Vývoj webových služeb

v J2EE bez zbytečné složitosti Přední dodavatelé z tábora zastánců Javy podporují se svými produkty vývoj webový...


v J2EE bez zbytečné složitosti
Přední dodavatelé z tábora zastánců Javy podporují se svými produkty vývoj
webových služeb už delší dobu. Grafická vývojová prostředí nabízejí
programátorům komfortní nástroje pro tvorbu javových web services, které
pokrývají celý cyklus jejich realizace od tvorby kódu až po nasazení. Avšak
teprve v nedávno uvolněné poslední verzi standardu J2EE 1.4 je na tuto
architekturu poprvé oficiálně brán zřetel.
To, že se webové služby staly už zcela seriózně zvažovanou a využívanou
alternativou pro většinu IT oddělení, ukazují i průzkumy mezi podnikovými
uživateli. Konzultanti z firmy Cap Gemini Ernst & Young v loňském roce
zjistili, že na tuto architekturu alespoň zčásti sází 83 % ze 170 dotázaných
výkonných manažerů z německých podniků. Analytikové ze společnosti Gartner
dokumentují na základě své studie z jara 2003 dokonce ještě silnější zájem:
Podle ní testovalo metodu webových služeb ponejvíce v rámci pilotních projektů
už 92 % účastníků průzkumu prováděného ve Spojených státech.
Za plus můžeme považovat to, že je možné implementovat webové služby při
využití jakéhokoliv programovacího jazyka. Potřebnou transformaci kódu
vytvořeného v jednotlivých programovacích jazycích dávají k dispozici vývojová
prostředí jako JDeveloper společnosti Oracle, JBuilder firmy Borland nebo
Microsoft Visual Studio .Net a lze ji provést obvykle několikerým kliknutím
myší. Webové služby nabízejí rovněž možnost realizace mostů mezi platformami
J2EE a .Net.

Smíšené aplikace
Známá grafická vývojová prostředí nabízejí programátorům komfortní nástroje pro
tvorbu javových komponent typu web services. To se týká jak psaní obchodní
logiky například ve formě javových tříd, vybudování J2EE Enterprise Archivu,
tvorby WSDL rozhraní a SOAP zpráv, tak nasazení archivu na aplikačním serveru.
Pro zajištění kompatibility například mezi zmíněnými J2EE a .Net nicméně v
současnosti ještě nejsou zcela kompletně definovány potřebné standardy. Tak
může dojít i k tomu, že třeba WSDL popisy vytvořené pomocí jednoho nástroje
nebudou kompatibilní se SOAP zprávami klienta, který byl vygenerován pomocí
nástroje jiného dodavatele. Zde mohou poskytnout pomoc vývojářské komunity a
fóra (jako je skupina SOAPBuilders, www.soapbuilders.org), aby bylo možné
otestovat bikompatibilitu smíšených aplikací a zjistit, zda může být
kupříkladu .Net aplikace volána javovým klientem a obráceně.
Na rozdíl od XML webových služeb navrhovaných podle pravidel Microsoftu, které
se opírají o technologii .Net a operační systémy této firmy, a běží tedy pouze
na hardwarové platformě Intelu, představují webové služby vyvíjené pod J2EE
specifikaci frameworků založených na XML, které jsou implementovány různými
dodavateli. Přitom je definována řada standardizovaných API, která dovolují
realizovat existující obchodní logiku implementovanou například jako javové
třídy nebo Enterprise JavaBeans (EJB) ve formě webových služeb. Mezi klíčová
API patří: Java API for XML Processing (JAXP, API pro zpracování XML
dokumentů), na něm postavené Java API for XML-Based RPC (JAX-RPC, API pro
tvorbu webových služeb a aplikací, jež využívají RPC funkcionalitu odpovídající
specifikaci SOAP 1.1), rozhraní pro XML registry (Java API for XML Registries,
JAXR), jakož i Java Architecture for XML Binding (JAXB, API a nástroje pro
automatické mapování mezi XML dokumenty a javovými objekty).
V principu se rozlišují web services typu RPC-Style (RPC je zkratkou pro Remote
Procedure Call) a Document-Style (který hraje důležitou roli zejména ve světě
Microsoftu). V případě RPC-Style obsahuje SOAP zpráva syntaxi volání funkce a
provádí také volání vzdálené procedury. Datové typy jsou přitom kódovány podle
specifikace SOAP. U Document-Style služeb naproti tomu dochází k výměně
dokumentů a datové typy jsou kompletně definovány na základě XML Schematu.
Základem pro nasazení webových služeb jsou obvykle aplikační servery firem,
jako je BEA, Sun, Oracle, IBM, nebo také řešení z tábora open source, jako
třeba Apache Axis. Ty poskytují běhové prostředí, starají se o komunikaci web
services s klientskými programy a umožňují distribuci komponent. Kromě toho pak
nabízejí také kontrolní, bezpečnostní a transakční služby. Pro tvorbu a
distribuci webových služeb disponují aplikační servery například účelově
orientovanými nástroji, s jejichž pomocí lze programy zabalit jako webové
služby.

