Na závěr své prezentace webových služeb J2EE (Java 2 Platform, Enterprise Edition) na loňském JavaOne architekt IBM Jim Knutson poznamenal, že „každá webová služba potřebuje místo, aby mohla být službou“. Poté navrhl, že nejideálnějším místem webové služby je infrastruktura J2EE. O něco více než o rok později se blíží finální vydání J2EE 1.4 a jeho nejvýznamnějším příslibem je splnit vizi webových služeb J2EE.
Funkce webové služby v J2EE 1.4 řeší jak webovou, tak klientskou stránku webových služeb. Funkce rozšiřují J2EE, aby umožnily existujícím podnikovým komponentám Java na straně serveru stát se webovými službami a určují, jak může kontejner klienta J2EE vyvolat webové služby. Technologie pro oba cíle již nějakou dobu existují a nové specifikace J2EE se spoléhají na tyto existující API pro podporu webových služeb. Nové specifikace přidávají do stávajících technologií sadu požadavků na interoperabilitu a programovací a implementační model pro integraci webových služeb.
Existují dvě specifikace, které výslovně popisují tyto přidané funkce: Java Specification Request 151, zastřešující JSR pro J2EE 1.4 a JSR 109, Web Services for J2EE. V době psaní tohoto článku dosáhla JSR 109 své konečné fáze v JCP (Java Community Process), zatímco JSR 151 je v poslední fázi hlasování. Kromě toho JCP pozměnilo konečné vydání JSR 101, rozhraní Java API pro vzdálené volání procedur založené na XML (JAX-RPC), aby podporovalo požadavky na interoperabilitu J2EE 1.4.
Aplikační servery na úrovni J2EE 1.3 mohou také implementovat mnoho funkcí předepsaných těmito JSR. Mnoho prodejců aplikačních serverů již nějakou dobu podporuje ve svých stávajících produktech různé funkce vývoje a nasazení webových služeb. JSR 109 a 151 kodifikují některé stávající postupy a popisují nové mechanismy s nadějí na vytvoření univerzálního modelu integrace služeb J2EE-Web. Aplikační servery nové generace budou pravděpodobně následovat tento jednotný, standardizovaný model.
Po krátkém průzkumu nových funkcí J2EE souvisejících s webovými službami tento článek přezkoumává nové programovací modely klientů a serverů, včetně nových rolí nasazení J2EE a rolí správy služeb spojených s podporou webových služeb.
Rozšíření J2EE související s webovými službami
Snad nejvýznamnějším a nejdůležitějším dodatkem k J2EE jsou nové požadavky na interoperabilitu. Požadavky předepisují podporu protokolu SOAP (Simple Object Access Protocol) 1.1 v prezentační vrstvě J2EE, aby se usnadnila výměna zpráv XML. Kontejnery kompatibilní s J2EE 1.4 musí také podporovat základní profil WS-I (Web Services Interoperability Consortium). Protože výměna zpráv XML v J2EE závisí na JAX-RPC, specifikace JAX-RPC nyní vyžadují také podporu WS-I Basic Profile.
Výsledkem je, že aplikaci založenou na J2EE 1.4 lze vyvolat jako webovou službu, a to i z aplikací, které nejsou napsány v programovacím jazyce Java. I když se jedná o evoluční krok pro J2EE, protože platforma již dlouho zahrnuje jiné systémy než Java, je to možná nejpřímější způsob, jak usnadnit interakci s technologiemi založenými na Windows, které se spoléhají na .Net.
Klient služby založené na J2EE nemusí vědět, jak je služba implementována. Tento klient může službu používat spíše tím, že se bude plně spoléhat na definici WSDL (Web Services Description Language) služby. (Předchozí JavaWorldWebové služby sloupce vysvětlují, jak objevit služby na základě jejich definic WSDL a jak vytvořit a používat definice WSDL. Odkazy najdete v Zdrojích.) Zatímco specifikace J2EE neuvádějí přesnou mechaniku takové interakce, objetí základního profilu WS-I J2EE 1.4, které Microsoft také tvrdí, že bude následovat, bude pravděpodobně dělat interakci J2EE-.Net běžnou .
Pro usnadnění přístupu k definicím WSDL přidává J2EE 1.4 podporu standardu JAXR (Java API for XML Registries). Knihovny JAXR jsou nyní povinnou součástí aplikačního klienta J2EE, EJB (Enterprise JavaBeans) a webových kontejnerů (nikoli kontejner appletu). Jelikož základní profil WS-I vyžaduje podporu pro UDDI (Universal Description, Discovery a Integration) 2.0, mohou klienti J2EE, stejně jako komponenty a servlety EJB, komunikovat s veřejnými registry webových služeb. („Web Services Float with JAXR“ (JavaWorld, Květen 2002) nabízí výukový program o JAXR.) Obrázek 1 ilustruje další knihovny související s webovými službami podporované J2EE 1.4.
Ve skutečnosti J2EE zastává názor, že webová služba je implementací jednoho nebo více rozhraní definovaných dokumentem WSDL. Operace popsané v WSDL se nejprve mapují na metody Java podle pravidel mapování WSDL-Java na specifikaci JAX-RPC. Jakmile je definováno rozhraní Java odpovídající souboru WSDL, můžete implementovat metody tohoto rozhraní jedním ze dvou způsobů: jako fazole relace bez státní příslušnosti spuštěná v kontejneru EJB nebo jako třída Java spuštěná v kontejneru servletu J2EE. Nakonec zajistíte, aby příslušný kontejner naslouchal příchozím požadavkům SOAP a mapoval tyto požadavky na příslušnou implementaci (EJB nebo servlet). Ke zpracování příchozích vyvolání SOAP J2EE 1.4 nařizuje běhový modul JAX-RPC jako další službu kontejneru J2EE.
V souladu s architekturou J2EE zprostředkovává kontejner implementace služby přístup k webové službě: pokud vystavíte komponentu EJB nebo servlet jako webovou službu J2EE, mohou klienti vaší služby tuto službu vyvolat pouze nepřímo, prostřednictvím kontejneru. To umožňuje implementaci služby těžit ze zabezpečení kontejneru, správy vláken a dokonce i záruk kvality služby. Kontejnery vám navíc umožňují provádět důležitá rozhodnutí o webových službách, jako jsou omezení zabezpečení, v době nasazení. Nakonec model J2EE založený na kontejnerech umožňuje přenos webových služeb: můžete vytvořit webovou službu založenou na Javě pomocí libovolného nástroje J2EE a očekávat, že tato služba bude spuštěna v jakékoli jiné implementaci vyhovujícího kontejneru.
Klient webové služby na druhé straně zůstává nevědomý přítomnosti kontejneru webové služby. Místo toho klient vidí a přístav představující instanci koncového bodu sítě webové služby. Tento koncový bod sleduje JAX-RPC rozhraní koncového bodu služby (SEI) model a poskytuje implementaci rozhraní služby. Klient vidí každou webovou službu J2EE jako kombinaci SEI a portu. Jeden kontejner J2EE může hostit mnoho takových kombinací, jak ukazuje obrázek 2. Každá kombinace SEI / port je instancí webové služby.
Všimněte si, že klientem v této architektuře může být buď klient J2EE, běžící uvnitř kontejneru klienta J2EE, nebo klient jiný než J2EE. Webovou službu J2EE může použít jakýkoli klient vyhovující základnímu profilu WS-I, ale každý klient může sledovat různé programovací modely. Specifikace webových služeb J2EE popisuje programovací model pro klienty, kteří běží uvnitř kontejneru klienta aplikace J2EE, a další model - programovací model serveru - pro implementace webových služeb, které se spouštějí v kontejnerech EJB nebo servletu.
Model programování klienta webové služby J2EE
Podstatou programovacího modelu klienta webové služby je zjednodušit používání API definovaných v JSRs 67 (Java API pro XML Messaging, JAXM), 93 (JAXR) a 101 (JAX-RPC) a poskytnout komplexní rámec pro společné používání těchto API v klientském kontejneru J2EE.
V souladu s klientským programovacím modelem klienta J2EE je klient webové služby vzdálený a poskytuje místní / vzdálenou transparentnost. Poskytovatel portu webové služby a kontejner, ve kterém je port spuštěn, definují, jak klient vidí webovou službu. Klient vždy přistupuje k portu a nikdy mu není předán přímý odkaz na implementaci webové služby. Klient webové služby J2EE si stále neuvědomuje, jak port funguje, a musí se zabývat pouze metodami, které port definuje. Tyto metody představují veřejné rozhraní webové služby. Kromě toho musí klient považovat přístup k portu webové služby za bezstavový v rámci vyvolání služby. Pokud jde o klienta, port postrádá jedinečnou identitu - klient nemá žádný způsob, jak zjistit, zda komunikuje se stejnými porty napříč vyvoláním služby.
Klient získá přístup k portu na základě rozhraní služby portu. Webové služby J2EE se při definování vztahu mezi portem a jeho servisním rozhraním spoléhají na JAX-RPC. JAX-RPC vytváří tento vztah na základě pravidel zpracování WSDL. Chování portu tedy definuje definice WSDL webové služby. Na základě definice JAX-RPC může být rozhraní služby buď obecným rozhraním přímo implementujícím javax.xml.rpc.Služba rozhraní nebo „generovaná služba“, což je podtyp tohoto rozhraní. Druhý typ rozhraní je specifický pro typ webové služby.
V programovacím modelu J2EE klient získá odkaz na webovou službu Servis objekt prostřednictvím vyhledávací operace JNDI (Java Naming and Directory Interface). Vyhledávání JNDI probíhá logickým názvem nebo odkaz na službu, pro webovou službu. Stejně jako u všech adresářových prostředků musí klient ve svém deskriptoru nasazení deklarovat, jaké prostředky potřebuje (o tom později).
Specifikace webových služeb Java (JSR 109) doporučuje, aby všechny webové služby byly zahrnuty pod JNDI servis podkontext. Kontejner klienta váže servisní rozhraní popsané tímto odkazem pod java: comp / env kontext pojmenování prostředí klienta. Deklarováním odkazu na službu v deskriptoru nasazení klienta kontejner klienta zajistí, že odkazovaná služba je k dispozici v prostředcích podporujících JNDI. Následující fragment kódu ukazuje, jak získat odkaz na webovou službu založenou na J2EE prostřednictvím vyhledávání JNDI:
InitialContext ctx = new InitialContext (); Služba myService = (služba) ctx.lookup ("java: comp / env / services / MyWebService"); Výše uvedený kód získá obecný objekt služby: objekt bez konkrétního typu. Ke službě generované JAX-RPC se přistupuje stejným způsobem, tentokrát k odeslání služby na typ rozhraní konkrétní webové služby:
InitialContext ctx = new InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Tento kód předpokládá, že MyWebService reference se váže na objekt, který implementuje MyWebService rozhraní. Vzhledem k tomu, že vazba služby je usnadněna v době nasazení webové služby, očekává se, že nástroje J2EE zajistí tuto konzistenci. Všechny aplikační servery kompatibilní s J2EE 1.4 musí podporovat vyhledávání služeb založené na JNDI.
Jakmile klient získá webovou službu Servis objekt, může tento objekt použít k načtení a javax.xml.rpc.Volání instance, která provádí skutečné vyvolání služby. Klient má tři možnosti, jak získat a Volání: přes stub, dynamický proxy služby nebo DII (Dynamic Invocation Interface). V tomto článku nebudu diskutovat rozdíly mezi těmito metodami, protože bez ohledu na to, jak Volání je vytvořeno, že Volání odkazuje přímo zpět na port služby - jediný objekt, kterého si klient musí být vědom při vyvolání webové služby. Všechny kontejnery kompatibilní s J2EE 1.4 musí podporovat Servis metody rozhraní, a tak umožnit klientovi získat odkaz na a Volání objekt pro webovou službu a na port této služby prostřednictvím Volání.
Na rozdíl od používání JAX-RPC mimo J2EE by klient neměl používat JAX-RPC ServiceFactory třídy k získání nové služby. Místo toho by měl klient získat přístup k Servis ze zdroje založeného na JNDI, protože odkaz na službu získanou z JNDI bude mít všechna nastavení a konfigurace nezbytné k vyvolání konkrétní instance služby. Z pohledu klienta je tento rozdíl poněkud analogický tomu, jak klient J2EE načte JDBC Zdroj dat prostřednictvím rozhraní JNDI pro přístup k databázi namísto ruční konfigurace JDBC Spojení instance.
S tím Volání objektu na místě, klient se řídí sémantikou JAX-RPC vzdáleného volání procedur. Například klient může použít vyvolat () metoda Volání komunikovat s webovou službou. (Příklad vyvolání služby ve stylu JAX-RPC najdete v části „Líbí se mi váš typ: Popište a vyvolajte webové služby založené na typu služby“ (JavaWorld, Září 2002).)
Programovací model serveru webové služby
Webová služba založená na J2EE může následovat jednu ze dvou možných implementací: Pokud je služba implementována jako běžná třída Java, musí odpovídat požadavkům kontejneru servletu JAX-RPC. Nebo, pokud je služba definována tak, aby se spouštěla v kontejneru EJB, musí se řídit programovacím modelem požadovaným pro fazole relace EJB bez státní příslušnosti. Bez ohledu na metodu implementace poskytuje každý kontejner implementaci webové služby s podporou životního cyklu, správou souběžnosti a infrastrukturou zabezpečení.
Primární odpovědností kontejneru serveru J2EE je mapování a odesílání požadavků SOAP v případě EJB na fazole relace bez státní příslušnosti a v případě kontejneru servletu na metody ve třídách koncových bodů služby JAX-RPC. Zatímco specifikace JAX-RPC definuje programovací model pro druhou možnost, J2EE Web Services JSR (JSR 109) popisuje analogický model pro fazole relace EJB bez státní příslušnosti.
