Ved afslutningen af sin J2EE (Java 2 Platform, Enterprise Edition) præsentation af webservices på sidste års JavaOne bemærkede IBM-arkitekt Jim Knutson, at "enhver webtjeneste har brug for et sted for at være en tjeneste." Han foreslog derefter, at det mest ideelle sted at være en webtjeneste var inde i J2EE-infrastrukturen. Lidt mere end et år senere er den endelige frigivelse af J2EE 1.4 nært forestående, og dens mest betydningsfulde løfte er at levere J2EE's webtjeneste vision.
Webtjenestefunktionerne i J2EE 1.4 adresserer både server- og klientsiden af webservices. Funktionerne udvider J2EE, så eksisterende Java-komponenter på serversiden kan blive webtjenester og specificere, hvordan en J2EE-klientcontainer kan påberåbe sig webtjenester. Teknologierne til begge mål har eksisteret i et stykke tid, og de nye J2EE-specifikationer er afhængige af de eksisterende API'er til understøttelse af webtjenester. De nye specifikationer tilføjer til de eksisterende teknologier et sæt interoperabilitetskrav og en programmerings- og implementeringsmodel til integration af webservices.
Der er to specifikationer, der eksplicit skitserer de tilføjede funktioner: Java Specification Request 151, paraplyen JSR til J2EE 1.4 og JSR 109, Web Services til J2EE. På dette tidspunkt er JSR 109 nået sin sidste fase i JCP (Java Community Process), mens JSR 151 er i den sidste afstemningsfase. Derudover ændrede JCP den endelige frigivelse af JSR 101, Java API'er til XML-baseret Remote Procedure Call (JAX-RPC), for at understøtte J2EE 1.4-interoperationskrav.
J2EE 1.3-applikationsservere kan også implementere mange af de funktioner, der er foreskrevet af disse JSR'er. Faktisk har mange applikationsserverudbydere understøttet forskellige webtjenesteudviklings- og implementeringsfunktioner i deres eksisterende produkter i nogen tid nu. JSR'er 109 og 151 kodificerer nogle eksisterende praksis og beskriver nye mekanismer med håb om at skabe en universel J2EE-webtjenesteintegrationsmodel. Næste generations applikationsservere vil sandsynligvis følge den samlede standardiserede model.
Efter en kort oversigt over nye webservicerelaterede J2EE-funktioner gennemgår denne artikel de nye klient- og serverprogrammeringsmodeller, herunder nye J2EE-implementerings- og servicestyringsroller, der er knyttet til webservicesupport.
Webservicerelaterede J2EE-udvidelser
Måske den mest betydningsfulde og mest konsekvent tilføjelse til J2EE er de nye krav til interoperation. Kravene foreskriver understøttelse af SOAP (Simple Object Access Protocol) 1.1 i J2EE-præsentationslaget for at lette XML-meddelelsesudveksling. J2EE 1.4-kompatible containere skal også understøtte WS-I (Web Services Interoperability Consortium) Basic Profile. Da XML-meddelelsesudveksling i J2EE afhænger af JAX-RPC, kræver JAX-RPC-specifikationerne nu også support til WS-I Basic Profile.
Resultatet er, at en J2EE 1.4-baseret applikation kan påberåbes som en webservice, selv fra applikationer, der ikke er skrevet på Java-programmeringssproget. Selvom det er et evolutionært skridt for J2EE, da platformen længe har omfavnet ikke-Java-baserede systemer, er det muligvis den mest direkte måde at lette interaktion med Windows-baserede teknologier, der er afhængige af .Net.
En J2EE-baseret services klient behøver ikke at være opmærksom på, hvordan en service implementeres. Snarere kan denne klient bruge tjenesten ved helt at stole på tjenestens WSDL-definition (Web Services Description Language). (Tidligere JavaWorldWebtjenester kolonner forklarer, hvordan man finder tjenester baseret på deres WSDL-definitioner, og hvordan man opretter og bruger WSDL-definitioner. Se ressourcer for links.) Selvom J2EE-specifikationerne ikke præciserer den nøjagtige mekanik for en sådan interaktion, vil J2EE 1.4's omfavnelse af WS-I Basic-profilen, som Microsoft også hævder at følge, sandsynligvis gøre J2EE-.Net-interaktion almindelig. .
For at lette adgangen til WSDL-definitioner tilføjer J2EE 1.4 understøttelse af JAXR (Java API for XML Registries) -standarden. JAXR-bibliotekerne er nu en påkrævet del af J2EE-applikationsklienten, EJB (Enterprise JavaBeans) og webcontainere (dog ikke appletbeholderen). Da WS-I Basic Profile pålægger support til UDDI (Universal Description, Discovery and Integration) 2.0, kan J2EE-klienter samt EJB-komponenter og servlets interagere med offentlige webservicesregistre. ("Webtjenester flyder med JAXR" (JavaWorld, Maj 2002) tilbyder en tutorial om JAXR.) Figur 1 illustrerer de yderligere webservicerelaterede biblioteker, der understøttes af J2EE 1.4.
Faktisk er J2EE af den opfattelse, at en webtjeneste er en implementering af en eller flere grænseflader defineret af et WSDL-dokument. De operationer, der er beskrevet i WSDL, kortlægges først til Java-metoder efter JAX-RPC-specifikationens WSDL-til-Java-kortlægningsregler. Når en Java-grænseflade, der svarer til en WSDL-fil, er defineret, kan du implementere grænsefladens metoder på en af to måder: som en statsløs session bønne, der kører i EJB-containeren eller som en Java-klasse, der kører i J2EE-servletcontaineren. Endelig sørger du for, at den respektive container lytter til indgående SOAP-anmodninger og kortlægger disse anmodninger til den respektive implementering (EJB eller servlet). For at behandle indgående SOAP-påkald, mandaterer J2EE 1.4 JAX-RPC-runtime som en ekstra J2EE-containertjeneste.
I overensstemmelse med J2EE-arkitekturen formidler en serviceimplementeringscontainer adgang til en webtjeneste: Hvis du udsætter enten en EJB-komponent eller en servlet som en J2EE-webtjeneste, kan din services klienter kun påberåbe sig denne tjeneste indirekte via containeren. Dette gør det muligt for en serviceimplementering at drage fordel af containerens sikkerhed, trådadministration og endda servicekvalitetsgarantier. Derudover giver containere dig mulighed for at tage vigtige webservicebeslutninger, såsom sikkerhedsbegrænsninger, ved implementeringstidspunktet. Endelig gør J2EEs containerbaserede model implementering af webservices bærbar: du kan udvikle en Java-baseret webtjeneste ved hjælp af ethvert J2EE-værktøj og forvente, at tjenesten kører i enhver anden kompatibel implementering af containere.
En webserviceklient er derimod uvidende om en webservicecontainers tilstedeværelse. I stedet ser klienten en Havn repræsenterer en netværksslutpunktsforekomst af en webtjeneste. Dette slutpunkt følger JAX-RPC service slutpunkt interface (SEI) -model og giver en implementering af tjenestens grænseflade. En klient ser hver J2EE-webservice som en SEI- og portkombination. En enkelt J2EE-container kan være vært for mange sådanne kombinationer, som figur 2 illustrerer. Hver SEI / portkombination er en forekomst af en webservice.
Bemærk, at klienten i denne arkitektur kan enten være en J2EE-klient, der kører inde i J2EE-klientcontaineren, eller en ikke-J2EE-klient. Enhver WS-I Basic-profil-kompatibel klient kan bruge en J2EE-webservice, men hver klient kan følge forskellige programmeringsmodeller. J2EE Web Services-specifikationen skitserer en programmeringsmodel for klienter, der kører inde i J2EE-applikationsklientcontaineren, og en anden model - serverprogrammeringsmodellen - til implementering af webservices, der udføres i EJB- eller servletcontainere.
J2EE-webserviceklientprogrammeringsmodellen
Essensen af Web Service-klientprogrammeringsmodellen er at strømline brugen af API'er defineret i JSRs 67 (Java API'er til XML Messaging, JAXM), 93 (JAXR) og 101 (JAX-RPC) og at give en omfattende ramme for ved hjælp af disse API'er sammen i J2EE-klientcontaineren.
I overensstemmelse med J2EE-klientprogrammeringsmodellen er en webserviceklient fjernbetjenbar og giver lokal / fjern gennemsigtighed. Webtjenesteudbyder og containeren, som porten kører i, definerer, hvordan en klient ser en webservice. Klienten får altid adgang til porten og får aldrig direkte en henvisning til implementeringen af en webservice. En J2EE-webserviceklient forbliver uvidende om, hvordan en port fungerer, og må kun beskæftige sig med de metoder, en port definerer. Disse metoder udgør en webservices offentlige grænseflade. Derudover skal en klient betragte adgangen til en webserviceport som statsløs på tværs af serviceopkald. Hvad klienten angår, mangler en port en unik identitet - en klient har ingen måde at afgøre, om den kommunikerer med identiske porte på tværs af tjenesteanmeldelser.
Klienten får adgang til en port baseret på portens serviceinterface. J2EE-webtjenester er afhængige af JAX-RPC for at definere forholdet mellem en port og dens serviceinterface. JAX-RPC skaber dette forhold baseret på WSDL-behandlingsregler. Webtjenestens WSDL-definition styrer således i sidste ende havnens adfærd. Baseret på JAX-RPC-definitionen kan serviceinterfacet enten være en generisk interface, der direkte implementerer javax.xml.rpc.Service interface eller en "genereret tjeneste", som er en undertype af denne grænseflade. Sidstnævnte interfacetype er specifik for en webservices type.
I J2EE-programmeringsmodellen får klienten en henvisning til en webservices Service objekt via en JNDI-opslagsfunktion (Java Naming and Directory Interface). JNDI-opslag sker med et logisk navn, eller servicehenvisning, til webtjenesten. Som med alle biblioteksbaserede ressourcer skal en klient erklære, hvilke ressourcer den har brug for i sin installationsbeskrivelse (mere om det senere).
Java Web Services-specifikationen (JSR 109) anbefaler, at alle webtjenester underordnes under JNDI service underkontekst. Klientcontaineren binder servicegrænsefladen beskrevet af denne reference under java: comp / env klientmiljø navngivning kontekst. Ved at erklære en servicehenvisning i klientens installationsbeskrivelse sikrer klientcontaineren, at den refererede tjeneste er tilgængelig i JNDI-opmærksomme ressourcer. Følgende kodestykke viser, hvordan man får en reference til en J2EE-baseret webtjeneste via JNDI-opslag:
InitialContext ctx = ny InitialContext (); Service myService = (Service) ctx.lookup ("java: comp / env / services / MyWebService"); Ovenstående kode får et generisk serviceobjekt: et objekt uden en bestemt type. En JAX-RPC-genereret tjeneste tilgås på samme måde, denne gang kaster tjenesten til den specifikke webtjenestes interface-type:
InitialContext ctx = ny InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Bemærk, at denne kode forudsætter, at MyWebService reference binder til et objekt, der implementerer MyWebService interface. Da servicebinding letter på en webservices implementeringstid, forventes J2EE-værktøjer at sikre denne konsistens. Alle J2EE 1.4-kompatible applikationsservere skal understøtte JNDI-baseret serviceopslag.
Når en klient får en webtjeneste Service objekt, kan det bruge objektet til at hente et javax.xml.rpc.Call forekomst, der udfører den faktiske serviceopfordring. Kunden har tre muligheder for at få en Opkald: via en stub, en dynamisk serviceproxy eller en DII (Dynamic Invocation Interface). Jeg diskuterer ikke i denne artikel forskellene mellem disse metoder siden, uanset hvordan en Opkald er skabt, det Opkald henviser direkte tilbage til tjenestens port - det eneste objekt, klienten skal være opmærksom på, når han påberåber sig webservicen. Alle J2EE 1.4-kompatible containere skal understøtte Service grænseflademetoder, og således tillade en klient at få en reference til en Opkald objekt til en webtjeneste og til denne tjenestes port via Opkald.
Bemærk, at i modsætning til brug af JAX-RPC uden for J2EE, bør en klient ikke bruge JAX-RPC ServiceFabrik klasse for at få en ny service. I stedet skal klienten få adgang til Service fra en JNDI-baseret kilde, da henvisning til en tjeneste, der hentes fra JNDI, vil have alle de indstillinger og konfigurationer, der er nødvendige for at påkalde den bestemte tjenesteinstans. Fra en klients synspunkt er forskellen noget analog med, hvordan en J2EE-klient henter en JDBC Datakilde via JNDI-grænsefladen for at få adgang til en database i stedet for manuelt at konfigurere en JDBC Forbindelse eksempel.
Med det Opkald objekt på plads, følger klienten JAX-RPC-semantikken ved fjernprocedurkald. For eksempel bruger klienten muligvis påkalde () metode på det Opkald at interagere med webservicen. (Se "Jeg kan lide din type: Beskriv og påkald webservices baseret på servicetype" (for et eksempel på JAX-RPC-stil serviceopkald) (JavaWorld, September 2002).)
Webtjenesteserverprogrammeringsmodellen
En J2EE-baseret webtjeneste kan følge en af to mulige implementeringer: Hvis tjenesten implementeres som en almindelig Java-klasse, skal den overholde kravene til JAX-RPC-servletcontaineren. Eller hvis tjenesten er defineret til at udføre i EJB-containeren, skal den følge den programmeringsmodel, der kræves af statsløse EJB-sessionbønner. Uanset implementeringsmetode leverer hver container webtjenesteimplementeringen med livscyklusstøtte, samtidig styring og en sikkerhedsinfrastruktur.
J2EE-servercontainerens primære ansvar er at kortlægge og sende SOAP-anmodninger i EJB-sagen til statsløse sessionbønner og i servletcontainer-sagen til metoder i JAX-RPC-serviceendepunktsklasser. Mens JAX-RPC-specifikationen definerer en programmeringsmodel for sidstnævnte mulighed, skitserer J2EE-webtjenesterne JSR (JSR 109) en analog model for statsløse EJB-sessionbønner.
