Viime vuoden JavaOne-palvelussa J2EE (Java 2 Platform, Enterprise Edition) -verkkopalveluesittelynsä päätteeksi IBM: n arkkitehti Jim Knutson huomautti, että "jokainen verkkopalvelu tarvitsee paikan palveluksi". Sitten hän ehdotti, että ihanteellisin paikka olla verkkopalvelu oli J2EE-infrastruktuurin sisällä. Hieman yli vuotta myöhemmin J2EE 1.4: n viimeinen julkaisu on välitön, ja sen merkittävin lupaus on toteuttaa J2EE-verkkopalveluvisio.
J2EE 1.4: n verkkopalveluominaisuudet osoittavat sekä verkkopalvelujen palvelin- että asiakaspuolet. Ominaisuudet laajentavat J2EE: tä, jotta nykyiset palvelinpuolen yritys Java-komponentit voivat tulla verkkopalveluiksi, ja määritetään, miten J2EE-asiakassäiliö voi kutsua verkkopalveluja. Molempien tavoitteiden tekniikat ovat olleet jo jonkin aikaa, ja uudet J2EE-tekniset tiedot tukeutuvat olemassa oleviin sovellusliittymiin verkkopalvelujen tueksi. Uudet tiedot lisäävät nykyisiin tekniikoihin joukon yhteentoimivuusvaatimuksia sekä ohjelmointi- ja käyttöönottomallin verkkopalvelujen integrointia varten.
On kaksi eritelmää, jotka hahmottavat nimenomaisesti nämä lisätyt ominaisuudet: Java-määrityspyyntö 151, sateenvarjo JSR for J2EE 1.4 ja JSR 109, Web Services for J2EE. Tämän kirjoituksen aikaan JSR 109 on saavuttanut viimeisen vaiheensa JCP: ssä (Java Community Process), kun taas JSR 151 on viimeisessä äänestysvaiheessa. Lisäksi JCP muutti JSR 101: n, Java-sovellusliittymien XML-pohjaisen etäprosessipuhelun (JAX-RPC) lopullista julkaisua tukemaan J2EE 1.4 -yhteistyövaatimuksia.
J2EE 1.3 -tason sovelluspalvelimet voivat myös toteuttaa monia näiden JSR: n määrittelemiä ominaisuuksia. Itse asiassa monet sovelluspalvelimien toimittajat ovat jo jonkin aikaa tukeneet nykyisten tuotteidensa verkkopalvelujen kehittämistä ja käyttöönottoa. JSR: t 109 ja 151 kodifioivat joitain olemassa olevia käytäntöjä ja kuvaavat uusia mekanismeja toivomalla luoda universaali J2EE-Web-palveluiden integrointimalli. Seuraavan sukupolven sovelluspalvelimet seuraavat todennäköisesti tätä yhtenäistä, standardoitua mallia.
Lyhyen kyselyn jälkeen uusista verkkopalveluihin liittyvistä J2EE-ominaisuuksista tässä artikkelissa tarkastellaan uusia asiakas- ja palvelinohjelmointimalleja, mukaan lukien uudet J2EE-käyttöönotto- ja palvelunhallintaroolit, jotka liittyvät verkkopalveluiden tukeen.
Verkkopalveluihin liittyvät J2EE-laajennukset
Ehkä merkittävimmät ja seurannaisimmat lisäykset J2EE: hen ovat uudet yhteistyövaatimukset. Vaatimukset edellyttävät J2EE-esityskerroksen SOAP (Simple Object Access Protocol) 1.1 -tukea XML-sanomanvaihdon helpottamiseksi. J2EE 1.4 -yhteensopivien säilöjen on tuettava myös WS-I (Web Services Interoperability Consortium) -profiilia. Koska XML-sanomanvaihto J2EE: ssä riippuu JAX-RPC: stä, JAX-RPC-spesifikaatiot edellyttävät nyt myös WS-I Basic Profile -tukea.
Tuloksena on, että J2EE 1.4 -pohjainen sovellus voidaan kutsua verkkopalveluksi, jopa sovelluksista, joita ei ole kirjoitettu Java-ohjelmointikielellä. Vaikka tämä on J2EE: lle evoluutiovaihe, koska alusta on pitkään omaksunut muut kuin Java-pohjaiset järjestelmät, se on mahdollisesti suorin tapa helpottaa vuorovaikutusta .Net-verkkoon perustuvien Windows-pohjaisten tekniikoiden kanssa.
J2EE-pohjaisen palvelun asiakkaan ei tarvitse olla tietoinen siitä, miten palvelu toteutetaan. Asiakas voi pikemminkin käyttää palvelua luottaen täysin palvelun WSDL (Web Services Description Language) -määritykseen. (Edellinen JavaWorldWeb palvelut sarakkeissa selitetään, miten palveluita löydetään niiden WSDL-määritysten perusteella ja miten luodaan ja käytetään WSDL-määritelmiä. Katso linkit lähteistä.) Vaikka J2EE-tiedot eivät täsmennä tällaisen vuorovaikutuksen tarkkaa mekaniikkaa, J2EE 1.4: n omaksuma WS-I-perusprofiili, jota Microsoft väittää myös noudattavan, tekee todennäköisesti J2EE-.Net-vuorovaikutuksesta yleisen. .
WSDL-määritelmien käytön helpottamiseksi J2EE 1.4 lisää tuen JAXR (Java API for XML Registries) -standardille. JAXR-kirjastot ovat nyt pakollinen osa J2EE-sovellusasiakasta, EJB: tä (Enterprise JavaBeans) ja verkkosäiliöitä (ei kuitenkaan applettisäiliötä). Koska WS-I Basic Profile edellyttää UDDI (Universal Description, Discovery and Integration) 2.0 -tukea, J2EE-asiakkaat, samoin kuin EJB-komponentit ja servletit, voivat olla vuorovaikutuksessa julkisten verkkopalvelurekistereiden kanssa. ("Verkkopalvelut levittävät JAXR: n kanssa" (JavaWorld, Toukokuu 2002) tarjoaa opetusohjelman JAXR: stä.) Kuva 1 havainnollistaa J2EE 1.4: n tukemia muita verkkopalveluihin liittyviä kirjastoja.
J2EE katsoo, että verkkopalvelu on yhden tai useamman WSDL-asiakirjan määrittämän rajapinnan toteutus. WSDL: ssä kuvatut toiminnot kartoitetaan ensin Java-menetelmiin JAX-RPC-määrityksen WSDL-Java-määrityssääntöjen mukaisesti. Kun WSDL-tiedostoa vastaava Java-käyttöliittymä on määritelty, voit toteuttaa kyseisen käyttöliittymän menetelmät kahdella tavalla: valtiottomana istuntopapuna, joka toimii EJB-säilössä, tai Java-luokassa, joka toimii J2EE-palvelinsäiliössä. Lopuksi järjestät, että vastaava säilö kuuntelee saapuvia SOAP-pyyntöjä ja kartoittaa nämä pyynnöt vastaavaan toteutukseen (EJB tai servlet). Saapuvien SOAP-kutsujen käsittelemiseksi J2EE 1.4 valtuuttaa JAX-RPC-ajonaikana ylimääräisenä J2EE-konttipalveluna.
J2EE-arkkitehtuurin mukaisesti palvelun toteutuksen säilö välittää pääsyn verkkopalveluun: Jos paljastat joko EJB-komponentin tai servletin J2EE-verkkopalveluna, palvelusi asiakkaat voivat kutsua kyseistä palvelua vain epäsuorasti säilön kautta. Tämän avulla palvelun toteutus voi hyötyä kontin tietoturvasta, säikeiden hallinnasta ja jopa palvelun laadun takaamisesta. Lisäksi konttien avulla voit tehdä tärkeitä verkkopalvelupäätöksiä, kuten suojausrajoituksia, käyttöönoton yhteydessä. Lopuksi J2EE: n säilöpohjainen malli tekee verkkopalvelun käyttöönoton kannettavaksi: voit kehittää Java-pohjaisen verkkopalvelun käyttämällä mitä tahansa J2EE-työkalua ja odottaa kyseisen palvelun toimivan missä tahansa muussa yhteensopivassa säilön toteutuksessa.
Verkkopalveluasiakas ei sitä vastoin ole tietoinen verkkopalvelusäiliön läsnäolosta. Sen sijaan asiakas näkee satamaan joka edustaa verkkopalvelun verkon päätepistettä. Tämä päätepiste noudattaa JAX-RPC: tä palvelun päätepisteliittymä (SEI) -malli ja tarjoaa palvelun käyttöliittymän. Asiakas näkee jokaisen J2EE-verkkopalvelun SEI- ja porttiyhdistelmänä. Yhdessä J2EE-säiliössä voi olla monia tällaisia yhdistelmiä, kuten kuvio 2 kuvaa. Jokainen SEI / portti-yhdistelmä on verkkopalvelun ilmentymä.
Huomaa, että tämän arkkitehtuurin asiakas voi olla joko J2EE-asiakas, joka toimii J2EE-asiakassäiliössä, tai ei-J2EE-asiakas. Jokainen WS-I Basic Profile -yhteensopiva asiakas voi käyttää J2EE-verkkopalvelua, mutta jokainen asiakas voi noudattaa erilaisia ohjelmointimalleja. J2EE-verkkopalvelumäärityksessä hahmotellaan ohjelmointimalli asiakkaille, jotka toimivat J2EE-sovellusasiakassäiliössä, ja toinen malli - palvelimen ohjelmointimalli - verkkopalvelutoteutuksille, jotka suoritetaan EJB- tai servlet-säilöissä.
J2EE-verkkopalvelun asiakasohjelmointimalli
Verkkopalvelun asiakasohjelmointimallin ydin on virtaviivaistaa JSR: issä 67 (Java APIs for XML Messaging, JAXM), 93 (JAXR) ja 101 (JAX-RPC) määriteltyjen sovellusliittymien käyttöä ja tarjota kattava kehys käyttämällä näitä sovellusliittymiä yhdessä J2EE-asiakassäiliössä.
J2EE-asiakasohjelmointimallin mukaisesti verkkopalveluasiakas on kauko-ohjattava ja tarjoaa läpinäkyvyyden paikallisesti / etäisesti. Verkkopalvelun porttitoimittaja ja portti, jota portti käyttää, määrittävät, miten asiakas näkee verkkopalvelun. Asiakas käyttää aina porttia, eikä hänelle koskaan lähetetä suoraa viittausta verkkopalvelun käyttöönottoon. J2EE-verkkopalveluasiakas ei ole tietoinen portin toiminnasta, ja hänen on huolehdittava vain portin määrittelemistä menetelmistä. Nämä menetelmät muodostavat verkkopalvelun julkisen käyttöliittymän. Lisäksi asiakkaan on pidettävä verkkopalveluportin käyttöä kansalaisuudettomana kaikissa palvelukutsuissa. Asiakkaan osalta portista puuttuu yksilöllinen identiteetti - asiakkaalla ei ole mitään tapaa määrittää, onko se yhteydessä identtisiin portteihin palvelukutsujen kautta.
Asiakas saa pääsyn porttiin portin palvelurajapinnan perusteella. J2EE-verkkopalvelut tukeutuvat JAX-RPC: hen portin ja sen palvelurajapinnan välisen suhteen määrittelemiseksi. JAX-RPC luo kyseisen suhteen WSDL-käsittelysääntöjen perusteella. Siten verkkopalvelun WSDL-määritelmä hallitsee lopulta portin käyttäytymistä. JAX-RPC-määritelmän perusteella palvelurajapinta voi olla joko yleinen käyttöliittymä, joka toteuttaa suoraan javax.xml.rpc.Service käyttöliittymä tai "luotu palvelu", joka on kyseisen käyttöliittymän alatyyppi. Jälkimmäinen käyttöliittymätyyppi on ominaista verkkopalvelun tyypille.
J2EE-ohjelmointimallissa asiakas saa viitteen verkkopalveluun Palvelu objektin JNDI (Java Naming and Directory Interface) -hakutoiminnon kautta. JNDI-haku tapahtuu loogisella nimellä tai palveluviite, verkkopalvelua varten. Kuten kaikkien hakemistopohjaisten resurssien kohdalla, asiakkaan on ilmoitettava tarvittavat resurssit käyttöönottokuvaajaansa (lisätietoja siitä myöhemmin).
Java-verkkopalvelumäärittely (JSR 109) suosittelee, että kaikki verkkopalvelut kuuluvat JNDI: n alaisuuteen palvelu alakonteksti. Asiakassäiliö sitoo palvelurajapinnan, jota tämä viite kuvaa java: comp / env asiakasympäristön nimeämiskonteksti. Ilmoittamalla palveluviittauksen asiakkaan käyttöönottokuvaajassa, asiakassäiliö varmistaa, että viitattu palvelu on käytettävissä JNDI-tietoisissa resursseissa. Seuraava koodinpätkä näyttää, miten viite J2EE-pohjaiseen verkkopalveluun saadaan JNDI-haun kautta:
InitialContext ctx = uusi InitialContext (); Palvelu myService = (Palvelu) ctx.lookup ("java: comp / env / services / MyWebService"); Yllä oleva koodi saa yleisen palveluobjektin: objektin, jolla ei ole tiettyä tyyppiä. JAX-RPC: n luomaa palvelua käytetään samalla tavalla ja tällä kertaa palvelu siirretään tietyn verkkopalvelun käyttöliittymätyyppiin:
InitialContext ctx = uusi InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Huomaa, että tässä koodissa oletetaan, että MyWebService viite sitoutuu objektiin, joka toteuttaa MyWebService käyttöliittymä. Koska palvelujen sitomista helpotetaan verkkopalvelun käyttöönottoaikana, J2EE-työkalujen odotetaan varmistavan yhdenmukaisuuden. Kaikkien J2EE 1.4 -yhteensopivien sovelluspalvelimien on tuettava JNDI-pohjaista palvelujen hakua.
Kun asiakas on hankkinut verkkopalvelun Palvelu objekti, se voi käyttää kyseistä objektia a javax.xml.rpc.Soita ilmentymä, joka suorittaa varsinaisen palvelukutsu. Asiakkaalla on kolme vaihtoehtoa saada Puhelu: tynkän, dynaamisen palvelupalvelimen tai DII: n (Dynamic Invocation Interface) kautta. En käsittele tässä artikkelissa eroja näiden menetelmien välillä, riippumatta siitä, miten a Puhelu on luotu Puhelu viittaa suoraan palvelun porttiin - ainoa objekti, jonka asiakkaan on oltava tietoinen Web-palvelua käynnistettäessä. Kaikkien J2EE 1.4 -yhteensopivien astioiden on tuettava Palvelu käyttöliittymämenetelmiä, ja siten antaa asiakkaalle mahdollisuuden saada viittaus a Puhelu objekti verkkopalvelulle ja kyseisen palvelun portille Puhelu.
Huomaa, että päinvastoin kuin JAX-RPC: tä käytetään J2EE: n ulkopuolella, asiakkaan ei tule käyttää JAX-RPC: tä ServiceFactory luokassa saadakseen uuden palvelun. Sen sijaan asiakkaan tulisi saada pääsy Palvelu JNDI-pohjaisesta lähteestä, koska viitteellä JNDI: ltä haettuun palveluun on kaikki tarvittavat asetukset ja kokoonpanot tietyn palvelujärjestelmän kutsumiseksi. Asiakkaan näkökulmasta tämä ero on jonkin verran analoginen siihen, miten J2EE-asiakas hakee JDBC: n Tietolähde JNDI-liitännän kautta päästäksesi tietokantaan sen sijaan, että määrität JDBC: n manuaalisesti Yhteys ilmentymä.
Tuon kanssa Puhelu Kohde paikallaan, asiakas seuraa JAX-RPC-semantiikkaa etäproseduurikutsusta. Esimerkiksi asiakas saattaa käyttää vedota() menetelmä Puhelu olla vuorovaikutuksessa verkkopalvelun kanssa. (Esimerkki JAX-RPC-tyylisestä palvelukutsu, katso "Pidän tyypistäsi: Kuvaile ja kutsu verkkopalveluja palvelutyypin perusteella" (JavaWorld, Syyskuu 2002).)
Web-palvelinohjelmointimalli
J2EE-pohjainen verkkopalvelu voi seurata yhtä kahdesta mahdollisesta toteutuksesta: Jos palvelu on toteutettu tavallisena Java-luokkaan, sen on oltava JAX-RPC-palvelinsovelluksen säiliön vaatimusten mukainen. Tai jos palvelu määritetään suoritettavaksi EJB-säilössä, sen on noudatettava kansalaisuudettomille EJB-istuntopavuille vaadittavaa ohjelmointimallia. Toteutustavasta riippumatta jokainen säilö tarjoaa verkkopalvelutoteutukselle elinkaarituen, samanaikaisuuden hallinnan ja suojausinfrastruktuurin.
J2EE-palvelinsäiliön ensisijainen vastuu on kartoittaa ja lähettää SOAP-pyynnöt EJB-tapauksessa valtiottomille istuntopavuille ja servlet-säilön tapauksessa JAX-RPC-palvelun päätepisteiden luokkien menetelmille. Vaikka JAX-RPC-määrittely määrittelee ohjelmointimallin jälkimmäiselle vaihtoehdolle, J2EE-verkkopalvelut JSR (JSR 109) esittävät analogisen mallin kansalaisuudettomille EJB-istuntopavuille.
