Programovanie

J2EE 1.4 uľahčuje vývoj webových služieb

Na záver svojej prezentácie webových služieb J2EE (Java 2 Platform, Enterprise Edition) na minuloročnom JavaOne architekt IBM Jim Knutson poznamenal, že „každá webová služba potrebuje miesto, aby mohla byť službou“. Potom navrhol, že najideálnejším miestom na poskytovanie webových služieb je infraštruktúra J2EE. O niečo viac ako rok neskôr sa blíži konečné vydanie J2EE 1.4 a jeho najvýznamnejším prísľubom je splnenie vízie webových služieb J2EE.

Funkcie webovej služby v J2EE 1.4 sa zameriavajú na serverovú aj klientskú stranu webových služieb. Tieto funkcie rozširujú J2EE, aby umožnili existujúcim podnikovým komponentom Java na strane servera stať sa webovými službami, a určujú, ako môže kontajner klienta J2EE vyvolať webové služby. Technológie pre oba ciele už nejaký čas existujú a nové špecifikácie J2EE sa spoliehajú na tieto existujúce API pre podporu webových služieb. Nové špecifikácie pridávajú k existujúcim technológiám súbor požiadaviek na interoperabilitu a model programovania a nasadenia pre integráciu webových služieb.

Existujú dve špecifikácie, ktoré explicitne načrtávajú tieto pridané funkcie: Java Specification Request 151, zastrešujúci JSR pre J2EE 1.4 a JSR 109, Web Services for J2EE. V čase písania tohto článku JSR 109 dosiahla svoju poslednú fázu v JCP (Java Community Process), zatiaľ čo JSR 151 je v poslednej fáze hlasovania. Okrem toho JCP zmenilo a doplnilo finálne vydanie JSR 101, rozhrania Java API pre vzdialené volanie procedúr na báze XML (JAX-RPC), aby podporilo požiadavky interoperability J2EE 1.4.

Aplikačné servery na úrovni J2EE 1.3 môžu tiež implementovať mnoho funkcií predpísaných týmito JSR. Veľa dodávateľov aplikačných serverov už istý čas podporuje podporu vývoja a nasadenia webových služieb vo svojich existujúcich produktoch. JSR 109 a 151 kodifikujú niektoré existujúce postupy a opisujú nové mechanizmy s nádejou na vytvorenie univerzálneho modelu integrácie služieb J2EE-Web. Aplikačné servery novej generácie budú pravdepodobne nasledovať tento zjednotený štandardizovaný model.

Po krátkom prieskume nových funkcií J2EE súvisiacich s webovými službami tento článok skúma nové programovacie modely klientov a serverov, vrátane nových rolí nasadenia J2EE a rolí správy služieb spojených s podporou webových služieb.

Rozšírenia J2EE súvisiace s webovými službami

Asi najvýznamnejším a najdôležitejším prírastkom v J2EE sú nové požiadavky na interoperabilitu. Požiadavky predpisujú podporu protokolu SOAP (Simple Object Access Protocol) 1.1 v prezentačnej vrstve J2EE na uľahčenie výmeny správ XML. Kontajnery vyhovujúce J2EE 1.4 musia tiež podporovať základný profil WS-I (Web Services Interoperability Consortium). Pretože výmena správ XML v J2EE závisí od JAX-RPC, špecifikácie JAX-RPC teraz nariaďujú aj podporu základného profilu WS-I.

Výsledkom je, že aplikáciu založenú na J2EE 1.4 je možné vyvolať ako webovú službu, a to aj z aplikácií, ktoré nie sú napísané v programovacom jazyku Java. Aj keď je to pre J2EE evolučný krok, pretože platforma už dávno obsahuje systémy, ktoré nie sú založené na prostredí Java, je to pravdepodobne najpriamejší spôsob uľahčenia interakcie s technológiami založenými na systéme Windows, ktoré sa spoliehajú na.

