Lukas Zapletal wrote: > Mockrat dekuju za reakce. K tomu, jestli musim nebo nemusim - ja si to > nevymyslel, mam jen pred sebou "jednoduchy" pozadavek: CORBA-SOAP > bridge a vcetne emulace RPC pres SOAP. Je nutne, aby to zkratka > chodilo pres jednu ESB. > > Podivam se na ty "pokusy" o tento pristup. Moc me to tedy nepotesilo, > ale doufam, ze nejaka podmnozina funkcnosti nebude zas tak slozita na > implementaci. Bohate mi bude postacovat nejaky mechanismus predavani > odkazu, jako je napriklad naznacen v prikladu zde: > > http://webservices.xml.com/pub/a/ws/2003/07/22/sessions.html?page=2 > > Uvidim, budu dale zkoumat. Pokud by mel nekdo jeste pripominku, sem s ni :-)
Ten clanek je zastaraly. Uz ve stejnem roce, jako byl napsan, se zjistilo, ze jediny zpusob, jak opravdu zajistit interoperabilitu, je zanechat marnych pokusu o prenosy objektu pomoci XML, a misto toho pouzivat prenos XML dokumentu. Ten rozdil na prvni pohled vypada maly, ale je velmi vyznamny. Zatimco dva programovaci jazyky se neshodnou ani na tom, co je treba pole retezcu, a z neshod vyplyvaji nekompatibility, parsovani XML dokumentu je ve vsech programovacich jazycich stejne. Viz velmi dobry clanek, proc pouzivat document/literal wrapped style: http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ > > Mimochodem, to je moc zajimavy clanek. Kdyz jsem ci tak cetl temi > vyhodami a nevyhodami mezi DO/WS, tak me napadla otakza (nejen na pana > Kubu): proc je tedy SOA tak uspesna, kdyz DO ma tolik veci navic (a ty > tri nevyhody by byly prece v jiste mire resitelne)? Ja si nejsem jisty, nakolik je SOA uspesna, a nakolik jde o dojem vytvareny marketingovymi oddelenimi firem produkujicich nastroje pro SOA :-) Viz napriklad cerstvy clanek Who is killing SOA: http://www.zapthink.com/report.html?id=ZAPFLASH-20071001 Nicmene muj pocit je, ze pro spoustu pripadu je plnotucne reseni zalozene na DO (CORBA a spol.) zbytecne slozite, a tudiz pro vyvojare tezke na nauceni. Oproti tomu SOAP web services jsou relativne jednoduche na nauceni. Ale ted zrovna zastavam nazor, ze pro tu stejnou spoustu pripadu je i SOAP zbytecne slozite reseni, a uplne postaci JSON http://www.json.org/, protoze data prenese taky a mnohem jednoduseji. Nakonec totiz plati, a vzdycky bude platit, ze jednodussi reseni je lepsi nez slozitejsi. Prisel na to uz mnich William Occam ve ctrnactem stoleti a rika se tomu Occamova britva :-) Jednodussi reseni maji mene veci, ktere mohou nefungovat. Napriklad se zjistilo, ze kdyz Amazon dal stejnou sluzbu k dispozici pres SOAP a pres jednoduche stahnuti XML dokumentu pomoci HTTP metody GET, tak 80% provozu je na te jednoduche sluzbe, viz http://csdl2.computer.org/comp/mags/ds/2004/12/oz001.pdf A jeste jedna vec je asi dulezita, proc sluzby jsou uspesnejsi nez distribuovane objekty. Sluzby totiz asi lepe modeluji lidskou cinnost nez objekty. Kdyz chcete neco po nejakem uradu, poslete jim dokument, kterym zadate o sluzbu, a oni vam po case asynchronne vrati jiny dokument, ktery vas informuje o vysledku. To odpovida volani sluzby pomoci dokumentu. S uradem nejednate tak, ze na nem zavolate operaci, ktere predate ukazatel na jiny urad :-) 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
