On Monday 20 of March 2006 18:29, Martin Kuba wrote: > Oto 'tapik' Buchta wrote: > > A ted k draftu: > > > > Kapitolka 3.2.1.3 Reachability je presne to, o cem SOA byt nema ;-) Dale > > doporucuji kapitolu 2.2 (a jeji posledni odstavec ;-) ), ktera je opravdu > > reprezentativnim vzorkem. Lide znali historie CORBY se opravdu budou za > > bricho popadat ;-) > > Tady bych byl opatrnejsi. Trh s CORBA komponentami nevznikl s vice > duvodu, jako ze implementace CORBY nebyly interoperabilni, a ze OO > rozhrani nedovoluji nezavisly vyvoj komponent. SOA nemusi > opakovat stejne chyby prave proto, ze neni OO.
Co se tyce interoperability mas pravdu - XSLT a XQuery jsou mnohem hezci nastroje nez CORBA2CORBA convertory. Na druhou stranu interoperabilita nad IDLky byla asi na stejne urovni jako mezi MS-serializaci a Apache-serializaci, o hratkach s datumem, nullem ci choicem ani nemluvim. Navic jsem ochoten tvrdit, ze kdyby v CORBA svete byla firma kalibru MS (maj to vsichni, ale nic horsiho neni), i tam by se vsichni prizpusobovali jednomu hraci. > > A co treba takova citace o provadeni akci "against the service"? Nene. > > Nekdo proste neslysel o WS-Addressingu. Tvurci teto specky si mysli, ze > > SOA je jenom tzv. XORBA (nepatentovano, lec priznano Radovanovi > > Janeckovi), neboli CORBA over XML. Jenze to je SOAP pet let stary a > > hlavni hraci na trhu SOA jsou jiz nekde UPLNE jinde (Pozor! MS o sobe > > tvrdi, ze SOA nema a neposkytuje!). > > 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 :-( > > A kecy o semantice dat to nenapravi (kdo kdy slysel, ze ZML-Schema > > definuje semantiku?) > > Co to ? Slova XML a schema se v tom dokumentu vubec nevyskytuji ! > Explicitni semantika je velice dulezita, protoze WSDL definuji pouze > lokalne nazvy XML elementu, ale pokud vyznam jejich obsahu neni urcen > zadnou explicitni specifikaci zpracovatelnou programem, musi byt vyznam > hardkodovan do programu programatory. A to je velice neflexibilni. 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 :-( > > A uplne nejvic to dorazili, kdyz pisou o transakcinich aspektech servisy. > > Transakce v SOA zkratka nefunguji a vi to uz uplne vsichni, kdo s nimi > > meli co do cineni. A vsechny ty snahy o BTP, WS-TX ci WS-Transaction > > skoncili krachem. > > Nefunguji ACID transakce, na ktere jsou vsichni zvykli z databazi. > Ale to neznamena, ze sluzba nemuze mit transakcni aspekty. > Pokud sis napriklad pres dve sluzby zarezervoval letadlo a hotel, > tak jsou to dve transakce, a kdyz ti zrusi letadlo, tak > bys mel zrusit i hotel, to proste je transakcni aspekt, > i kdyz se to neda vyresit klasickou transakci se zamykanim zdroju. 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 Vsechna tri chovani se ti v beznem zivote pri rezervaci pokoju mohou stat. Jaky je teda transakcni aspekt te ktere situace? Opravdu to neni jenom o ACIDite. Je ot celkem principialni. > > Bojim se, ze bude-li tento draft prijat jako 1.0 a bude nekym prosazovan, > > stahne to SOA zase na zacatek dlouho ji tam udrzi. > > Hm hm, a kde ze to teda vlastne SOA dneska je (krome toho, ze UPLNE > jinde ?). Jestli mas odkaz na nejaky rozumny text, ktery nejsou > jenom marketingove zvasty, tak si ho velice rad prectu. 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 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), 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 :-) -- Oto 'tapik' Buchta, [EMAIL PROTECTED] http://www.buchtovi.cz ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