Klient služby založený na J2EE nemusí vedieť, ako je služba implementovaná. Tento klient môže službu používať skôr tak, že sa úplne spolieha na definíciu služby WSDL (Web Services Description Language). (Predchádzajúce JavaWorldWebové služby stĺpce vysvetľujú, ako vyhľadávať služby na základe ich definícií WSDL a ako vytvárať a používať definície WSDL. Odkazy nájdete v zdrojoch.) Zatiaľ čo špecifikácie J2EE neurčujú presnú mechaniku takejto interakcie, objatie základného profilu WS-I, ktoré Microsoft tiež tvrdí, že bude nasledovať, vďaka J2EE 1.4 pravdepodobne spôsobí, že interakcia J2EE-.Net bude bežná .

Na uľahčenie prístupu k definíciám WSDL pridáva J2EE 1.4 podporu pre štandard JAXR (Java API for XML Registries). Knižnice JAXR sú teraz povinnou súčasťou aplikačného klienta J2EE, EJB (Enterprise JavaBeans) a webových kontajnerov (nie však kontajner appletu). Pretože základný profil WS-I vyžaduje podporu pre UDDI (Universal Description, Discovery a Integration) 2.0, môžu klienti J2EE, ako aj komponenty a servlety EJB interagovať s verejnými registrami webových služieb. („Webové služby plávajú s JAXR“ (JavaWorld, Máj 2002) ponúka výukový program o JAXR.) Obrázok 1 zobrazuje ďalšie knižnice súvisiace s webovými službami podporované J2EE 1.4.

J2EE v skutočnosti zastáva názor, že webová služba je implementáciou jedného alebo viacerých rozhraní definovaných dokumentom WSDL. Operácie opísané v WSDL sa najskôr mapujú na metódy Java podľa pravidiel mapovania WSDL-Java na špecifikácie JAX-RPC. Po definovaní rozhrania Java zodpovedajúceho súboru WSDL môžete metódy tohto rozhrania implementovať jedným z dvoch spôsobov: ako fazuľa bezstavovej relácie bežiaca v kontajneri EJB alebo ako trieda Java bežiaca v kontajneri servletu J2EE. Nakoniec zariadite, aby príslušný kontajner počúval prichádzajúce požiadavky SOAP a mapoval tieto požiadavky na príslušnú implementáciu (EJB alebo servlet). Na spracovanie prichádzajúcich volaní SOAP J2EE 1.4 poveruje runtime JAX-RPC ako ďalšiu službu kontajnera J2EE.

V súlade s architektúrou J2EE sprostredkuje kontajner implementácie služby prístup k webovej službe: ak vystavíte buď komponent EJB, alebo servlet ako webovú službu J2EE, klienti vašej služby môžu túto službu vyvolať iba nepriamo, prostredníctvom kontajnera. To umožňuje implementácii služby ťažiť zo bezpečnosti kontajnera, správy vlákien a dokonca zo záruk kvality služieb. Kontajnery vám navyše umožňujú v čase nasadenia robiť dôležité rozhodnutia o webových službách, ako sú napríklad bezpečnostné obmedzenia. A konečne, kontajnerový model J2EE umožňuje prenosnosť nasadenia webových služieb: môžete vyvinúť webovú službu založenú na prostredí Java pomocou ľubovoľného nástroja J2EE a očakávať, že táto služba bude bežať v akejkoľvek inej implementácii kompatibilného kontajnera.

Na druhej strane klient webových služieb zostáva informovaný o prítomnosti kontajnera webových služieb. Namiesto toho klient vidí a prístav predstavujúca inštanciu koncového bodu siete webovej služby. Tento koncový bod sleduje JAX-RPC rozhranie služby endpoint (SEI) model a poskytuje implementáciu rozhrania služby. Klient považuje každú webovú službu J2EE za kombináciu SEI a portov. Jeden kontajner J2EE môže hostiť mnoho takýchto kombinácií, ako ukazuje obrázok 2. Každá kombinácia SEI / port je inštanciou webovej služby.

