Názory k článku Idoox demonstroval interoperabilitu svých produktů založených na Web Services

Je velmi chvalihodne, ze jednotlivi implementatori produktu zalozenych na protokolu SOAP udrzuji interoperabilitu vzajemnymi setkanimi. Mozna by stalo za uvahu, jestli by interoperabilitu nemel zajistovat uz samotny standard protokolu SOAP.

Tento clanek je pro mne velmi poucny neb marketingovy pojem ''Web Services'' povysil na architekturu.

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).

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.

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).

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.

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...

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''.

Suhlas. Soap sa urcite uplatni ako medzi-platformovy protokol pre vzajomnu komunikaciu inak voci sebe uzavretych systemov - napr. medzi Javou a m$ svetom (.net). V inych oblastiach sa ale takmer vzdy da najst lepsie riesenie...

Co je pradvdy na tom, ze jiz existuje MS IE pod Unix? Podival jsem se primo do About boxu verze 5.0 pod Windows a tam je cituji: "Verze pro systém Unix obsahuje software, na který uděluje licenci společnost Mainsoft Corporation."

Ze by MS prestal ignorovat UNIX?

Myslim, ze byla vyvijena a mozna i vyvinuta verze pro SunOS. Ale v kazdem pripade od toho nelze ocekavat, ze se bude chovat uplne jako IE pod Win, vsechny vlastnosti, uzce svazane s ruznymi Win objektama, nebyly asi plne portovany.

Mno, na microsoft.com jsem videl verzi pro HP-UX (tusim) ... bylo to dodavane v balicku, ne jako source a pouze pro tento system. jak msie tak i outlook express.

Tak pak je dost velka ignorace od MS, ze ho neportovala pod Linux. Podle meho by mel MS, pokud se nechce utopit, zacit podporovat linux co nejdriv. Ale nejlepsi by bylo, kdyby se utopil uz ted. Nechtel bych videt dalsi licencni spory ohledne tehle produktu. A hlavne draz nez zadarmo by podle meho lidem z komunity nic neprodal, a ty neznalci, co maji wokna stejne na Lin v dohledny dobe neprejdou (naji prece sva Okna, co porad nejdou, ale jsou tak easy).

ze zatimco CORBA a EJB jsou uz hotove za znamou cenu, tak na rozdilu ceny CORBA + EJB <-> SOAP + reseni IDOOX, hodla IDOOX zalozit business plan :-)

IMHO EJB je plus minus totez, co se snazi IDOOX prezentovat jako svoji vizi (ale pssst, nerikejte to investorum).

IMHO ne. EJB je o implementaci business logiky, perzistenci, transakcich a v neposledni rade take o pristupu k business logice. SOAP je podle me spis jenom o tom pristupu. Zato je tak trochu otevrenejsi a umoznuje pristupovat jak k EJB, CORBe ... (viz nahore).
Chudak jsem asi i ja, protoze jsem nepochopil tu na me asi prilis genialni noticku o Idoox business planu a jeho zalozeni na nejakem rozdilu ceny :O(

- cetl jsem specifikaci; a pokud si k SOAP pridame WSDL + UDDI (souhrne nazyvane Web Services) uz mi to vubec neprijde "simple"
- ted je SOAP v pozici glue mezi CORBA + EJB/RMI + COM/DCOM, pokud se tam pridaji veci jako transakcni kontexty, security a dalsi veci, za par let budeme hledat protocol na integraci CORBA, EJB, DCOM a SOAP(Web Services) (na tom asi zalozim svuj bussiness plan ja ;)
- za simple povazuji tak jeste HTTP, rovnez XML je uzitecne (pro projekt na kterem delam jsme si vyvinuli
nas vlastni XML-based protocol pouzivajici HTTP: interface aplicace je popsan v XML a na generovani
stubu nebo skeletonu staci jeden XSLT template)

hi all,

kdyz jsem si tak cetl diskusi: vubec si nemyslim, ze jedina rozumna aplikace SOAPu je pro EAI nebo B2B, jak se tady naznacuje. Srovnavat enterprise technologie typu CORBA, EJB se SOAPem je asi taky dost mimo. Vzdyt web services jsou hlavne o jinem (z mnoha ohledu lepsim) pristupu k tvorbe webovskych aplikaci. Kolik procent web serveru ted ma jako svoje backendy J2EE servery nebo CORBA runtimy? Vzdyt jsou tu tuny jednodussich aplikaci bezicich na klasicke kombinaci Apache + php apod. Vize Idooxu je mimo jine zalozena na tom, ze SOAP, WSDL, a UDDI spojeny vhodne do jednoho celku povznesou tyto aplikace z urovne CGI skriptu na distribuovane objekty, organizovane a vyhledatelne napr. podle interfejsu, komunikujici jednim jazykem (nezavislym na transportu!)... To je pro me pritazlive daleko vic nez EAI, i kdyz uznavam, ze v integraci a b2b komunikaci je trochu vic penez (a asi vic problemu a tudiz i spousta vyzev). Proto taky v Idooxu delame oboje :-) Nas system je maximalne integrovan s J2EE (SOAP/JMS, JTA, EJB, security), ale nezavisi na nem, tudiz udelat si s nasim produktem jednoduchou web servisku bezici treba na Tomcatovi je zalezitost asi 5 minut.

Jinak souhlasim s Gergiho naznakem, ze se ze SOAP/WSDL/UDDI++## muze stat CORBA pristi generace :-)

''Jinak souhlasim s Gergiho naznakem, ze se ze SOAP/WSDL/UDDI++## muze stat CORBA pristi generace :-)''

Drzim palce a preji mnoho uspechu. Nebudete to mit vubec jednoduche. :-))