K dnešnímu článku mě inspiroval můj bývalý kolega, který se jednou naučil webové služby a od té doby je používal úplně všude - bez ohledu na to, že by se mnohdy dalo použít lepší (rozuměj jednodušší, efektivnější) řešení.
Napadá mě zde analogie s EJB. Mnoho lidí se naučí EJB a od té doby je používají bez ohledu na to, zda skutečně EJB kontejner v aplikaci potřebují. Podobné je to i s webovými službami. Webové služby jsou nezastupitelné v komunikaci mezi různými platformami. Jinak řečeno, pokud nemáme všechny komunikující systémy pod kontrolou, tak vždy bude asi nejlepší používat webové služby. Existují i jiné "multiplatformí" protokoly jako např. binární Hessian nebo textový Burlap, ale určitě nejsou tak rozšířené jako webové služby. Co se ale týče jednoduchosti použití a hlavně rychlosti komunikace, tak zde webové služby hodně ztrácejí oproti jiným řešením.
Pokud ovšem máme komunikující systémy pod kontrolou a navíc se jedná o Java aplikace, tak bych webové služby nevolil. V těchto případech většinou nejde o vystavení nějaké trvalé služby, ale o vzdálené volání metod. Pro tyto případy nejvíce ocením jednoduchost použití (tj. jednoduchost při nastavení řešení plus pracnost spojená s úpravou objektů pro přenos) a rychlost komunikace.
Pro tyto případy mám výborné zkušenosti s řešením od Springu - Spring remoting. Osobní zkušenosti mám s použitím HttpInvokeru - víceméně řešení postavené na Java serializaci s přenosem po HTTP. S tímto řešením jsem neměl jediné problémy, fungovalo suprově. Jen jsem musel dořešit jednu věc - kromě vlastních objektů se přenášely i objekty knihoven třetích stran, které občas obsahovaly neserializované objekty (většinou se jednalo o výjimky). V tomto případě jsem si pomohl AOP - vytvořil jsem si AOP vrstvu nad vzdálenými službami, která kontrolovala, zda všechny přenášená data jsou opravdu serializovatelná.
Na posledním projektu používáme Hessian z důvodu požadavku na co největší výkon resp. na přenos co nejmenšího množství dat. Tuto volbu jsme provedli (lépe řečeno mojí kolegové) na základě vlastních měření a ze zkušeností uvedených v tomto článku. S Hessianem pracuji zatím velice krátce, ale již se mi podařilo narazit na problémy s přenosem dat (až budu znát přesné příčiny a řešení, tak to uvedu v komentáři k tomuto článku).
U Spring remotingu se mi také libí, že je to postavené nad DispatcherServletem (stejně jako třeba Spring MVC), takže mohu využívat spoustu společných věcí, zejména Spring security pro zabezpečení.
Pokud nevíte, který protokol vybrat pro vaše řešení, tak si přečtěte výše uvedený článek (zejména závěrečné shrnutí) a nebo doporučení uvedené v dokumentaci Springu.
Facilitace je klíč úspěchu
před 2 týdny
Příspěvky
15 komentářů:
Uplny souhlas. Jedina nevyhoda Spring Remoting je, ze na obou stranach musi bezet Spring.
Jsi si tím opravdu jistý? Já bych řekl, že Spring pouze zabaluje knihovny třetích stran a nijak neovlivňuje dané protokoly - takže by mělo jít mít na jedné straně Spring remoting s Hessianem a na druhé straně třeba Python také s Hessianem. Nemám to vyzkoušené, je to jen můj předpoklad.
Byl to informacni sum, za ktery se omlouvam :) Zdalo se mi, ze pri HttpInvokeru je komunikace Spring2Spring, ale podle dokumentace se zda, ze neni.U ostatnich protokolu samozrejme muze klient v jakemkoliv podporovanem jazyce.
Já měl onehdá s Hessianem problémy v případě, že metody měly složitější signatury například foo(InputStream, String). Nevíte jestli se to dá nějak řešit?
4jinxx:Tak pokud vim tak Spring Remoting je projekt ktery zastresuje ruzne remote protokoly a zjenodudusuje praci s nima. Naproti tomu HttpInvoker je primo v tomto projektu vytvoreny protokol, ktery serializuje standardni java serializaci a takto zaserializovane objekty posle skrze HTTP.
Takze (myslim) jedno je podmnozinou druheho.
P.S.: Takze HttpInvoker je dobry pokud vsechny komunikujici vrstvy aplikace maji stejnou verzi. Nekomunikuje se totiz skrz rozhrani, ale primo instancema. Coz ma hned nekolik neblahych vlastnosti. Bez velkeho usili nedosahnete toho, aby fieldy dostupne jenom na serveru se nemaji propagovat na klienta (bespecnostni problemy). Navic kdyz takhle do instnace na serveru pridate novy field, naprosto nepodstatny na klientovy, musite dodat i novou kompilaci klienta, jinak nebude objekt deserializovatelny. (samozrejme muzete napsat vlastni serializaci a deserializaci trid, ale to uz bude prilis slozite).
ja v jave delam zatim jenom s SE,
takze tyhle webove sluzby neznam.
a jak ctu ruzne javove weby, tak
to vypada jako by uz klasicke
aplikace s GUI swingem uz nikdo
nedelal.
Souhlas s Anonymní. Dělám menší projektíky v JavaSE, ale pohled do konferencí, blogů a na další místa vypadá, jako by nikdo nedělal nic jiného než webové aplikace. Nebo se desktopoví vývojáři skrývají?
4MaReK Olsavsky: Java je silna prave na serverove aplikace. A casem se ukazuje ze sprava aplikaci ktere pouzivaji browser jako klienta je vyrazne snazsi a mene narocne. Neresite problemy klientskych stanic (spatna verze javy, rozbite dll, stara verze aplikace kterou si uzivatel nechce preinstalovat, nasazovani na nove pocitace)
Tim nechci rict ze by nemelo smysl vytvaret SE aplikace, ale nemyslim, ze Java je na to nejlepsi nastroj Takze o tom si spise poctete v C, C++, Delphi, Visual Basic a mozna i v C# komunite, nez v Java komunite.
P.S.: navic uzivatel od webove aplikace neocekava ze se bude chovat jako Word a mnohe ji promine. Chape ze na vsechno klika mysi a klavesove zkratky vubec nepouziva, po kliku pokojne ceka ne reload a nevi jestli je to kvuli pomalosti linky nebo aplikace.
Odbočím od posledních komentářů k mému problému s Hessianem - jak jsem již uváděl v článku.
Problém byl v tom, ze Hessian při serializaci standardně přistupuje k některým datovým typům speciálně, např. typy Iterator, Enumeration, Collection apod. serializuje jako pole. A jelikož moje přenášená struktura implementuje Iterator, tak ho serializuje jako pole, což při deserializaci nefunguje. Takže je třeba explicitně nakonfigurovat SerializationFactory tak, aby pro danou třídu použil jiný typ serializace.
@Lukas Krecan jake problemy Lukasi? My jsme ted delali jedno remote rozhrani a pouzili jsme Hessian. V prototyp jsme zkusily testy Java a C# klienta a fakcilo to vcetne prenasini velkych souboru, ktere byly v signature metody uvedeny jako InputStream. Jediny problem byl se C# Hessian implementaci, ktera nezvladla soubory vetsi nez 128MB.
ad benzin:
nam funguje Java Web Start uspokojivě pro tisícovku klientů, viz Javová aplikace pro každého? Ano!
ad benzin:
nam funguje Java Web Start uspokojivě pro tisícovku klientů, viz Javová aplikace pro každého? Ano!
Out of topic: Trosku v uvodu citim zahorklost vuci EJB :) ... premyslim, kolik lidi, se muze na projektu rozhodnout, zda pouzit EJB nebo jinou technologii. Na vetsine projektu, kde jsem byl, si technologii urcil zakaznik, popr. architekt, takze uz moc prostoru k rozhodovani se, zda pouzit EJB ci nikoliv, tam nebylo.
To sám znám, že některé věci si člověk prostě sám vybrat nemůže, ale zase vím, že dost často se daly určité technologie "vysvětlit".
Je také pravda, že na většině projektů jsem to byl já, kdo volil technologie a kdo to celé navrhoval, takže jsem si to mohl udělat podle svého.
@jiripisa no to zalezi na pozici, pokud jsi byl vsude jako kontraktor, tak jsi prostel mohl drzet usta a krok. Ja delal vzdy na projektech, kde byla svoboda rozhodovani ponechana do jiste miry na jeho tvurcich. Vsude platilo, ze pokud byl duvod pro zavedeni one technologie alespon trochu rozumny, tak to slo. Nekdy sice tezce, ale slo :-).
Okomentovat