Upozorňujeme, že klientom v tejto architektúre môže byť buď klient J2EE, ktorý je spustený vo vnútri kontajnera klienta J2EE, alebo klient, ktorý nie je J2EE. Webovú službu J2EE môže používať ktorýkoľvek klient kompatibilný so štandardom WS-I Basic Profile, ale každý klient môže dodržiavať rôzne programovacie modely. Špecifikácia webových služieb J2EE načrtáva programovací model pre klientov, ktorí bežia v kontajneri klienta aplikácie J2EE, a ďalší model - programovací model servera - pre implementácie webových služieb, ktoré sa vykonávajú v kontajneroch EJB alebo servlet.

Model programovania klienta J2EE Web Service

Podstatou programovacieho modelu klienta webových služieb je zjednodušiť používanie rozhraní API definovaných v JSRs 67 (Java API pre XML Messaging, JAXM), 93 (JAXR) a 101 (JAX-RPC) a poskytnúť komplexný rámec pre spoločné použitie týchto rozhraní API v kontajneri klienta J2EE.

V súlade s programovacím modelom klienta J2EE je klient webových služieb vzdialený a poskytuje lokálnu / vzdialenú transparentnosť. Poskytovateľ portu webovej služby a kontajner, v ktorom je port spustený, definujú, ako klient vidí webovú službu. Klient vždy pristupuje k portu a nikdy mu nepríde priamy odkaz na implementáciu webovej služby. Klient webových služieb J2EE si stále neuvedomuje, ako port funguje, a musí sa zaoberať iba metódami, ktoré port definuje. Tieto metódy tvoria verejné rozhranie webovej služby. Okrem toho musí klient považovať prístup k portu webovej služby za bezstavový pri vyvolaní služby. Pokiaľ ide o klienta, portu chýba jedinečná identita - klient nemá žiadny spôsob, ako určiť, či komunikuje s rovnakými portami naprieč vyvolanými službami.

Klient získa prístup k portu na základe servisného rozhrania portu. Webové služby J2EE sa pri definovaní vzťahu medzi portom a jeho servisným rozhraním spoliehajú na JAX-RPC. JAX-RPC vytvára tento vzťah na základe pravidiel spracovania WSDL. Definícia WSDL webovej služby teda v konečnom dôsledku riadi správanie portu. Na základe definície JAX-RPC môže byť servisným rozhraním buď všeobecné rozhranie, ktoré priamo implementuje javax.xml.rpc.Služba rozhranie alebo „generovaná služba“, ktorá je podtypom tohto rozhrania. Druhý typ rozhrania je špecifický pre typ webovej služby.

V programovacom modeli J2EE získa klient odkaz na webovú službu Služby objekt prostredníctvom vyhľadávacej operácie JNDI (Java Naming and Directory Interface). Vyhľadanie JNDI sa uskutočňuje logickým názvom alebo odkaz na službu, pre webovú službu. Rovnako ako v prípade všetkých zdrojov založených na adresároch, musí klient vo svojom deskriptore nasadenia deklarovať, aké prostriedky potrebuje (o tom neskôr).

Špecifikácia webových služieb Java (JSR 109) odporúča, aby boli všetky webové služby subsumované pod JNDI služby podkontext. Kontejner klienta viaže rozhranie služby opísané v tomto odkaze pod java: comp / env kontext pomenovania prostredia klienta. Deklarovaním odkazu na službu v deskriptore nasadenia klienta kontajner klienta zabezpečí, že odkazovaná služba je k dispozícii v prostriedkoch s vedomím JNDI. Nasledujúci úryvok kódu ukazuje, ako získať odkaz na webovú službu založenú na J2EE prostredníctvom vyhľadávania JNDI:

 InitialContext ctx = nový InitialContext (); Služba myService = (služba) ctx.lookup ("java: comp / env / services / MyWebService"); 

