Programmering

J2EE 1.4 letter utviklingen av webtjenester

Ved avslutningen av sin J2EE (Java 2 Platform, Enterprise Edition) webtjenestepresentasjon på fjorårets JavaOne, bemerket IBM-arkitekten Jim Knutson at "hver webtjeneste trenger et sted å være en tjeneste." Han foreslo da at det mest ideelle stedet å være en nettjeneste var inne i J2EE-infrastrukturen. Litt mer enn et år senere er den endelige utgivelsen av J2EE 1.4 nært forestående, og dens viktigste løfte er å levere visjonen om J2EE Web-tjenester.

Webtjenestefunksjonene i J2EE 1.4 adresserer både server- og klientsiden til webtjenester. Funksjonene utvider J2EE slik at eksisterende Java-komponentene på serversiden kan bli webtjenester og spesifisere hvordan en J2EE-klientcontainer kan påkalle webtjenester. Teknologiene for begge mål har eksistert en stund, og de nye J2EE-spesifikasjonene er avhengige av de eksisterende API-ene for støtte for webtjenester. De nye spesifikasjonene legger til eksisterende teknologier et sett med krav til interoperabilitet og en programmerings- og distribusjonsmodell for integrering av webtjenester.

Det er to spesifikasjoner som eksplisitt skisserer de tilleggsfunksjonene: Java Specification Request 151, paraplyen JSR for J2EE 1.4 og JSR 109, Web Services for J2EE. I skrivende stund har JSR 109 nådd sin siste fase i JCP (Java Community Process), mens JSR 151 er i den siste avstemningsfasen. I tillegg endret JCP den endelige versjonen av JSR 101, Java API-er for XML-basert Remote Procedure Call (JAX-RPC), for å støtte J2EE 1.4-interoperasjonskrav.

J2EE 1.3-nivå applikasjonsservere kan også implementere mange av funksjonene som er foreskrevet av disse JSR-ene. Faktisk har mange applikasjonsserverleverandører støttet ulike utvikling av webtjenester og distribusjonsfunksjoner i sine eksisterende produkter i noen tid nå. JSR 109 og 151 kodifiserer noen eksisterende fremgangsmåter og beskriver nye mekanismer med håp om å skape en universell J2EE-webtjenesteintegrasjonsmodell. Neste generasjons applikasjonsservere vil trolig følge den enhetlige, standardiserte modellen.

Etter en kort oversikt over nye webtjenerelaterte J2EE-funksjoner, gjennomgår denne artikkelen de nye klient- og serverprogrammeringsmodellene, inkludert nye J2EE-distribusjons- og tjenesteadministrasjonsroller knyttet til støtte for webtjenester.

Webtjenerelaterte J2EE-utvidelser

Kanskje det mest betydningsfulle og mest konsekvente tilskuddet til J2EE er de nye kravene til interoperasjon. Kravene foreskriver støtte for SOAP (Simple Object Access Protocol) 1.1 i J2EE-presentasjonslaget for å lette XML-meldingsutveksling. J2EE 1.4-kompatible containere må også støtte WS-I (Web Services Interoperability Consortium) Basic Profile. Siden XML-meldingsutveksling i J2EE avhenger av JAX-RPC, krever JAX-RPC-spesifikasjonene nå også støtte for WS-I Basic Profile.

Resultatet er at en J2EE 1.4-basert applikasjon kan påberopes som en webtjeneste, selv fra applikasjoner som ikke er skrevet på Java-programmeringsspråket. Selv om det er et evolusjonært trinn for J2EE, siden plattformen lenge har omfavnet ikke-Java-baserte systemer, er det muligens den mest direkte måten å legge til rette for interaksjon med Windows-baserte teknologier som er avhengige av .Net.

En J2EE-basert tjenestes klient trenger ikke å være klar over hvordan en tjeneste implementeres. Snarere kan den klienten bruke tjenesten ved å stole helt på tjenestens WSDL-definisjon (Web Services Description Language). (Tidligere JavaWorldNettjenester kolonnene forklarer hvordan du oppdager tjenester basert på WSDL-definisjonene, og hvordan du oppretter og bruker WSDL-definisjoner. Se ressurser for lenker.) Selv om J2EE-spesifikasjonene ikke angir den nøyaktige mekanikken til slik interaksjon, vil J2EE 1.4s omfavnelse av WS-I Basic Profile, som Microsoft også hevder å følge, sannsynligvis gjøre J2EE-.Net-interaksjon vanlig. .

For å lette tilgangen til WSDL-definisjoner, legger J2EE 1.4 til støtte for JAXR (Java API for XML Registries) -standarden. JAXR-bibliotekene er nå en nødvendig del av J2EE-applikasjonsklienten, EJB (Enterprise JavaBeans) og webcontainere (ikke appletbeholderen, skjønt). Siden WS-I Basic Profile krever støtte for UDDI (Universal Description, Discovery, and Integration) 2.0, kan J2EE-klienter, så vel som EJB-komponenter og servlets, samhandle med offentlige webtjenesteregister. ("Web Services Take Float with JAXR" (JavaWorld, Mai 2002) tilbyr en veiledning om JAXR.) Figur 1 illustrerer tilleggsnettbaserte biblioteker som støttes av J2EE 1.4.

