Noslēdzot savu J2EE (Java 2 Platform, Enterprise Edition) tīmekļa pakalpojumu prezentāciju pagājušā gada JavaOne, IBM arhitekts Džims Knutsons atzīmēja, ka "katram tīmekļa pakalpojumam ir nepieciešama vieta, lai tas būtu pakalpojums". Pēc tam viņš ieteica, ka ideālākā vieta tīmekļa pakalpojumam ir J2EE infrastruktūrā. Nedaudz vairāk nekā gadu vēlāk ir gaidāma J2EE 1.4 galīgā izlaišana, un tā nozīmīgākais solījums ir J2EE tīmekļa pakalpojumu redzējuma izpilde.
J2EE 1.4 tīmekļa pakalpojuma funkcijas adresē Web servera un klienta puses. Funkcijas paplašina J2EE, lai esošie servera puses uzņēmuma Java komponenti varētu kļūt par tīmekļa pakalpojumiem, un norāda, kā J2EE klienta konteiners var izsaukt tīmekļa pakalpojumus. Abiem mērķiem paredzētās tehnoloģijas jau kādu laiku pastāv, un jaunās J2EE specifikācijas paļaujas uz šīm esošajām API tīmekļa pakalpojumu atbalstam. Jaunās specifikācijas esošajām tehnoloģijām papildina savietojamības prasību kopumu, kā arī programmēšanas un izvietošanas modeli tīmekļa pakalpojumu integrācijai.
Ir divas specifikācijas, kas skaidri iezīmē šīs pievienotās funkcijas: Java specifikācijas pieprasījums 151, jumta JSR for J2EE 1.4 un JSR 109, Web Services for J2EE. Šīs rakstīšanas laikā JSR 109 ir sasniedzis pēdējo posmu JCP (Java Community Process), savukārt JSR 151 atrodas pēdējā balsošanas posmā. Turklāt JCP grozīja JSR 101 gala laidienu, Java API uz XML balstītu attālās procedūras izsaukumu (JAX-RPC), lai atbalstītu J2EE 1.4 sadarbības prasības.
J2EE 1.3 līmeņa lietojumprogrammu serveri var arī ieviest daudzas no šīm JSR noteiktajām funkcijām. Patiešām, daudzi lietojumprogrammu serveru piegādātāji jau kādu laiku ir atbalstījuši dažādus tīmekļa pakalpojumu izstrādes un izvietošanas līdzekļus esošajos produktos. JSR 109 un 151 kodificē dažas esošās prakses un apraksta jaunus mehānismus, cerot izveidot universālu J2EE-Web pakalpojumu integrācijas modeli. Nākamās paaudzes lietojumprogrammu serveri, iespējams, sekos šim vienotajam, standartizētajam modelim.
Pēc īsa ar Web pakalpojumu saistītu J2EE funkciju pārskata šajā rakstā ir apskatīti jaunie klientu un serveru programmēšanas modeļi, tostarp jaunās J2EE izvietošanas un pakalpojumu pārvaldības lomas, kas saistītas ar tīmekļa pakalpojumu atbalstu.
Ar tīmekļa pakalpojumiem saistīti J2EE paplašinājumi
Iespējams, ka visnozīmīgākie un visbūtiskākie J2EE papildinājumi ir jaunās prasības sadarbībai. Prasības nosaka SOAP (vienkāršs objekta piekļuves protokols) 1.1 atbalstu J2EE prezentācijas slānī, lai atvieglotu XML ziņojumu apmaiņu. J2EE 1.4 saderīgiem konteineriem jāatbalsta arī WS-I (Web Services Interoperability Consortium) pamata profils. Tā kā XML ziņojumu apmaiņa J2EE ir atkarīga no JAX-RPC, JAX-RPC specifikācijas tagad nosaka arī WS-I pamata profila atbalstu.
Rezultāts ir tāds, ka uz J2EE 1.4 balstītu lietojumprogrammu var izsaukt kā tīmekļa pakalpojumu pat no lietojumprogrammām, kas nav rakstītas Java programmēšanas valodā. Lai gan tas ir J2EE evolucionārs solis, tā kā platforma jau sen ir aptvērusi sistēmas, kas nav Java balstītas, iespējams, tas ir vistiešākais veids, kā atvieglot mijiedarbību ar Windows balstītām tehnoloģijām, kuras paļaujas uz .Net.
J2EE balstīta pakalpojuma klientam nav jāzina, kā pakalpojums tiek ieviests. Drīzāk šis klients var izmantot pakalpojumu, pilnībā paļaujoties uz pakalpojuma WSDL (Web Services Description Language) definīciju. (Iepriekšējais JavaWorldTīmekļa pakalpojumi slejās ir paskaidrots, kā atrast pakalpojumus, pamatojoties uz to WSDL definīcijām, kā arī izveidot un izmantot WSDL definīcijas. Skatiet saites resursos.) Lai gan J2EE specifikācijās nav precīzi aprakstīta šādas mijiedarbības mehānika, J2EE 1.4, izmantojot WS-I pamata profilu, kuru Microsoft apgalvo arī sekojošu, visticamāk padarīs J2EE-.Net mijiedarbību parastu. .
Lai atvieglotu piekļuvi WSDL definīcijām, J2EE 1.4 pievieno atbalstu JAXR (Java API for XML Registries) standartam. JAXR bibliotēkas tagad ir obligāta J2EE lietojumprogrammu klienta, EJB (Enterprise JavaBeans) un tīmekļa konteineru (tomēr ne sīklietotņu konteinera) daļa. Tā kā WS-I pamata profils nosaka atbalstu UDDI (universālajam aprakstam, atklāšanai un integrācijai) 2.0, J2EE klienti, kā arī EJB komponenti un servleti var mijiedarboties ar publiskajiem tīmekļa pakalpojumu reģistriem. ("Tīmekļa pakalpojumi peld ar JAXR" (JavaWorld, 2002. gada maijs) piedāvā apmācību par JAXR.) 1. attēlā ir parādītas ar Web pakalpojumu saistītas papildu bibliotēkas, kuras atbalsta J2EE 1.4.
Patiešām, J2EE uzskata, ka tīmekļa pakalpojums ir vienas vai vairāku WSDL dokumentā definēto saskarņu ieviešana. WSDL aprakstītās darbības vispirms tiek kartētas uz Java metodēm, ievērojot JAX-RPC specifikācijas WSDL-Java kartēšanas kārtulas. Kad ir definēta Java saskarne, kas atbilst WSDL failam, šīs saskarnes metodes var ieviest vienā no diviem veidiem: kā bezvalstnieka sesijas pupiņu, kas darbojas EJB konteinerā, vai kā Java klasi, kas darbojas J2EE servletīklā. Visbeidzot, jūs noorganizējat, lai attiecīgais konteiners noklausītos ienākošos SOAP pieprasījumus un šos pieprasījumus piesaistītu attiecīgajai ieviešanai (EJB vai servletīkls). Lai apstrādātu ienākošos SOAP izsaukumus, J2EE 1.4 pilnvaro JAX-RPC izpildlaiku kā papildu J2EE konteineru pakalpojumu.
Saskaņā ar J2EE arhitektūru pakalpojuma ieviešanas konteiners starpo piekļuvi tīmekļa pakalpojumam: ja jūs pakļaujat vai nu EJB komponentu, vai servletu kā J2EE tīmekļa pakalpojumu, jūsu pakalpojuma klienti var izsaukt šo pakalpojumu tikai netieši, izmantojot konteineru. Tas ļauj pakalpojuma ieviešanai izmantot konteinera drošību, pavedienu pārvaldību un pat pakalpojumu kvalitātes garantijas. Turklāt konteineri ļauj jums izvietošanas laikā pieņemt svarīgus tīmekļa pakalpojumu lēmumus, piemēram, drošības ierobežojumus. Visbeidzot, ar J2EE konteineru modeli tīmekļa pakalpojumu izvietošana ir pārnēsājama: varat izstrādāt Java balstītu tīmekļa pakalpojumu, izmantojot jebkuru J2EE rīku, un sagaidāt, ka šis pakalpojums darbosies jebkurā citā atbilstošā konteinera ieviešanā.
Savukārt tīmekļa pakalpojumu klients nezina par tīmekļa pakalpojumu konteinera klātbūtni. Tā vietā klients redz a osta kas pārstāv tīkla pakalpojuma tīkla galapunktu. Šis galapunkts seko JAX-RPC pakalpojuma galapunkta saskarne (SEI) modeli un nodrošina pakalpojuma saskarnes ieviešanu. Klients katru J2EE tīmekļa pakalpojumu uzskata par SEI un porta kombināciju. Vienā J2EE konteinerā var izvietot daudzas šādas kombinācijas, kā parādīts 2. attēlā. Katra SEI / porta kombinācija ir tīmekļa pakalpojuma gadījums.
Ņemiet vērā, ka klients šajā arhitektūrā var būt vai nu J2EE klients, kas darbojas J2EE klienta konteinerā, vai arī klients, kas nav J2EE. Jebkurš ar WS-I Basic Profile atbilstošs klients var izmantot J2EE tīmekļa pakalpojumu, taču katrs klients var sekot dažādiem programmēšanas modeļiem. J2EE tīmekļa pakalpojumu specifikācijā ir izklāstīts programmēšanas modelis klientiem, kuri darbojas J2EE lietojumprogrammu klienta konteinerā, un cits modelis - servera programmēšanas modelis - tīmekļa pakalpojumu ieviešanai, kas tiek izpildīti EJB vai servletīklu konteineros.
J2EE tīmekļa pakalpojuma klienta programmēšanas modelis
Tīmekļa pakalpojuma klienta programmēšanas modeļa būtība ir pilnveidot API, kas definētas JSR 67 (Java API for XML Messaging, JAXM), 93 (JAXR) un 101 (JAX-RPC), un nodrošināt visaptverošu sistēmu izmantojot šīs API kopā J2EE klienta konteinerā.
Saskaņā ar J2EE klienta programmēšanas modeli tīmekļa pakalpojumu klients ir attālināti un nodrošina vietējo / attālo pārredzamību. Tīmekļa pakalpojumu porta nodrošinātājs un konteiners, kurā darbojas ports, nosaka, kā klients redz tīmekļa pakalpojumu. Klients vienmēr piekļūst ostai, un viņam nekad netiek nodota tieša norāde uz tīmekļa pakalpojuma ieviešanu. J2EE tīmekļa pakalpojuma klients joprojām nezina, kā darbojas osta, un viņam jāpievērš uzmanība tikai tām metodēm, kuras osta nosaka. Šīs metodes veido tīmekļa pakalpojuma publisko saskarni. Turklāt klientam ir jāapsver piekļuve tīmekļa pakalpojumu portam kā bezvalstnieks pakalpojumu izsaukumos. Ciktāl tas attiecas uz klientu, ostai trūkst unikālas identitātes - klientam nav iespējas noteikt, vai tas visu pakalpojumu izsaukumu laikā sazinās ar identiskām ostām.
Klients iegūst piekļuvi ostai, pamatojoties uz ostas pakalpojumu saskarni. J2EE tīmekļa pakalpojumi paļaujas uz JAX-RPC, lai noteiktu attiecības starp portu un tā pakalpojumu saskarni. JAX-RPC izveido šīs attiecības, pamatojoties uz WSDL apstrādes noteikumiem. Tādējādi tīmekļa pakalpojuma WSDL definīcija galu galā regulē porta uzvedību. Pamatojoties uz JAX-RPC definīciju, servisa saskarne var būt vai nu vispārēja saskarne, kas tieši ievieš javax.xml.rpc.Service interfeiss vai "ģenerēts pakalpojums", kas ir šīs saskarnes apakštips. Pēdējais saskarnes tips ir raksturīgs tīmekļa pakalpojuma tipam.
J2EE programmēšanas modelī klients iegūst atsauci uz tīmekļa pakalpojumu apkalpošana objektu, izmantojot JNDI (Java Naming and Directory Interface) uzmeklēšanas darbību. JNDI uzmeklēšana notiek ar loģisku nosaukumu vai pakalpojuma atsauce, Web pakalpojumam. Tāpat kā visiem direktoriju resursiem, arī klientam izvietošanas aprakstā ir jāpaziņo, kādi resursi tam nepieciešami (par to vēlāk).
Java tīmekļa pakalpojumu specifikācija (JSR 109) iesaka visus tīmekļa pakalpojumus ieskaitīt JNDI apkalpošana zemteksts. Klienta konteiners saista pakalpojuma saskarni, kas aprakstīta šajā atsaucē sadaļā java: comp / env klienta vides nosaukšanas konteksts. Deklarējot pakalpojuma atsauci klienta izvietošanas aprakstā, klienta konteiners nodrošina, ka atsauces pakalpojums ir pieejams JNDI apzinošos resursos. Šis koda fragments parāda, kā iegūt atsauci uz J2EE balstītu tīmekļa pakalpojumu, izmantojot JNDI uzmeklēšanu:
InitialContext ctx = jauns InitialContext (); Pakalpojums myService = (Pakalpojums) ctx.lookup ("java: comp / env / services / MyWebService"); Iepriekš minētais kods iegūst vispārēju pakalpojuma objektu: objektu bez noteikta veida. JAX-RPC ģenerētam pakalpojumam piekļūst tāpat, šoreiz pakalpojums tiek nodots konkrētā tīmekļa pakalpojuma saskarnes tipam:
InitialContext ctx = jauns InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Ņemiet vērā, ka šis kods pieņem, ka MyWebService atsauce saistās ar objektu, kas īsteno MyWebService interfeiss. Tā kā pakalpojumu saistīšana tiek atvieglota tīmekļa pakalpojuma izvietošanas laikā, paredzams, ka J2EE rīki nodrošinās šo konsekvenci. Visiem ar J2EE 1.4 saderīgajiem lietojumprogrammu serveriem jāatbalsta uz JNDI balstīta pakalpojumu meklēšana.
Kad klients ir ieguvis tīmekļa pakalpojumu apkalpošana objektu, tā var izmantot šo objektu, lai izgūtu a javax.xml.rpc.Zvani instance, kas veic faktisko pakalpojuma izsaukšanu. Klientam ir trīs iespējas iegūt Zvaniet: izmantojot spraudni, dinamisku pakalpojuma starpniekserveri vai DII (Dynamic Invocation Interface). Šajā rakstā es neapspriedīšu atšķirības starp šīm metodēm kopš tā laika Zvaniet ir izveidots, ka Zvaniet atsaucas tieši uz pakalpojuma portu - vienīgais objekts, par kuru klientam ir jāzina, atsaucoties uz Web pakalpojumu. Visiem ar J2EE 1.4 saderīgiem konteineriem jāatbalsta apkalpošana saskarnes metodes un tādējādi ļauj klientam iegūt atsauci uz a Zvaniet objekts Web pakalpojumam un uz šī pakalpojuma portu, izmantojot Zvaniet.
Ņemiet vērā, ka pretstatā JAX-RPC izmantošanai ārpus J2EE, klientam nevajadzētu izmantot JAX-RPC ServiceFactory klasē, lai iegūtu jaunu pakalpojumu. Tā vietā klientam vajadzētu piekļūt apkalpošana no JNDI bāzes avota, jo atsaucei uz pakalpojumu, kas iegūts no JNDI, būs visi iestatījumi un konfigurācijas, kas nepieciešami, lai izsauktu konkrēto pakalpojuma gadījumu. No klienta viedokļa šī atšķirība ir nedaudz analoga tam, kā J2EE klients iegūst JDBC Datu avots izmantojot JNDI saskarni, lai piekļūtu datu bāzei, nevis manuāli konfigurētu JDBC Savienojums instancē.
Ar to Zvaniet objekts vietā, klients ievēro JAX-RPC attālās procedūras izsaukšanas semantiku. Piemēram, klients var izmantot izsaukt () metodi Zvaniet mijiedarboties ar Web pakalpojumu. (JAX-RPC stila pakalpojumu izsaukuma piemēru skatiet sadaļā "Man patīk jūsu tips: aprakstiet un izsauciet Web pakalpojumus, pamatojoties uz pakalpojuma tipu" (JavaWorld, 2002. gada septembris).)
Tīmekļa pakalpojumu servera programmēšanas modelis
J2EE balstīts tīmekļa pakalpojums var sekot vienam no diviem iespējamiem ieviešanas veidiem: Ja pakalpojums tiek ieviests kā parasta Java klase, tam jāatbilst JAX-RPC servetleta konteinera prasībām. Vai arī, ja pakalpojums ir noteikts izpildei EJB konteinerā, tam jāievēro programmēšanas modelis, kas nepieciešams EJB sesijas pupiņām bezvalstniekiem. Neatkarīgi no ieviešanas metodes katrs konteiners nodrošina Web pakalpojuma ieviešanu ar dzīves cikla atbalstu, vienlaicīguma pārvaldību un drošības infrastruktūru.
J2EE servera konteinera galvenā atbildība ir kartēt un nosūtīt SOAP pieprasījumus EJB gadījumā bezvalstnieku sesijas pupiņām un servletīlu konteinera gadījumā - metodēm JAX-RPC pakalpojuma galapunkta klasēs. Kamēr JAX-RPC specifikācija definē pēdējās opcijas programmēšanas modeli, J2EE tīmekļa pakalpojumi JSR (JSR 109) iezīmē analogu modeli bezvalstniekiem EJB sesijas pupiņām.
