On Tuesday 25 April 2006 15:45, Zdeněk Vráblík wrote: > On 4/25/06, Jan Medek <[EMAIL PROTECTED]> wrote: > > Tahle kombinace by me zajimala. KOmunikace mezi C# a Java jede > > pres WebServices? Jak hodnotite rychlost pri prenosu vetsiho mnozstvi > > dat? > > Nikdy jsem rychlost netestoval. Na velke mnozstvi dat pouzivame prave > ten vlastni XML protokol. WS pouzivame jen na kratke ridici > dotazy/prikazy. > WS protokol je docela "uzvaneny":] a pred vlastnim zpracovanim dat > musi provest prevod > xml -> objekty. Vlastni protokol muzeme zpracovavat po castech a ty > pak zahazovat. > Myslim si, ze nejvetsi slabina je prave pametova narocnost.
Asi se do teto diskuse budu muset vlozit. Je smutne, kolik mytu, pover, dezinformaci, polopravd a lzi se siri kolem sveta webovych sluzeb. Pokusim se nektere z nich vyvratit: 1) U webovych sluzeb neni zarucena doba odezvy - u Webove Sluzby je to naprosto stejne jako u jakekoli jine meziprocesove komunikace (ani nemusi jit o sitovou komunikaci pres TCP/IP ci jiny sitovy protokol). NIKDY nemate zarucenu dobu odezvy. Jedine, co vam muze jakz takz pomoct je timeout prenosoveho protokolu, takze kdyz mate request-response WebServisu s HTTP-SOAP bindingem, mate tu 30 vterin... Navic nikde jinde nez ve svete WebServis mate tak rozpracovany system QoS - Quality Of Service. Mnohe discovery systemy je pak umeji perfektne pouzit, takze jsou brokery distribuujici na zaklade kriterii, jako je load systemu, odezva hosta atd. 2) Webove sluzby se nedaji pouzit na real-time aplikace - dneska si uz nikdo nedokaze predstavit velke simulacni systemy, aniz by fungovali na clusterech pri pouziti vicevrstve architektury. A vicevrstva architektura znamena sitarinu a jsme u bodu 1). A budete se divit, co vsechno se dnes dela pres WebServisy. Par prikladu: * jedna armada pouziva WebServisy k simulaci bojovych situaci, pricemz kazde bojove jednotce odpovida jedna WebServisa. Jejich discovery se pak resi pres UDDI. * moc by se vsichni uzivatele Microsoft Windows XP a KDE divili, kolik maji na svem pocitaci bezicich webovych sluzeb, a pritom ani nejsou na Internetu ;-) * veskere toky dat v jedne nejmenovane francouzke bankovni spolecnosti tecou pres SOAP interface * vsichni zakaznici T-Mobile se s kazdou odeslanou SMS ci zavolanim spojuji se SOAP stackem jedne nejmenovane spolecnosti *... 3) WebServisy jsou pomale, protoze se dela serializace a deserializace mezi XML a objektovou reprezentaci. - mnoho velkych systemu pracuje nativne nad XML dokumenty, takze pouzivaji jako rozhrani tzv. RAW servisy, tedy ve skutecnosti servlety a pouze generuji SOAP misto HTML. Zpracovani SOAP Envelope zabere zlomek casu oproti vlastnimu naparsovani XMLcka. Ano, XML je zakladnim kamenem urazu. 4) Zavolani WebServisy je HTTP request-response. - SOAP je nezavisly na transportnim protokolu. Nedavno jsem dokonce slysel, ze jeden clovicek pouziva SOAP via disketa ;-). Ale SMTP a JMS transporty jsou zcela bezne pouzivane. 5) HTTP protokol je pomaly - no jestli mate pomale odezvy Googlu... Ad vlastni XML protokol: Moc by mne zajimalo, kolik z vas, kdo pouziva vlastni XML protokol, k nemu pristupuje pres SAX ci jiny podobny parser. Myslim, ze vetsina z vas to stejne nazene do DOMu ;-) Ad rychlost prenosu dat: uz jsem psal, ze potize jsou v XML. Pockejte na binarni XML a prenos se dostane o rad jinde. Ad mnozstvi dat: pres SOAP with attachments jsme protlacili 2GB zpravu, a to vse na Opteronoven Linuxu. Holt nas zakaznik, nas pan. Ad problem sluzby na nasobeni: vite, uz pred deseti lety bylo na urovni transputeru dokazano, ze vysoka mira specializace bez dokonale hierarchizace zahlcuje system (URLcko vam nereknu, pouze vim, ze se tehdy jednalo o optimalizace pri RayTracingovem renderovani sceny, kde kazdy transputer predstavoval jedno teleso. Nakonec se ukazalo, ze vykonnejsi je nedelit scenu, ale pruzor, takze kazdy transputer dostal spocitat kousek sceny, kterou dostal celou k dispozici) . Jsou-li si vsechny WS rovny, pak nema-li dojit k zahlceni systemu, je treba shlukovat aplikacni logiku WebServis do celku. Je tedy jasne, ze sluzba nasobici dve cisla bude hodne nesmyslna. Na druhou stranu existuji systemy se desitkami tisic webovych sluzeb (a nejsou to jednoucelne ani generovane webservisy) a v pohode tyto systemy funguji. Tady pak nastava akorat potiz jejich spravovatelnosti, aby se nestalo, ze servis se stejnou ci podobou funkcionalitou bude zbytecne mnoho (idealne ne vic nez jedna, ale to je opravdu ideal). -- 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 ______________________________________________________________________
