Baigdamas savo J2EE („Java 2 Platform“, „Enterprise Edition“) žiniatinklio paslaugų pristatymą praėjusių metų „JavaOne“, IBM architektas Jimas Knutsonas pažymėjo, kad „kiekvienai interneto paslaugai reikia vietos, kad ji būtų paslauga“. Tada jis pasiūlė, kad idealiausia vieta būti interneto paslauga yra J2EE infrastruktūroje. Praėjus kiek daugiau nei metams, netrukus bus išleistas galutinis „J2EE 1.4“ leidimas, o svarbiausias pažadas yra įgyvendinti „J2EE“ interneto paslaugų viziją.
J2EE 1.4 žiniatinklio paslaugos funkcijos nukreipia tiek į serverio, tiek į kliento žiniatinklio paslaugų puses. Šios funkcijos praplečia J2EE, kad esami serverio įmonės įmonės „Java“ komponentai galėtų tapti žiniatinklio paslaugomis ir nurodoma, kaip „J2EE“ kliento sudėtinis rodinys gali iškviesti žiniatinklio paslaugas. Abiem tikslams skirtos technologijos egzistuoja kurį laiką, o naujosios J2EE specifikacijos remiasi tomis esamomis API, kad palaikytų žiniatinklio paslaugas. Naujos specifikacijos prie esamų technologijų papildo sąveikos reikalavimų rinkinį ir programavimo bei diegimo modelį, skirtą interneto paslaugų integravimui.
Yra dvi specifikacijos, kurios aiškiai apibūdina šias papildomas funkcijas: „Java Specification Request 151“, „JSR“ skėtis, skirtas „J2EE 1.4“, ir „JSR 109“, „Web Services for J2EE“. Šio rašymo metu JSR 109 pasiekė paskutinį JCP („Java Community Process“) etapą, o JSR 151 yra paskutiniame balsavimo etape. Be to, JCP pakeitė galutinį „JSR 101“, „Java“ API, skirtos XML pagrįstam nuotolinio procedūrų iškvietimui (JAX-RPC), leidimą, kad būtų palaikomi „J2EE 1.4“ sąveikos reikalavimai.
J2EE 1.3 lygio programų serveriai taip pat gali įgyvendinti daugelį šių JSR nurodytų funkcijų. Iš tiesų, daugelis programų serverių tiekėjų jau kurį laiką palaiko įvairias žiniatinklio paslaugų kūrimo ir diegimo funkcijas esamuose produktuose. JSR 109 ir 151 kodifikuoja kai kurias esamas praktikas ir aprašo naujus mechanizmus, tikėdamiesi sukurti universalų J2EE ir interneto paslaugų integravimo modelį. Naujos kartos programų serveriai greičiausiai vadovausis tuo vieningu, standartizuotu modeliu.
Atlikus trumpą naujų su žiniatinklio paslaugomis susijusių J2EE funkcijų apžvalgą, šiame straipsnyje apžvelgiami nauji kliento ir serverio programavimo modeliai, įskaitant naujus J2EE diegimo ir paslaugų valdymo vaidmenis, susijusius su žiniatinklio paslaugų palaikymu.
Su interneto paslauga susiję J2EE plėtiniai
Bene reikšmingiausi ir reikšmingiausi J2EE papildymai yra nauji sąveikos reikalavimai. Reikalavimai nurodo SOAP (paprasto objekto prieigos protokolo) 1.1 palaikymą J2EE pateikimo sluoksnyje, kad būtų lengviau keistis XML pranešimais. „J2EE 1.4“ suderinami konteineriai taip pat turi palaikyti pagrindinį WS-I („Web Services Interoperability Consortium“) profilį. Kadangi XML pranešimų mainai J2EE priklauso nuo JAX-RPC, JAX-RPC specifikacijos taip pat įpareigoja palaikyti „WS-I Basic Profile“.
Rezultatas yra tas, kad J2EE 1.4 pagrindu veikiančią programą galima iškviesti kaip žiniatinklio paslaugą, net iš programų, kurios nėra parašytos „Java“ programavimo kalba. Nors tai yra evoliucinis J2EE žingsnis, kadangi platforma jau seniai apima ne „Java“ pagrįstas sistemas, tai galbūt yra tiesioginis būdas palengvinti sąveiką su „Windows“ pagrįstomis technologijomis, kurios remiasi .Net.
J2EE pagrįstos paslaugos klientas neprivalo žinoti, kaip paslauga įgyvendinama. Veikiau tas klientas gali naudotis paslauga visiškai pasikliaudamas paslaugos WSDL („Web Services Description Language“) apibrėžimu. (Ankstesnis „JavaWorld“Žiniatinklio paslaugos stulpeliuose paaiškinta, kaip atrasti paslaugas remiantis jų WSDL apibrėžimais ir kaip sukurti bei naudoti WSDL apibrėžimus. Žr. Nuorodų šaltinius.) Nors „J2EE“ specifikacijose nėra tiksliai apibrėžta tokios sąveikos mechanika, „J2EE 1.4“ aprėpia „WS-I“ pagrindinį profilį, kuriuo taip pat teigia besivadovaujanti „Microsoft“, tikėtina, kad „J2EE-.Net“ sąveika bus įprasta. .
Siekdamas palengvinti prieigą prie WSDL apibrėžimų, „J2EE 1.4“ papildo JAXR („Java API for XML Registries“) standartą. JAXR bibliotekos dabar yra būtina „J2EE“ programos kliento, EJB („Enterprise JavaBeans“) ir žiniatinklio konteinerių dalis (tačiau ne programėlių talpykla). Kadangi „WS-I Basic Profile“ reikalauja palaikyti UDDI (universalus aprašymas, atradimas ir integravimas) 2.0, „J2EE“ klientai, taip pat EJB komponentai ir servletai gali sąveikauti su viešaisiais interneto paslaugų registrais. („Žiniatinklio paslaugos plinta su JAXR“ („JavaWorld“, 2002 m. Gegužė) siūlo pamoką apie JAXR.) 1 paveiksle pavaizduotos papildomos su interneto paslauga susijusios bibliotekos, palaikomos J2EE 1.4.
Iš tiesų, J2EE laikosi nuomonės, kad žiniatinklio paslauga yra vienos ar daugiau sąsajų, apibrėžtų WSDL dokumente, įgyvendinimas. WSDL aprašytos operacijos pirmiausia susiejamos su „Java“ metodais, laikantis JAX-RPC specifikacijos WSDL – Java susiejimo taisyklių. Nustačius „Java“ sąsają, atitinkančią WSDL failą, tos sąsajos metodus galite įgyvendinti vienu iš dviejų būdų: kaip seanso pupelę be pilietės, veikiančią EJB konteineryje, arba kaip „Java“ klasę, veikiančią „J2EE“ servleto talpykloje. Galiausiai pasirūpinsite, kad atitinkamas konteineris išklausytų gaunamas SOAP užklausas ir priskirtumėte šias užklausas atitinkamam įgyvendinimui (EJB arba servletui). Norėdami apdoroti gaunamus SOAP iškvietimus, J2EE 1.4 įpareigoja JAX-RPC vykdymo laiką kaip papildomą J2EE konteinerių paslaugą.
Laikantis J2EE architektūros, paslaugų diegimo talpykla tarpininkauja prieigai prie žiniatinklio paslaugos: jei EJB komponentą arba servletą atskleidžiate kaip J2EE žiniatinklio paslaugą, jūsų paslaugos klientai gali pasinaudoti ta paslauga tik netiesiogiai, per talpyklą. Tai leidžia paslaugų diegimui pasinaudoti talpyklos saugumu, gijų valdymu ir netgi paslaugų kokybės garantijomis. Be to, sudėtiniai rodiniai leidžia jums priimti svarbius žiniatinklio paslaugų sprendimus, pvz., Saugos apribojimus, diegimo metu. Galiausiai, naudojant „J2EE“ konteinerių modelį, žiniatinklio paslaugų diegimas yra nešiojamas: galite sukurti „Java“ pagrindu veikiančią žiniatinklio paslaugą naudodami bet kurį „J2EE“ įrankį ir tikėtis, kad ši paslauga bus vykdoma bet kuriame kitame suderinamame sudėtiniame rodinyje.
Kita vertus, žiniatinklio paslaugų klientas ir toliau nežino apie žiniatinklio paslaugų talpyklos buvimą. Vietoj to klientas mato a uostas atstovaujantis tinklo paslaugos tinklo pabaigos taško egzemplioriui. Ta galūnė seka JAX-RPC paslaugos galutinio taško sąsaja (SEI) modelį ir pateikia paslaugos sąsajos įgyvendinimą. Klientas kiekvieną J2EE žiniatinklio paslaugą mato kaip SEI ir prievado derinį. Viename J2EE konteineryje gali būti daug tokių derinių, kaip parodyta 2 paveiksle. Kiekvienas SEI / prievado derinys yra žiniatinklio paslaugos pavyzdys.
Atkreipkite dėmesį, kad šios architektūros klientas gali būti arba J2EE klientas, veikiantis J2EE kliento talpykloje, arba ne J2EE klientas. Bet kuris „WS-I Basic Profile“ suderinamas klientas gali naudoti „J2EE“ žiniatinklio paslaugą, tačiau kiekvienas klientas gali naudoti skirtingus programavimo modelius. J2EE žiniatinklio paslaugų specifikacijoje pateikiamas programavimo modelis klientams, kurie veikia „J2EE“ programos kliento talpykloje, ir kitas modelis - serverio programavimo modelis - žiniatinklio paslaugų diegimui, kuris vykdomas EJB arba „servlet“ talpyklose.
J2EE žiniatinklio paslaugos kliento programavimo modelis
Žiniatinklio paslaugos kliento programavimo modelio esmė yra supaprastinti API, apibrėžtų JSR 67 („Java“ API XML Messaging, JAXM), 93 (JAXR) ir 101 (JAX-RPC), apibrėžimą ir pateikti išsamią sistemą naudojant šias API kartu J2EE kliento sudėtiniame rodinyje.
Laikantis J2EE kliento programavimo modelio, interneto paslaugų klientas yra nuotolinis ir užtikrina vietinį / nuotolinį skaidrumą. Žiniatinklio paslaugos prievado teikėjas ir talpykla, kurioje veikia uostas, apibrėžia, kaip klientas mato žiniatinklio paslaugą. Klientas visada patenka į uostą ir niekada neperduoda tiesioginės nuorodos į žiniatinklio paslaugos įgyvendinimą. J2EE žiniatinklio paslaugų klientas ir toliau nežino, kaip veikia uostas, ir turi rūpintis tik tais būdais, kuriuos nustato uostas. Šie metodai sudaro viešąją žiniatinklio paslaugos sąsają. Be to, klientas turi laikyti prieigą prie interneto paslaugų prievado be pilietybės visuose paslaugų kvietimuose. Kalbant apie klientą, uoste nėra unikalios tapatybės - klientas niekaip negali nustatyti, ar per paslaugų iškvietimus jis bendrauja su identiškais prievadais.
Klientas gauna prieigą prie uosto pagal uosto paslaugų sąsają. J2EE žiniatinklio paslaugos remiasi JAX-RPC, kad apibrėžtų ryšį tarp uosto ir jo paslaugų sąsajos. JAX-RPC sukuria tą ryšį remdamasis WSDL apdorojimo taisyklėmis. Taigi, interneto paslaugos WSDL apibrėžimas galiausiai valdo uosto elgesį. Remiantis JAX-RPC apibrėžimu, paslaugų sąsaja gali būti bendroji sąsaja, tiesiogiai įgyvendinanti javax.xml.rpc.Service sąsaja arba „sukurta paslauga“, kuri yra tos sąsajos potipis. Pastarasis sąsajos tipas būdingas žiniatinklio paslaugos tipui.
J2EE programavimo modelyje klientas gauna nuorodą į žiniatinklio paslaugą Aptarnavimas objektą per JNDI („Java Naming and Directory Interface“) paieškos operaciją. JNDI peržiūra vyksta loginiu pavadinimu arba paslaugos nuoroda, žiniatinklio paslaugai. Kaip ir naudojant visus katalogų išteklius, klientas turi nurodyti, kokių išteklių jam reikia savo diegimo apraše (daugiau apie tai vėliau).
„Java“ žiniatinklio paslaugų specifikacijoje (JSR 109) rekomenduojama, kad visos žiniatinklio paslaugos būtų priskiriamos JNDI paslaugą potekstė. Kliento talpykla susieja paslaugos sąsają, aprašytą ta nuoroda java: comp / env kliento aplinkos pavadinimo kontekstas. Deklaruodamas paslaugos nuorodą kliento diegimo apraše, kliento sudėtinis rodinys užtikrina, kad nurodoma paslauga būtų prieinama JNDI žinančiuose šaltiniuose. Šis kodo fragmentas rodo, kaip gauti nuorodą į J2EE pagrįstą žiniatinklio paslaugą per JNDI peržvalgą:
InitialContext ctx = naujas InitialContext (); „Service myService“ = (tarnyba) ctx.lookup ("java: comp / env / services / MyWebService"); Aukščiau pateiktas kodas gauna bendrą paslaugos objektą: objektą be konkretaus tipo. JAX-RPC sukurta paslauga pasiekiama tuo pačiu būdu, šį kartą perduodant paslaugą pagal konkretaus žiniatinklio paslaugos sąsajos tipą:
InitialContext ctx = naujas InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Atminkite, kad šiame kode daroma prielaida, kad „MyWebService“ nuoroda susiejasi su objektu, kuris įgyvendina „MyWebService“ sąsaja. Kadangi paslaugų susiejimas palengvinamas žiniatinklio tarnybos diegimo metu, tikimasi, kad J2EE įrankiai užtikrins tą nuoseklumą. Visi J2EE 1.4 suderinami programų serveriai turi palaikyti JNDI pagrįstą paslaugų paiešką.
Kai tik klientas gauna žiniatinklio paslaugą Aptarnavimas objektą, jis gali naudoti tą objektą nuskaityti a javax.xml.rpc.Call egzempliorius, kuris atlieka faktinį paslaugos iškvietimą. Klientas turi tris galimybes gauti Skambinkite: per šabloną, dinaminį paslaugos tarpinį serverį arba DII (dinaminės iškvietimo sąsają). Šiame straipsnyje nenagrinėsiu šių metodų skirtumų, nesvarbu, kaip Skambinkite yra sukurta, kad Skambinkite nurodo tiesiogiai į paslaugos prievadą - vienintelis objektas, apie kurį klientas turi žinoti, kai naudojasi žiniatinklio paslauga. Visi J2EE 1.4 suderinami konteineriai turi palaikyti Aptarnavimas sąsajos metodus ir taip leisti klientui gauti nuorodą į a Skambinkite objektas, skirtas žiniatinklio paslaugai, ir į tos paslaugos uostą per Skambinkite.
Atkreipkite dėmesį, kad priešingai nei naudojant JAX-RPC ne J2EE, klientas neturėtų naudoti JAX-RPC „ServiceFactory“ klasę gauti naują paslaugą. Vietoj to, klientas turėtų gauti prieigą prie Aptarnavimas iš JNDI pagrįsto šaltinio, nes nuoroda į iš JNDI gautą paslaugą turės visus nustatymus ir konfigūracijas, reikalingus tam tikram paslaugos egzemplioriui iškviesti. Kliento požiūriu, šis skirtumas yra šiek tiek analogiškas tam, kaip J2EE klientas gauna JDBC Duomenų šaltinis per JNDI sąsają patekti į duomenų bazę, užuot rankiniu būdu sukonfigūravus JDBC Ryšys instancija.
Su tuo Skambinkite objekto vietoje, klientas vadovaujasi JAX-RPC nuotolinio procedūrų iškvietimo semantika. Pavyzdžiui, klientas gali naudoti iškviesti () metodas Skambinkite bendrauti su interneto paslauga. (JAX-RPC stiliaus paslaugų iškvietimo pavyzdį žr. „Man patinka jūsų tipas: aprašykite ir iškvieskite interneto paslaugas pagal paslaugos tipą“ („JavaWorld“, 2002 m. Rugsėjo mėn.).)
Žiniatinklio paslaugų serverio programavimo modelis
J2EE pagrindu veikianti žiniatinklio paslauga gali būti vykdoma vienu iš dviejų galimų diegimų: Jei paslauga įgyvendinama kaip įprasta „Java“ klasė, ji turi atitikti JAX-RPC servetėlių talpyklos reikalavimus. Arba, jei paslauga yra apibrėžta vykdyti EJB talpykloje, ji turi atitikti programavimo modelį, kurio reikalaujama be EJB sesijos pupelių. Nepaisant diegimo metodo, kiekvienas sudėtinis rodinys teikia žiniatinklio paslaugos diegimui gyvavimo ciklo palaikymą, lygiagrečių valdymą ir saugos infrastruktūrą.
Pagrindinė „J2EE“ serverio talpyklos atsakomybė yra susieti ir išsiųsti SOAP užklausas EJB atveju be seanso pupelių be pilietybės, o servletų konteinerio atveju - į metodus JAX-RPC paslaugų pabaigos taškų klasėse. Nors JAX-RPC specifikacijoje apibrėžtas pastarosios galimybės programavimo modelis, J2EE žiniatinklio paslaugos JSR (JSR 109) pateikia analogišką modelį be pilietybės EJB sesijos pupelėms.