J2EE mener faktisk at en webtjeneste er en implementering av ett eller flere grensesnitt definert av et WSDL-dokument. Operasjonene beskrevet i WSDL blir først kartlagt til Java-metoder i henhold til JAX-RPC-spesifikasjonens WSDL-til-Java-kartleggingsregler. Når et Java-grensesnitt som tilsvarer en WSDL-fil er definert, kan du implementere grensesnittets metoder på en av to måter: som en statsløs øktbønne som kjører i EJB-beholderen eller som en Java-klasse som kjører i J2EE-servletbeholderen. Til slutt ordner du at den respektive beholderen lytter etter innkommende SOAP-forespørsler og kartlegger disse forespørslene til den respektive implementeringen (EJB eller servlet). For å behandle innkommende SOAP-påkallinger, gir J2EE 1.4 mandat til JAX-RPC-kjøretiden som en ekstra J2EE-containertjeneste.

I tråd med J2EE-arkitekturen formidler en tjenesteimplementeringscontainer tilgang til en webtjeneste: Hvis du avslører enten en EJB-komponent eller en servlet som en J2EE-webtjeneste, kan tjenestens klienter påberope seg tjenesten bare indirekte via containeren. Dette gjør at en tjenesteimplementering kan dra nytte av containerens sikkerhet, trådadministrasjon og til og med servicekvalitet. I tillegg lar containere deg ta viktige beslutninger om webtjenester, for eksempel sikkerhetsbegrensninger, ved distribusjonstidspunktet. Til slutt gjør J2EEs containerbaserte modell distribusjon av webtjenester bærbar: du kan utvikle en Java-basert webtjeneste ved hjelp av hvilket som helst J2EE-verktøy og forvente at tjenesten skal kjøre i en hvilken som helst annen kompatibel implementering av container.

En webtjenesteklient er derimot uvitende om tilstedeværelsen til en webservicecontainer. I stedet ser klienten a havn som representerer en nettverksendepunktforekomst av en webtjeneste. Dette endepunktet følger JAX-RPC tjenestens endepunktgrensesnitt (SEI) -modell og gir en implementering av tjenestens grensesnitt. En klient ser på hver J2EE-nettjeneste som en SEI- og portkombinasjon. En enkelt J2EE-container kan være vert for mange slike kombinasjoner, som figur 2 illustrerer. Hver SEI / portkombinasjon er en forekomst av en webtjeneste.

Merk at klienten i denne arkitekturen kan være enten en J2EE-klient, som kjører inne i J2EE-klientcontaineren, eller en ikke-J2EE-klient. Enhver WS-I Basic-profil-kompatibel klient kan bruke en J2EE-webtjeneste, men hver klient kan følge forskjellige programmeringsmodeller. J2EE Web Services-spesifikasjonen skisserer en programmeringsmodell for klienter som kjører inne i J2EE-applikasjonsklientcontaineren, og en annen modell - serverprogrammeringsmodellen - for implementering av webtjenester som kjøres i EJB- eller servletcontainere.

Programmeringsmodellen for J2EE Web Service Client

Essensen av Web Service-klientprogrammeringsmodellen er å effektivisere bruken av APIer definert i JSRs 67 (Java APIs for XML Messaging, JAXM), 93 (JAXR) og 101 (JAX-RPC), og å gi et omfattende rammeverk for bruker disse API-ene sammen i J2EE-klientbeholderen.

I tråd med J2EE-klientprogrammeringsmodellen er en webtjenesteklient ekstern og gir lokal / ekstern gjennomsiktighet. Webtjenesteportleverandøren og containeren som porten kjører i definerer hvordan en klient ser en webtjeneste. Klienten får alltid tilgang til porten og får aldri direkte referanse til implementeringen av en webtjeneste. En J2EE-webtjenesteklient forblir uvitende om hvordan en port fungerer, og må bare være opptatt av metodene en port definerer. Disse metodene utgjør en nettjenestes offentlige grensesnitt. I tillegg må en klient vurdere tilgang til en webtjenesteport som statsløs på tvers av tjenesteanrop. Når det gjelder klienten, mangler en port en unik identitet - en klient har ingen måte å avgjøre om den kommuniserer med identiske porter på tvers av tjenesteanrop.

Klienten får tilgang til en port basert på portens tjenestegrensesnitt. J2EE Web-tjenester er avhengige av JAX-RPC for å definere forholdet mellom en port og dens tjenestegrensesnitt. JAX-RPC oppretter det forholdet basert på WSDL-behandlingsregler. Dermed styrer nettjenestens WSDL-definisjon til slutt havnens oppførsel. Basert på JAX-RPC-definisjonen, kan tjenestegrensesnittet enten være et generisk grensesnitt som direkte implementerer javax.xml.rpc.Service grensesnitt, eller en "generert tjeneste", som er en undertype av grensesnittet. Sistnevnte grensesnitttype er spesifikk for typen webtjeneste.