Vyššie uvedený kód získava objekt všeobecnej služby: objekt bez konkrétneho typu. K službe generovanej JAX-RPC sa pristupuje rovnakým spôsobom, tentoraz sa služba prenesie na typ rozhrania konkrétnej webovej služby:

 InitialContext ctx = nový InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); 

Upozorňujeme, že tento kód predpokladá, že: MyWebService odkaz sa viaže na objekt, ktorý implementuje MyWebService rozhranie. Pretože väzba služby je uľahčená v čase nasadenia webovej služby, očakáva sa, že konzistenciu zabezpečia nástroje J2EE. Všetky aplikačné servery vyhovujúce J2EE 1.4 musia podporovať vyhľadávanie služieb založené na JNDI.

Akonáhle klient získa webovú službu Služby objekt, môže tento objekt použiť na získanie a javax.xml.rpc.Volať inštancia, ktorá vykonáva skutočné vyvolanie služby. Klient má tri možnosti, ako získať a Volaj: prostredníctvom pahýľa, servera dynamickej služby alebo rozhrania DII (Dynamic Invocation Interface). V tomto článku nebudem rozoberať rozdiely medzi týmito metódami, pretože bez ohľadu na to, ako a Volaj je vytvorené, že Volaj odkazuje priamo na port služby - jediný objekt, ktorý musí byť klient pri vyvolaní webovej služby vedomý. Všetky kontajnery vyhovujúce J2EE 1.4 musia podporovať Služby metódy rozhrania, a tak umožniť klientovi získať odkaz na a Volaj objekt pre webovú službu a na port tejto služby prostredníctvom Volaj.

Upozorňujeme, že na rozdiel od použitia JAX-RPC mimo J2EE by klient nemal používať JAX-RPC ServiceFactory triedy na získanie novej služby. Namiesto toho by mal klient získať prístup k Služby zo zdroja založeného na JNDI, pretože odkaz na službu načítanú z JNDI bude mať všetky nastavenia a konfigurácie potrebné na vyvolanie konkrétnej inštancie služby. Z pohľadu klienta je tento rozdiel trochu analogický s tým, ako klient J2EE získava JDBC Dátový zdroj prostredníctvom rozhrania JNDI na prístup do databázy namiesto manuálnej konfigurácie JDBC Pripojenie inštancia.

S tým Volaj objektu na mieste, klient sa riadi sémantikou JAX-RPC vzdialeného volania procedúry. Napríklad, klient môže použiť vzývať() metóda na to Volaj komunikovať s webovou službou. (Príklad vyvolania služby v štýle JAX-RPC nájdete v časti „Páči sa mi váš typ: Popíšte a vyvolajte webové služby na základe typu služby“ (JavaWorld, September 2002).)

Programovací model servera webovej služby

Webová služba založená na J2EE môže nasledovať jednu z dvoch možných implementácií: Ak je služba implementovaná ako bežná trieda Java, musí zodpovedať požiadavkám kontajnera servletu JAX-RPC. Alebo, ak je služba definovaná na vykonávanie v kontajneri EJB, musí nasledovať programovací model vyžadovaný od fazule relácie EJB bez štátnej príslušnosti. Bez ohľadu na metódu implementácie poskytuje každý kontajner implementácii webových služieb podporu životného cyklu, správu súbežnosti a bezpečnostnú infraštruktúru.

Primárnou zodpovednosťou kontajnera servera J2EE je mapovanie a odosielanie požiadaviek SOAP, v prípade EJB, na bezstavové fazule relácie a v prípade kontajnera servletu na metódy v triedach koncových bodov služby JAX-RPC. Zatiaľ čo špecifikácia JAX-RPC definuje programovací model pre druhú možnosť, J2EE Web Services JSR (JSR 109) načrtáva analogický model pre bezstavové fazule relácie EJB.

$config[zx-auto] not found$config[zx-overlay] not found