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 workflow
muzes 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
--------------------------------------------------------------

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Odpovedet emailem