Oto 'tapik' Buchta wrote:
Ja v tom draftu vidim v casti 2.2 explicitne uvedene, ze SOA *neni* Objektove Orientovana tj. CORBA-like.OOP neni CORBA.A navic to je asi tak, jako kdyz Paroubek v televizi rekl, ze ten, kdo vyklada, ze CSSD prosazuje zakony za pomoci komunistu, lze. Nekladou duraz na zakladni principy OOP jako je dedicnost a enkapsulace, ale napriklad Booz-Allenove vidi kazdou servisu jako xicht pro s databazi manipulijici business logic. Bohuzel :-(
Na ksichtu pro manipulaci s databazi jeste neni nic spatneho. K tomu OOP - nejde o OOP, ale o ditribuovane objekty. Ze v distribuovanem pripade se neda distribuovanost objektu schovat pekne popisuje tohle: [1] Samuel Kendall and Jim Waldo and Ann Wollrath and Geoff Wyant:Note on Distributed Computing, 1994, http://research.sun.com/techrep/1994/abstract-29.html
A vyborny clanek, proc distribuovane objekty jsou spatne je tohle: [2] Werner Vogels: Web Services Are Not Distributed Objects, IEEE Internet Computing, Volume 7, Number 6, 2003, http://csdl.computer.org/dl/mags/ic/2003/06/w6059.htm (asi je to videt jenom pro predplatitele IEEE Digital Library) v podstate pise, ze problem s objekty v distribuovanem pripade jsou vzajemne reference objektu a orientace na operace misto na dokumenty, protoze prvni vyzaduje distribuovane garbage collectory a druhe znemoznuje evoluci. A velice trefny postreh je v [3] Pat Helland: Data on the Outside Versus Data on the Inside, {CIDR, Second Biennial Conference on Innovative Data Systems Research, 2005, http://www-db.cs.wisc.edu/cidr/cidr2005/papers/P12.pdf totiz ze prechod od DOO k SOA je jako prechod od Newtonovske k Einsteinove fyzice - prvni predpoklada, ze existuje jakysi pozorovatelny soucasny stav celeho systemu, kdezto druha musi pocitat s tim, ze viditelny je vzdy jen obraz minuleho stavu vzdaleneho systemu. No a mne pripada, ze ten draft od OASIS si je tehto problemu s DOO vedom, coz je pozitivni.
Souhlasim s tebou, lec:V dokumentu neni o semantice nic poradneho napsano a pokud vim, tak onou semantikou byla prave myslena implicitni semantika dana standardizovanymi XML schematy. Bohuzel. Prestoze pouzili slovo "ontologie", o RDF si mysli sve :-(
Co se ontologii tyce, tak si o RDF taky myslim sve, a myslim, ze OWL by se dal postavit i bez RDF.
Vis, Makube, toto preci neni o transakcnosti. To je o schopnosti resit nezvykle situace. Co udelas, kdyz si koupis tapetu presne na miru a pak pri lepeni zjistis, ze jsi spatne meril? Kdyby slo rollbacknout tapetu a lepidlo zpatky do obchodu, bylo by to prima. Jenomze takto to nefunguje. A uplne stejne je to ve svete long-running loosely-coupled procesu. I v tvem pripade. Zavolas si na hotel, tam ti reknou:a) ano, muzeme zrusit rezervaci b) za poplatek ji zrusime c) mate smulu
Mas pravdu, ale pokud vis predem, ktera z moznosti a)-c) muze nastat, muzes s tim pocitat. A pri sestavovani slozitejsiho workflowmuzes predem pocitat s tim, ze kdyz dojde k nejake chybe (vypadne letadlo), muzes udelat jistou kompenzacni akci (zrusit i hotel).
Muzes to misto transakcnosti nazvat kompenzovatelnosti vypadku, ale je to jisty aspekt :-)
Problem je v jedne veci: neexistuje ucelena architektonicka studie. Dodavatele nechavaji tuto bohulibou cinnost na Gartnerech a Burtonech a ZiffDavisech a jim podobnych a vzdy, kdyz nejaka takova analyticka skupĂșina s necim prijde, snazi se ukazat, jak napasovat sve produkty prave do te ktere strategie. Treba zajimavy link od celkem mene znamych je na http://www.newrowley.com/reports/soa_nrg_v1_0.pdf
Diky za odkazy. Tenhle je pekne napsany, ale v podstate rikaji jenom ze SOA = neco postavenene na XML a WS.
Mali jsou moc mali a velci (MS a IBM) jsou rozhadani. A tak se hlavni architektonicky vyvoj deje vice mene zakulisne pri osobnich jednanich na face-to-facech, interopech ci conf-callech ruznych komisi. Spousta stripku se objevuje na Blozich architektu a evangelistu. Jenom obcas vyleti neco jako IONA seven points (http://whitepapers.zdnet.co.uk/0,39025945,60040064p-39000575q,00.htm),
Na tohle se nedostanu, chce to clenstvi :-(
Ale smer je vice mene dany uz tri roky: jedine, co ma vyznam, jsou data. Neni ani tak dulezite KDO provede danou akci, ale ZE se provede. Enrichment dat je uprednostnen nad procesy. Mizi klasicke consumer-provider kontrakty, do popredi se dostavaji dynamicke kontraktory. Dokumenty putujici po Internetu a hledajici-si svuj cil. A je jedno, jestli putuje po ESB, Content-Based Routeru, je jedno, jestli je pouzito UDDI, superinteligentni Broker nebo nas Blizzard, je jendo, jestli je zprava zpracovana sofistikovanym Gridem, tupym BPELem, C# servisou, EJBckem nebo jenom proleti nasim Arkem, a temi je jedno muzeme pokracovat.Proste vztah klient-sluzba v pojeti teto specky je velmi eqivalentni vztahu CORBA-klient - remote-object. V SOA takovy staticky kontrakt neni. Kdo si jej vytvori, prichazi o SOA. Takove srandicky jako QoS-based runtime licitace staveni vypocetni pipe-lajny se statickymi kontrakty proste nedate :-)
Makub -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Supercomputing Center Brno Martin Kuba Institute of Computer Science email: [EMAIL PROTECTED] Masaryk University http://www.ics.muni.cz/~makub/ Botanicka 68a, 60200 Brno, CZ mobil: +420-603-533775 --------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