Komfortní práce
Mnohem pohodlnější je, když vývojová prostředí podporují práci programátorů
prostřednictvím grafických nástrojů, tedy tzv. wizardů, grafického modelování
na bázi Unified Modelling Language (UML) s diagramy tříd a aktivit, jakož i
pomocí automatického generování javových tříd a XML dat. Vedle toho patří mezi
důležité vlastnosti většiny programovacích nástrojů funkce jako tuning,
debugging či monitoring webových služeb.
Při vývoji webových služeb je možné zpracovat odpovídajícím způsobem existující
programy a stejně tak psát i zcela nové aplikace. Pro novou aplikaci
naprogramuje vývojář jako obvykle její obchodní logiku například ve formě
javových tříd. Přitom jsou aplikace rozlišeny na "stateless" a "statefull",
přičemž aplikace prvního typu neoznačují svůj stav. Pokud by měly být použity
při tvorbě web services aplikací, které si stav pamatují, je nutné si vypomoci
použitím cookies. Programátor však není nucen se o to starat, neboť aplikační
server v tomto případě mechanismus založený na cookies používá automaticky.
Tato metoda však ještě není plně standardizována, přechodem na jiné běhové
prostředí tak mohou vzniknout náklady spojené s touto změnou. Dalšími
implementacemi logiky mohou být mezi jinými stateless Enterprise JavaBeans, JMS
Destination nebo také databázové aplikace jako SQL procedury a JSP procedury
(Java Stored Procedure).
Ve druhém kroku vytváří vývojář J2EE Enterprise Archive (EAR), což je ve
většině vývojových nástrojů taktéž podporováno. Přitom je automaticky vytvořeno
WSDL rozhraní, které popisuje, jak lze danou službu vyvolat. Zároveň dochází ke
generování všech nezbytných tříd: client stub nebo také proxy se starají o to,
aby byla javová volání na klientské straně přeložena do SOAP zpráv, a server
skeleton převádí na straně serveru SOAP volání do jazyka dané implementace
služby, tedy například do Javy.
Pro vývojáře klientských aplikací jsou k dispozici příslušná javová API, takže
nemusejí vytvářet SOAP zprávy ručně. Důvod spočívá zejména v tom, že
programátoři se zpravidla vyznají v Javě a neměli by být nuceni se nezbytně
zabývat implementací SOAPu.
Následující krok spočívá v nasazení archivu služeb na aplikační server. V rámci
této úlohy podporuje většina vývojových sad nasazení na více typů aplikačních
serverů, a to pouhými několika kliknutími myši. Přitom je vytvořen J2EE archiv
webových služeb, a ten adekvátně poskytuje J2EE předpisy v aplikačním serveru
tak, že je daná webová služba ihned schopna běhu. Pro otestování
provozuschopnosti webové služby většina běhových prostředí předem automaticky
vytváří testovacího klienta ve formě Java Server Page.

Poskytovatel a konzument
Posledním úkolem je napsat klientskou aplikaci. Zde mohou javoví vývojáři
profitovat z generovaného client stubu. Za tímto účelem musí být pouze
zajištěno, aby byla v klientském programu požadovaná volání webových služeb
naprogramována jako lokální volání javových metod na stub.
Jako webové služby je možné dávat k dispozici nejen javové aplikace, ale také
existující databázové aplikace, které mohou být za tímto účelem velmi pohodlně
odpovídajícím způsobem "přeměněny". Zde jsou rozlišovány v zásadě dva
mechanismy: databáze fungující buď jako provider, nebo jako consumer. V prvním
případě spočívá implementace, a tedy i programová logika v databázi, a měla by
proto být jako webová služba zvenčí dostupná. Tak se dá uskutečnit přístup k
relačním a multimediálním datům, XML dokumentům i dalším databázovým objektům
také přes jiné, například na prohlížeči založené aplikace. Výhodou je, že tímto
způsobem jsou současně chráněny dříve provedené investice do SQL aplikací, o
které se databáze opírá. S odpovídajícím nástrojem pak budou SQL procedury
zapouzdřeny do javového "obalu" a opatřeny popisem založeným na WSDL.
Prostřednictvím SOAP na ně následně mohou sahat i další programy.

Existující logika
Jestliže databáze pracuje jako consumer, získává SQL nebo Java Stored Procedure
aplikace data z jiného systému přes webovou službu. Aby bylo možné volat
vzdálenou službu, musejí být v databázi k dispozici příslušné SOAP knihovny i
Java Client Proxy. To je jednoduchý prostředek pro efektivní používání logiky,
již dává databáze k dispozici. Tak se lze podle potřeby dotazovat z databázové
aplikace na data, která se permanentně mění (kupříkladu kurzy akcií či měny,
úrokové sazby nebo informace o počasí). Uveďme si příklad: Nedosahuje-li se
stav zásob ve skladu, který je reprezentován nějakou databázovou tabulkou,
určité minimální hodnoty, bude prostřednictvím SOAP zprávy automaticky vyvolána
další objednávka zboží v dodavatelském systému.
V moderních podnikových řídicích řešeních jsou dnes takové události prováděny
přímo v aplikacích. U mnoha používaných databázových aplikací se však díky
webovým službám nabízí možnost velmi rychle doplnit či dodatečně nasadit mimo
databázi takové varovné či ohlašovací funkce bez toho, aby bylo třeba aplikaci
přepsat či znovu napsat.

Snadno a rychle
Právě rychlost a jednoduchost jsou hlavním motivem pro nasazování webových
služeb, což potvrzují i na začátku zmíněné průzkumy společnosti Cap Gemini
Ernst & Young. Zatímco méně než 38 % dotázaných uživatelů vedly k implementaci
web services jako klíčový důvod nákladové aspekty, kritéria jako flexibilita či
rychlé přizpůsobení se vůči změnám na trhu stála se 66 % jednoznačně na prvním
místě.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.