I J2EE-programmeringsmodellen får klienten en referanse til en webtjeneste Service objekt via en JNDI-oppslagsoperasjon (Java Naming and Directory Interface). JNDI-oppslaget skjer med et logisk navn, eller tjenestereferanse, for nettjenesten. Som med alle katalogbaserte ressurser, må en klient erklære hvilke ressurser den trenger i distribusjonsbeskrivelsen (mer om det senere).

Java Web Services-spesifikasjonen (JSR 109) anbefaler at alle webtjenester blir underlagt JNDI service underkontekst. Klientcontaineren binder servicegrensesnittet beskrevet av referansen under java: comp / env klientmiljø navnekontekst. Ved å erklære en tjenestereferanse i klientens distribusjonsbeskrivelse, sørger klientcontaineren for at den refererte tjenesten er tilgjengelig i JNDI-bevisste ressurser. Følgende kodebit viser hvordan du får en referanse til en J2EE-basert nettjeneste via JNDI-oppslag:

 InitialContext ctx = ny InitialContext (); Tjeneste myService = (Service) ctx.lookup ("java: comp / env / services / MyWebService"); 

Ovennevnte kode får et generisk tjenesteobjekt: et objekt uten en spesifikk type. En JAX-RPC-generert tjeneste er tilgjengelig på samme måte, denne gangen kaster tjenesten til den spesifikke nettjenestens grensesnittstype:

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

Merk at denne koden forutsetter at MyWebService referanse binder til et objekt som implementerer MyWebService grensesnitt. Siden tjenestebinding tilrettelegges på distribusjonstidspunktet til en nettjeneste, forventes J2EE-verktøy å sikre konsistensen. Alle J2EE 1.4-kompatible applikasjonsservere må støtte JNDI-basert tjenestesøk.

Når en klient får en webtjeneste Service objekt, kan den bruke det objektet til å hente et javax.xml.rpc.Call forekomst som utfører selve tjenesteanropet. Kunden har tre muligheter for å skaffe seg en Anrop: via en stub, en dynamisk tjenesteproxy eller et DII (Dynamic Invocation Interface). Jeg vil ikke diskutere forskjellene mellom disse metodene i denne artikkelen siden, uavhengig av hvordan en Anrop er skapt, det Anrop henviser direkte tilbake til tjenestens port - det eneste objektet klienten må være klar over når de påkaller nettjenesten. Alle J2EE 1.4-kompatible containere må støtte Service grensesnittmetoder, og dermed tillate en klient å få en referanse til en Anrop objekt for en webtjeneste, og til tjenestens port, via Anrop.

Merk at i motsetning til bruk av JAX-RPC utenfor J2EE, bør en klient ikke bruke JAX-RPC ServiceFactory klasse for å få en ny tjeneste. I stedet bør klienten få tilgang til Service fra en JNDI-basert kilde, siden referanse til en tjeneste hentet fra JNDI vil ha alle innstillinger og konfigurasjoner som er nødvendige for å påkalle den bestemte tjenesteinstansen. Fra en klients synspunkt er denne forskjellen noe analog med hvordan en J2EE-klient henter en JDBC Datakilde via JNDI-grensesnittet for å få tilgang til en database, i stedet for å konfigurere en JDBC manuelt Forbindelse forekomst.

Med det Anrop objektet på plass, følger klienten JAX-RPC-semantikken for ekstern prosedyreinnkalling. For eksempel kan klienten bruke påkalle () metode på det Anrop for å samhandle med nettjenesten. (For et eksempel på JAX-RPC-stil tjenesteanrop, se "Jeg liker din type: Beskriv og påkall webtjenester basert på tjenestetype" (JavaWorld, September 2002).)

Webtjenerens serverprogrammeringsmodell

En J2EE-basert webtjeneste kan følge en av to mulige implementeringer: Hvis tjenesten implementeres som en vanlig Java-klasse, må den være i samsvar med JAX-RPC servletbeholderens krav. Eller hvis tjenesten er definert til å utføre i EJB-containeren, må den følge programmeringsmodellen som kreves av statsløse EJB-sesjonsbønner. Uansett implementeringsmetode gir hver container implementeringen av webtjenesten med livssyklusstøtte, samtidig administrasjon og en sikkerhetsinfrastruktur.

J2EE-servercontainerens hovedansvar er å kartlegge og sende SOAP-forespørsler, i EJB-saken, til statsløse sesjonsbønner, og, i servletcontainer-saken, til metoder i JAX-RPC-tjenesteslutpunktklasser. Mens JAX-RPC-spesifikasjonen definerer en programmeringsmodell for sistnevnte alternativ, skisserer J2EE Web-tjenester JSR (JSR 109) en analog modell for statsløse EJB-sesjonsbønner.

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