Ob zaključku svoje predstavitve spletnih storitev J2EE (Java 2 Platform, Enterprise Edition) na lanski JavaOne je IBM-ov arhitekt Jim Knutson pripomnil, da "vsaka spletna storitev potrebuje mesto, ki bo storitev." Nato je predlagal, da je najbolj idealno mesto za spletno storitev znotraj infrastrukture J2EE. Nekaj več kot leto kasneje je končna izdaja J2EE 1.4 neizbežna, njegova najpomembnejša obljuba pa je uresničitev vizije spletnih storitev J2EE.
Funkcije spletnih storitev v J2EE 1.4 so namenjene tako strežniški kot odjemalski strani spletnih storitev. Funkcije razširjajo J2EE, tako da obstoječe komponente Java na strani strežnika postanejo spletne storitve in določajo, kako lahko odjemalec odjemalca J2EE prikliče spletne storitve. Tehnologiji za oba cilja obstajata že nekaj časa, nove specifikacije J2EE pa se zanašajo na obstoječe API-je za podporo spletnih storitev. Nove specifikacije obstoječim tehnologijam dodajo nabor zahtev po interoperabilnosti ter model programiranja in uvajanja za integracijo spletnih storitev.
Obstajata dve specifikaciji, ki izrecno opisujeta te dodane funkcije: Zahteva za specifikacijo Java 151, krovni JSR za J2EE 1.4 in JSR 109, spletne storitve za J2EE. V času pisanja tega članka je JSR 109 dosegel svojo zadnjo stopnjo v JCP (Java Community Process), medtem ko je JSR 151 v zadnji fazi glasovanja. Poleg tega je JCP spremenil končno izdajo JSR 101, Java API-jev za oddaljeni klic na osnovi XML (JAX-RPC), da bi podpiral zahteve po interoperabilnosti J2EE 1.4.
Aplikacijski strežniki na ravni J2EE 1.3 lahko izvajajo tudi številne funkcije, ki jih predpisujejo ti JSR-ji. Številni ponudniki aplikacijskih strežnikov že nekaj časa podpirajo različne funkcije razvoja in uvajanja spletnih storitev v svojih obstoječih izdelkih. JSR 109 in 151 kodificirata nekatere obstoječe prakse in opisujejo nove mehanizme z upanjem, da bodo ustvarili univerzalni model integracije spletnih storitev J2EE. Strežniki aplikacij naslednje generacije bodo verjetno sledili temu enotnemu, standardiziranemu modelu.
Po kratkem pregledu novih funkcij J2EE, povezanih s spletnimi storitvami, ta članek pregleduje nove modele programiranja odjemalcev in strežnikov, vključno z novimi vlogami uvajanja in upravljanja storitev J2EE, povezanimi s podporo za spletne storitve.
Razširitve J2EE, povezane s spletnimi storitvami
Morda so najpomembnejši in najpomembnejši dodatki k J2EE nove zahteve glede interoperabilnosti. Zahteve predpisujejo podporo za SOAP (Simple Object Access Protocol) 1.1 v predstavitveni plasti J2EE za lažjo izmenjavo sporočil XML. Zabojniki, skladni z J2EE 1.4, morajo podpirati tudi osnovni profil WS-I (Konzorcij za interoperabilnost spletnih storitev). Ker je izmenjava sporočil XML v J2EE odvisna od JAX-RPC, specifikacije JAX-RPC zdaj zahtevajo tudi podporo za osnovni profil WS-I.
Rezultat tega je, da lahko aplikacijo, ki temelji na J2EE 1.4, prikličete kot spletno storitev, tudi iz aplikacij, ki niso napisane v programskem jeziku Java. Čeprav je to evolucijski korak za J2EE, ker platforma že dolgo zajema sisteme, ki ne temeljijo na Javi, je verjetno najbolj neposreden način za lažjo interakcijo s tehnologijami, ki temeljijo na sistemu Windows in se zanašajo na .Net.
Naročnik storitve, ki temelji na J2EE, se ne mora zavedati, kako se storitev izvaja. Ta odjemalec lahko storitev uporablja tako, da se v celoti zanese na definicijo storitve WSDL (jezik za opis spletnih storitev). (Prejšnji JavaWorldSpletne storitve stolpci pojasnjujejo, kako odkriti storitve na podlagi njihovih definicij WSDL ter kako ustvariti in uporabiti definicije WSDL. Glejte Vire za povezave.) Medtem ko specifikacije J2EE ne navajajo natančne mehanike takšne interakcije, bo J2EE 1.4 s svojim osnovnim profilom WS-I, za katerega trdi tudi Microsoft, verjetno omogočil skupno delovanje J2EE-.Net .
Za lažji dostop do definicij WSDL J2EE 1.4 dodaja podporo za standard JAXR (Java API za registre XML). Knjižnice JAXR so zdaj obvezen del odjemalca aplikacije J2EE, EJB (Enterprise JavaBeans) in spletnih vsebnikov (ne pa vsebnika programčka). Ker osnovni profil WS-I zahteva podporo za UDDI (Univerzalni opis, odkrivanje in integracijo) 2.0, lahko odjemalci J2EE ter komponente in strežniški programčki EJB komunicirajo z javnimi registri spletnih storitev. ("Spletne storitve zaplavajo z JAXR" (JavaWorld, Maj 2002) ponuja vadnico o JAXR.) Slika 1 prikazuje dodatne knjižnice, povezane s spletnimi storitvami, ki jih podpira J2EE 1.4.
J2EE dejansko meni, da je spletna storitev izvedba enega ali več vmesnikov, opredeljenih v dokumentu WSDL. Operacije, opisane v WSDL, se najprej preslikajo v metode Java po pravilih preslikave WSDL-Java v specifikaciji JAX-RPC. Ko je definiran vmesnik Java, ki ustreza datoteki WSDL, lahko metode tega vmesnika uveljavite na enega od dveh načinov: kot seja brez zrn brez stanja, ki se izvaja v vsebniku EJB, ali kot razred Java, ki se izvaja v vsebniku strežniškega programčka J2EE. Nazadnje poskrbite, da bo ustrezni vsebnik poslušal dohodne zahteve SOAP in te zahteve preslikal v ustrezno izvedbo (EJB ali strežniški programček). Za obdelavo dohodnih klicev SOAP J2EE 1.4 pooblasti izvajalno okolje JAX-RPC kot dodatno storitev vsebnika J2EE.
V skladu z arhitekturo J2EE vsebnik izvedbe storitve posreduje dostop do spletne storitve: če komponento EJB ali strežniški program razkrijete kot spletno storitev J2EE, lahko odjemalci vaše storitve to storitev prikličejo le posredno prek vsebnika. To omogoča izvedbi storitve, da izkoristi varnost vsebnika, upravljanje niti in celo garancijo kakovosti storitve. Poleg tega vam vsebniki omogočajo, da v času uvajanja sprejemate pomembne odločitve spletnih storitev, na primer varnostne omejitve. Končno, model, ki temelji na vsebniku J2EE, naredi uvajanje spletnih storitev prenosno: spletno storitev, ki temelji na Javi, lahko razvijete s katerim koli orodjem J2EE in pričakujete, da se bo ta storitev izvajala v kateri koli drugi skladni izvedbi vsebnika.
Po drugi strani odjemalec spletnih storitev še vedno ne ve za prisotnost vsebnika spletnih storitev. Namesto tega stranka vidi a pristanišče predstavlja primer omrežne končne točke spletne storitve. Ta končna točka sledi JAX-RPC vmesnik končne točke storitve (SEI) model in zagotavlja izvedbo vmesnika storitve. Naročnik na vsako spletno storitev J2EE gleda kot na kombinacijo SEI in vrat. En posoda J2EE lahko gosti veliko takih kombinacij, kot prikazuje slika 2. Vsaka kombinacija SEI / vrat je primerek spletne storitve.
Upoštevajte, da je odjemalec v tej arhitekturi lahko odjemalec J2EE, ki se izvaja znotraj vsebnika odjemalca J2EE, ali odjemalec, ki ni J2EE. Vsak odjemalec, skladen z osnovnim profilom WS-I, lahko uporablja spletno storitev J2EE, vendar lahko vsak odjemalec sledi različnim programskim modelom. Specifikacija spletnih storitev J2EE opisuje programski model za odjemalce, ki se izvajajo znotraj odjemalskega vsebnika aplikacije J2EE, in drug model - model strežniškega programiranja - za izvedbe spletnih storitev, ki se izvajajo v vsebnikih EJB ali servlet.
Model odjemalskega programiranja odjemalca za spletno storitev J2EE
Bistvo odjemalskega programskega modela spletnih storitev je poenostaviti uporabo API-jev, opredeljenih v JSRs 67 (Java API-ji za sporočanje XML, JAXM), 93 (JAXR) in 101 (JAX-RPC), in zagotoviti celovit okvir za z uporabo teh API-jev v odjemalskem vsebniku J2EE.
V skladu z modelom programiranja odjemalcev J2EE je odjemalec spletnih storitev oddaljen in zagotavlja lokalno / oddaljeno preglednost. Ponudnik vrat spletnih storitev in vsebnik, v katerem se vrata izvajajo, določata, kako odjemalec vidi spletno storitev. Odjemalec vedno dostopa do vrat in nikoli ne prejme neposredne reference na izvedbo spletne storitve. Odjemalec spletne storitve J2EE še vedno ne ve, kako vrata delujejo, in se mora ukvarjati samo z načini, ki jih vrata določajo. Te metode predstavljajo javni vmesnik spletne storitve. Poleg tega mora odjemalec pri klicih storitev obravnavati dostop do vrat spletnih storitev kot brez državljanstva. Kar zadeva odjemalca, v vratih ni edinstvene identitete - odjemalec ne more ugotoviti, ali komunicira z enakimi vrati med klici storitev.
Naročnik dobi dostop do vrat na podlagi vmesnika storitve pristanišča. Spletne storitve J2EE se zanašajo na JAX-RPC, da opredelijo razmerje med vrati in njihovim vmesnikom storitve. JAX-RPC ustvari to razmerje na podlagi pravil obdelave WSDL. Tako definicija WSDL spletne storitve na koncu ureja vedenje vrat. Na podlagi definicije JAX-RPC je lahko vmesnik storitve generični vmesnik, ki neposredno izvaja javax.xml.rpc.Service vmesnik ali "ustvarjena storitev", ki je podvrsta tega vmesnika. Slednja vrsta vmesnika je značilna za vrsto spletne storitve.
V programskem modelu J2EE odjemalec pridobi sklic na spletno storitev Storitev objekt prek operacije iskanja JNDI (Java Naming and Directory Interface). Iskanje JNDI se izvede z logičnim imenom ali referenca storitve, za spletno storitev. Tako kot pri vseh virih, ki temeljijo na imeniku, mora odjemalec tudi v svojem deskriptorju razmestitve navesti, katere vire potrebuje (več o tem kasneje).
Specifikacija spletnih storitev Java (JSR 109) priporoča, da se vse spletne storitve vključijo v JNDI storitev podkontekst. Odjemalski vsebnik veže servisni vmesnik, opisan s to referenco pod java: comp / env kontekst poimenovanja odjemalskega okolja. Z navedbo sklica na storitev v odjemalčevem deskriptorju razmestitve odjemalski vsebnik zagotovi, da je referenčna storitev na voljo v virih, ki jih pozna JNDI. Naslednji delček kode prikazuje, kako pridobiti referenco na spletno storitev, ki temelji na J2EE, prek iskanja JNDI:
InitialContext ctx = nov InitialContext (); Storitev myService = (Storitev) ctx.lookup ("java: comp / env / services / MyWebService"); Zgornja koda pridobi generični objekt storitve: objekt brez določene vrste. Do storitve, ustvarjene z JAX-RPC, se dostopa na enak način, tokrat pa se storitev odda v vrsto vmesnika določene spletne storitve:
InitialContext ctx = nov InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Upoštevajte, da ta koda predvideva, da MyWebService sklic se veže na objekt, ki izvaja MyWebService vmesnik. Ker je vezava storitev olajšana v času uvajanja spletne storitve, naj bi orodja J2EE zagotovila to doslednost. Vsi aplikacijski strežniki, skladni z J2EE 1.4, morajo podpirati iskanje storitev na osnovi JNDI.
Ko stranka pridobi spletno storitev Storitev predmeta, lahko s tem predmetom pridobi a javax.xml.rpc.Call primerek, ki izvede dejanski priklic storitve. Naročnik ima tri možnosti za pridobitev Pokliči: prek klica, dinamičnega strežnika proxy ali DII (vmesnik dinamičnega klica). V tem članku ne bom razpravljal o razlikah med temi metodami, ne glede na to, kako Pokliči je ustvarjeno, to Pokliči se nanaša neposredno na vrata storitve - edini predmet, na katerega se mora zavedati odjemalec, ko prikliče spletno storitev. Vsi zabojniki, skladni z J2EE 1.4, morajo podpirati Storitev vmesniške metode in tako omogoči odjemalcu, da pridobi referenco na Pokliči predmet za spletno storitev in na vrata te storitve prek Pokliči.
Upoštevajte, da v nasprotju z uporabo JAX-RPC zunaj J2EE odjemalec ne sme uporabljati JAX-RPC ServiceFactory razred za pridobitev nove storitve. Namesto tega mora stranka dobiti dostop do Storitev iz vira, ki temelji na JNDI, saj bo imel sklic na storitev, pridobljeno iz JNDI, vse nastavitve in konfiguracije, potrebne za klicanje določenega primerka storitve. Z vidika stranke je ta razlika nekoliko podobna načinu, kako odjemalec J2EE pridobi JDBC Vir podatkov prek vmesnika JNDI za dostop do baze podatkov, namesto da bi ročno konfigurirali JDBC Povezava primer.
S tem Pokliči predmeta na mestu, odjemalec sledi semantiki JAX-RPC oddaljenega klica postopka. Na primer, odjemalec lahko uporabi prikliči () metoda za to Pokliči za interakcijo s spletno storitvijo. (Za primer priklica storitve v slogu JAX-RPC glejte "Všeč mi je vaš tip: Opiši in prikliči spletne storitve glede na vrsto storitve" (JavaWorld, September 2002).)
Model programiranja strežnika spletnih storitev
Spletna storitev, ki temelji na J2EE, lahko sledi eni od dveh možnih izvedb: Če je storitev izvedena kot običajni razred Java, mora ustrezati zahtevam vsebnika strežniškega programčka JAX-RPC. Če pa je storitev opredeljena za izvajanje v vsebniku EJB, mora slediti programskemu modelu, ki se zahteva za seje EJB brez stanja. Ne glede na način izvedbe vsak vsebnik zagotavlja izvedbo spletne storitve s podporo za življenjski cikel, upravljanje sočasnosti in varnostno infrastrukturo.
Primarna odgovornost vsebnika strežnika J2EE je preslikati in poslati zahteve SOAP, v primeru EJB, fižolom sej brez stanja in, v primeru vsebnika strežniškega programčka, metodam v razredih končnih točk storitve JAX-RPC. Medtem ko specifikacija JAX-RPC opredeljuje programski model za slednjo možnost, spletne storitve J2EE JSR (JSR 109) opisujejo analogen model za fižol seje EJB brez državljanstva.
