Vlákno názorů k článku Idoox demonstroval interoperabilitu svých produktů založených na Web Services od Tomas Zezula - Osobne si myslim, ze SOAP (Simple Object Access...
-
Článek je starý, nové názory již nelze přidávat.
-
Tomas Zezula (neregistrovaný)
Osobne si myslim, ze SOAP (Simple Object Access Protocol) je hezka prezentacni vrstva nikoliv protokol vhodny pro enterprise middleware. Pomineme-li pocatencni bolesti (URIFuzziness=5, problemy s navratovymi hodnotami versus out parametry), SOAP je pouze protokol nikoliv framework jako napriklad CORBA nebo EJB. Jedine mozne vyuziti SOAPu vidim v B2B pro bridging a pripadne jako prezencni vrstvy pro EJB nebo CORBA aplikace (e.g. IONA XMLBus).
-
Zdenek Svoboda (neregistrovaný)
Vyuziti v B2B je neoddiskutovatelne. Krome B2B vsak vidim vyuziti SOAPu i v pripade integrace komponent a aplikaci zalozenych na rozdilnych technologiich. Dnesni podniky nejsou zdaleka cernobile, takze SOAP muze byt vhodnou platformou napriklad pro integraci J2EE s mainfraimovymi technologiemi nebo aplikacemi zalozenymi na COM/DCOM - nepochybne velmi 'popularnich' mezi ctenari root.cz :o). Dokonce vyrknu kacirskou myslenku, ze vyse popsana integrace je nutnosti, kterou musi absolvovat kazda vetsi spolecnost drive nez zacne s realizaci nejake B2B platformy. Proc tedy nepouzit pro integraci technologii, ktera je transparentni z hlediska pouziti, funguje stejne dobre na interni siti jako na Internetu a tudiz pri pozdejsi implementaci B2B strategie nemusi clovek delat spoustu veci 2x.
Na zaklade vlastnich zkusenosti z velke zapadoevropske banky si dovolim odhadnout, ze ackoliv se SOAP dnes a v blizke budoucnosti bude pouzivat pro export business logiky na Internet, jeho nejvetsi prinos bude prave v oblasti integrace aplikaci. -
Tomas Zezula (neregistrovaný)
Jak jsem uvedl vyse. SOAP je vhodny pro B2B, B2C. Na integrace enterprise systemu je vsak nevhodny. Myslim si, ze CORBA a technologie na ni zalozene (EJB), nabizi mnohem vice moznosti, ktere enterprise potrebuje (e.g. Load balancing, Fault Tolerance, Licencing, a CORBA Application Domains jako je Finance, Telecomunication, atd). SOAP jednoduse postrada jakoukoliv infranstrukturu, jedna se pouze o protokol, mimochodem muze byt vlozen do CORBy jako ESIOP (coz vydim jako nejlepsi reseni, dostal bych existujici funkcni framework).
-
Zdenek Svoboda (neregistrovaný)
Tohle ja vidim naprosto odlisne. Pokud bych se na vec dival jenom z technologickeho hlediska, budu rikat to same - CORBA je nejpropracovanejsi, vseobjimajici system. Po udivu nad technologickou dokonalosti specifikaci CORBY u me ale prevladlo rozcarovani nad jejimi implementacemi, podporou vedoucich IT firem a jejim pouzivani. Specifikace jsou sice pekne, ale interoperabilita jednotlivych implementaci CORBA standardu konci u IIOP protokolu (mozna, tak jeste funguje zabezpeceni pres SSL). Vsechny dalsi casti CORBA standardu jako transaction, naming, trading services a dalsi - zkratka to, co pro mnoho lidi dela enterprise enterprisem :o), je uz silne proprietarni zalezitost. Sam bych si pral aby tomu tak nebylo - hovori ze me trpka zkusenost integrace CORBA reseni z jedne z nejvetsich clearingovych bank v Evrope, kde je dnes slovo CORBA chapano skoro jako sproste slovo :o). Kdyz si k tomu pridate postoj takoveho M$ ke CORBA standardu, nevychazi mi CORBA jako uplne idealni reseni pro integraci systemu. Osobne bych se priklanel k necemu jednodussimu a pruhlednejsimu - treba prave SOAPu nebo jeho nasledovniku v podobe nejakeho XML protokolu. Pokud se u SOAPu podari standardizovat veci jako remote references, security tokeny, propagace transakcniho kontextu (o cemz mimochodem setkani interopu jsou), myslim ze bude mnohem lepsim kandidatem nez CORBA nebo treba EJB (na tom se asi shodneme, ze v EJB je situace velmi podobna).
Zkratka - pro me je dulezity pristup a ten je v pripade SOAP a CORBA naprosto rozdilny - CORBA resi problemy shora - kazdy potencialni problem je osetren ve specifikaci. Tim se z CORBA stava velmi komplexni system, ktery snad jeste zadny dodavatel neimplementoval kompletne a pokud se uz tak tvari, tak ne interoperabilne.
SOAP pristup je presne opacny - resme a standardizujme to, co je treba, hlavne aby to bylo jednoduche a pouzitelne. Muj nazor je, ze s timto pristupem je dnes slabe rocni SOAP z hlediska interoperability dal nez leta pilovana CORBA. -
sk (neregistrovaný)
Na co by mohol byt SOAP lepsia kandidat ako EJB ??? Nechapem celkom ako mozete porovanavat tieto dve veci...
EJB je middlewareova komponentova technologia...
Nemali ste na mysli RMI - tj. doslovne protokol pre vzdialene volanie metod (ktorym sa zhodou okolnosti mozu volat EJBeany) ??
A v com je EJB v podobnej situacii ako CORBA ? Ak myslite to, ze jednotlive implementacie sa dostatocne nedrzia specifikacii, tak ja si myslim opak, situacia v podpore poslednych specifik. J2EE je podla mna celkom slusna (ak pominieme napr. IBM - WebSphere a pod.)
A samozrejme je tu jedna podstatna vec ktora rozlisuje SOAP a binarne protokoly ako IIOP a RMI - a to je vykon.
A kde je treba vykon, tam bude mat asi vzdy navrch dobre vyrieseny binarny protokol nez sebelepsi XML protokol beziaci cez HTTP... -
Zdenek Svoboda (neregistrovaný)
SOAP je podle me lepsi na integraci systemu. Mel jsem samozrejme na mysli RMI resp. RMI over IIOP.
Myslim, ze diskutovat o tom jak SOAP nahradi EJB nebo CORBu na urovni middleware je nesmysl. Zminovana role SOAPu je integrovat EJB, CORBA, COM/DCOM a dalsi distribuovane objekty a aplikace. Na to je podle me mnohem vhodnejsi nez CORBA, RMI a jim podobne protokoly.
Situace CORBA a EJB je velmi podobna pokud jde o interoperabilitu. Jinak pokud jde o J2EE standard a jeho dodrzovani jednotlivymi aplikacnimi servery, nikdo me po moji vice nez dvoulete praci v SilverStreamu nepresvedci, ze neco jako J2EE certifikace je zarukou kompatibility EJB containeru. (pomijeni WebSphere, ktera je svetova 2 v app serverech mi pripada nekorektni). Vzajemna interoperabilita EJB containeru je podle meho nazoru naprosto zalostna, ale to je namet na jinou debatu.
Pokud jde o vykon, jsem presvedcen, ze pri soucasne vykonnosti SOAP stacku (Java - cca 500 msgs za sekundu, C++ okolo 1500) je pro vetsinu implementaci diskuze o vykonnosti bezpredmetna. Pro me je diskuze o vykonu stejna jako kdybych si vybiral mezi auty, z nichz jedno ma maximalni rychlost 250 a druhe 300. Pokud nejsem pilot F1, dam pochopitelne prednost jinym argumentum :o) -
sk (neregistrovaný)
"SOAP je podle me lepsi na integraci systemu" = suhlas, tak som to myslel i ja (ak je to "systemu" v mnoznom cisle - tj. ak integrujeme viac heterogennych aplikacii).
"Myslim, ze diskutovat o tom jak SOAP nahradi EJB nebo CORBu na urovni middleware je nesmysl" - ja som iba reagoval na to, ze ste tieto veci kladli vedla seba - ide pritom o principialne odlisne veci (aj ked teraz som si vsimol, ze ste vlastne reagovali na toho pred vami..:)
Nechcem samozrejme nejak znizovat vase prakticke skusenosti J2EE servermi, resp. s EJB containermi - kazdopadne certifikacia je tu snad prave na to aby napr. RMI daneho servera fungovala podla specifikacie.. Takze 2 certifikovane servre by sa asi dohovorit mali.. (aj ked realna skutocnost sa zrejme lisi... )
Ak sa na primerane obsiahlej specifikacii SOAPu naozaj zhodnu vsetky dolezite strany a implementacie sa jej naozaj budu drzat - tak potom to bude skvele !
Co sa tyka vykonnosti SOAPu - existuju dake zdroje informacii / porovnania ? Celkom by ma to zaujimalo... -
Zdenek Svoboda (neregistrovaný)
Nejakou oficialni stranku o vykonnosti SOAP stacku jsem zatim nevidel. Moje informace jsou primo od jednotlivych dodavatelu SOAP stacku. Java stacky zalozene na lightweight XML parserech maji vykonnost okolo 500 zprav za sekundu (mereno na beznem Pentium III/600). Hodne jde take o implementaci HTTP listeneru (z vlastnich zkusenosti muzeme potvrdit napriklad obrovsky rozdil mezi beznym Tomcatem a WebLogicem - ve prospech druheho z nich). Jinak C++ implementace bezne dosahuji kolem 1500 msgs/sec. na stejnem HW (to je udaj od developeru MS SOAPu)
-
Karel Gardas (neregistrovaný)
Rad bych zde jen podotknul, ze na zaklade vlastnich mereni a informaci tretich stran musim opravit Vasi vetu srovnavajici kvalitu ruznych vozu na:
''Pro me je diskuze o vykonu stejna jako kdybych si vybiral mezi auty, z nichz jedno ma maximalni rychlost 25 a druhe 300. Pokud nejsem pilot F1, dam pochopitelne prednost jinym argumentum :o)''
Nebot 46800 one-way a 13500 two-way calls per second je proste trosku jina kava*
*ORBacus/E for C++ on a Pentium III 800MHz w/ Windows 2000 and Visual C++ 6.0, optimized for speed
- zdroj OOC. -
Karel Gardas (neregistrovaný)
Z Vaseho prispespevku jde citit klasicke znechuceni uzivatele implementace CORBA 2.0. Toto jsem zazil u mnoha lidi mnohokrat a tak uz se tomu ani nedivim. Nicmene bych si Vas dovolil opravit: CORBA v roce 1995 neni stejna jako ta v roce 2001 a CORBA 2.0 je proti CORBA 2.4 cistociste *orezavatko*. Mimo jine Vami zminovane services *jsou* skutecne interoperabilni uz na zaklade standardu a ten kdo ho neni schopen dodrzet proste neni ''compliant''.
