Java Standard Edition (SE) 6 ietvēra atbalstu tīmekļa pakalpojumiem. Šis ieraksts sāk četru daļu sēriju par Web pakalpojumiem Java SE, paskaidrojot, kādi ir tīmekļa pakalpojumi, un pārskata Java SE atbalstu tiem. Turpmākajās ziņās šis atbalsts tiks izmantots, lai izveidotu uz SOAP balstītus un uz RESTful balstītus tīmekļa pakalpojumus, un tie aptvers arī uzlabotas tīmekļa pakalpojumu tēmas.
Java XML un JSON
Šajā sērijā es pieņemu, ka jūs saprotat XML un JSON. Ja nē, jūs varētu vēlēties apskatīt manu Java XML un JSON grāmata, kas tiek reklamēta šī ieraksta beigās.
Kas ir tīmekļa pakalpojumi?
Wikipedia definē Tīmekļa pakalpojums kā "programmatūras sistēma, kas paredzēta sadarbspējīgas mašīnu savstarpējas mijiedarbības atbalstīšanai tīklā". Detalizētāku definīciju var iegūt, vispirms definējot šī termina daļas:
- Tīmeklis: Milzīgs savstarpēji saistīts resursu tīkls, kur a resurss ir vienota resursa identifikatora (URI) nosaukts datu avots, piemēram, uz PDF balstīts dokuments, video straume, Web lapa vai pat lietojumprogramma. Šiem resursiem var piekļūt, izmantojot standarta interneta protokolus, piemēram, HyperText Transfer Protocol (HTTP) vai Simple Mail Transfer Protocol (SMTP).
- Apkalpošana: Uz servera balstīta lietojumprogramma vai programmatūras sastāvdaļa, kas klientiem atklāj resursu, izmantojot ziņojumu apmaiņu saskaņā ar ziņojumu apmaiņas modeli (MEP). Pieprasījuma-atbildes deputāts ir tipisks.
Ņemot vērā šīs definīcijas, a Tīmekļa pakalpojums ir servera bāzes lietojumprogramma / programmatūras sastāvdaļa, kas, izmantojot ziņojumu apmaiņu, klientiem atklāj tīmekļa resursu. Šie ziņojumi var būt formatēti pēc paplašināmās iezīmēšanas valodas (XML) vai JavaScript objektu apzīmējuma (JSON). Arī šos ziņojumus var uzskatīt par tīmekļa pakalpojumu funkciju izsaukšanu un izsaukšanas rezultātu saņemšanu. Šo ziņojumu apmaiņu ilustrē 1. attēls.
1. attēls. Klients piekļūst resursam, apmainoties ar ziņojumiem ar tīmekļa pakalpojumu
Uzņēmumi un tīmekļa pakalpojumi
Uzņēmumi izmanto tīmekļa pakalpojumus, jo tie pārvar tradicionālās starpprogrammatūras problēmas (piemēram, dārgas, lai iegūtu un uzturētu, nespēj sazināties ar aizmugurējo programmatūru un klientu lietojumprogrammām internetā un ir neelastīgas), balstoties uz brīviem un atvērtiem standartiem, to uzturamību, iesaistot tīmeklī un elastīgi. Turklāt tie palīdz lielākiem uzņēmumiem saglabāt bieži vien nozīmīgos ieguldījumus mantotajā programmatūrā.
Tīmekļa pakalpojumus var klasificēt kā vienkāršus vai sarežģītus. Vienkārši tīmekļa pakalpojumi nedarbojas ar citiem tīmekļa pakalpojumiem (piemēram, atsevišķu servera lietojumprogrammu ar vienu funkciju, kas atgriež pašreizējo laiku norādītajai laika joslai). Turpretī sarežģīti tīmekļa pakalpojumi bieži mijiedarbojas ar citiem tīmekļa pakalpojumiem. Piemēram, vispārināts sociālā tīkla tīmekļa pakalpojums var mijiedarboties ar Twitter un Facebook tīmekļa pakalpojumiem, lai iegūtu un atgrieztu klientam visu Twitter un visu informāciju par konkrētu personu. Kompleksie tīmekļa pakalpojumi ir pazīstami arī kā mashups jo viņi misu (apvienot) datus no vairākiem tīmekļa pakalpojumiem.
Uz pakalpojumu orientēta arhitektūra
Tīmekļa pakalpojumi ir Uz pakalpojumu orientēta arhitektūra (SOA), kas ir programmatūras projektēšanas stils, kad pakalpojumi tiek nodrošināti dažādiem programmatūras komponentiem, izmantojot sakaru protokolu tīklā. Iedomājieties SOA kā dizaina principu kopumu vai ietvaru biznesa loģikas ieviešanai kā atkārtoti izmantojamus pakalpojumus, kurus var dažādos veidos apvienot, lai apmierinātu mainīgās biznesa prasības.
SOAP balstīti tīmekļa pakalpojumi
A Uz ziepēm balstīts tīmekļa pakalpojums ir plaši izmantota tīmekļa pakalpojumu kategorija, kuras pamatā ir ZIEPES, XML valoda definēšanai ziņas (abstraktas funkciju izsaukumi vai to atbildes), ko var saprast abos tīkla savienojuma galos. SOAP ziņojumu apmaiņu sauc par darbība, kas atbilst funkciju izsaukumam un tā reakcijai un ir attēlots 2. attēlā.
2. attēls. Tīmekļa pakalpojuma darbība ietver ievades un izvades ziņojumus
Saistītās darbības bieži tiek sagrupētas interfeiss, kas konceptuāli ir līdzīgs Java interfeisam. A saistošs sniedz konkrētu informāciju par to, kā saskarne ir saistīta ar ziņojumapmaiņas protokolu (īpaši SOAP), lai pa vadu paziņotu komandas, kļūdu kodus un citus vienumus. Iesiešana un a tīkla adrese (IP adrese un ports) URI ir pazīstams kā galapunkts, un galapunktu kolekcija ir a Tīmekļa pakalpojums. 3. attēlā parādīta šī arhitektūra.
3. attēls. Operāciju saskarnes ir pieejamas, izmantojot to galapunktus
Ziepes bieži lieto kopā ar Tīmekļa pakalpojumu apraksta valoda (WSDL, izrunā dumjš), XML valoda Web pakalpojuma darbību definēšanai. A WSDL dokuments ir oficiāls līgums starp SOAP balstītu tīmekļa pakalpojumu un tā klientiem, sniedzot visu informāciju mijiedarbībai ar tīmekļa pakalpojumu. Šis dokuments ļauj grupēt ziņojumus operācijās un operācijas saskarnēs. Tas arī ļauj jums noteikt saikni katram interfeisam, kā arī galapunkta adresi.
Līdztekus WSDL dokumentu atbalstam, uz SOAP balstītiem tīmekļa pakalpojumiem ir šādas īpašības:
- Spēja risināt sarežģītas nefunkcionālas prasības, piemēram, drošību un darījumus: Šīs prasības ir pieejamas, izmantojot dažādas specifikācijas. Lai veicinātu šo specifikāciju savstarpēju izmantojamību, Tīmekļa pakalpojumu sadarbspējas organizācija (WS-I) (nozares konsorcijs) tika izveidots. WS-I ir izveidojis profilu kopu, kur a profils ir nosaukto tīmekļa pakalpojumu specifikāciju kopums īpašos pārskatīšanas līmeņos, kā arī ieviešanas un savietojamības vadlīniju kopums, kurā ieteikts, kā specifikācijas var izmantot sadarbspējīgu tīmekļa pakalpojumu izstrādei. Piemēram, pats pirmais profils, WS-I pamata profils 1.0, sastāv no šāda nepatentētu tīmekļa pakalpojumu specifikāciju kopuma:
- ZIEPES 1.1
- WSDL 1.1
- Universālā apraksta atklāšana un integrācija (UDDI) 2.0
- XML 1.0 (otrais izdevums)
- XML shēmas 1. daļa: struktūras
- XML shēmas 2. daļa: datu tipi
- RFC2246: transporta slāņa drošības protokola versija 1.0
- RFC2459: Interneta X.509 publiskās atslēgas infrastruktūras sertifikāts un KRL profils
- RFC2616: HyperText pārsūtīšanas protokols 1.1
- RFC2818: HTTP, izmantojot TLS
- RFC2965: HTTP stāvokļa pārvaldības mehānisms
- Secure Sockets Layer Protocol 3.0 versija
Papildu profila piemēri ietver WS-I pamata drošības profilu un vienkāršo SOAP saistošo profilu. Lai iegūtu papildinformāciju par šiem un citiem profiliem, apmeklējiet vietni WS-I. Java SE atbalsta WS-I pamata profilu.
- Spēja asinhroni mijiedarboties ar tīmekļa pakalpojumu: Tīmekļa pakalpojumu klientiem jāspēj mijiedarboties ar tīmekļa pakalpojumu bez bloķēšanas un asinhronā veidā. Klienta puses asinhronā izsaukuma atbalsts tīmekļa pakalpojumu operācijām tiek nodrošināts Java SE.
SOAP bāzes tīmekļa pakalpojumi tiek izpildīti vidē, kurā ietilpst pakalpojumu pieprasītājs (klients), pakalpojumu sniedzējs un pakalpojumu brokeris. Šī vide ir parādīta 4. attēlā.
4. attēls. Uz SOAP balstīts tīmekļa pakalpojums ietver pakalpojumu pieprasītāju, pakalpojumu sniedzēju un pakalpojumu brokeri (piemēram, UDDI)
Pakalpojuma pieprasītājs, parasti klienta lietojumprogramma (piemēram, tīmekļa pārlūks) vai, iespējams, cits tīmekļa pakalpojums, vispirms kaut kādā veidā atrod pakalpojumu sniedzēju. Piemēram, pakalpojuma pieprasītājs var nosūtīt WSDL dokumentu pakalpojumu brokerim, kurš atbild ar citu WSDL dokumentu, identificējot pakalpojumu sniedzēja atrašanās vietu. Pēc tam pakalpojuma pieprasītājs sazinās ar pakalpojumu sniedzēju, izmantojot SOAP ziņojumus.
Pakalpojumu sniedzēji ir jāpublicē, lai citi varētu tos atrast un izmantot. 2000. gada augustā atklāta nozares iniciatīva, kas pazīstama kā Universāls apraksts, atklāšana un integrācija (UDDI) tika uzsākta, lai ļautu uzņēmumiem publicēt pakalpojumu sarakstus, atrast viens otru un noteikt, kā pakalpojumi vai programmatūras lietojumprogrammas mijiedarbojas internetā. Tomēr šis no platformas neatkarīgais, uz XML balstītais reģistrs netika plaši pieņemts un pašlaik netiek izmantots. Daudzi izstrādātāji uzskatīja, ka UDDI ir pārāk sarežģīts un tam nav funkcionalitātes, un izvēlējās tādas alternatīvas kā informācijas publicēšana vietnē. Piemēram, Google savulaik savus publiskos tīmekļa pakalpojumus (piemēram, Google Maps) padarīja pieejamus vietnē //code.google.com/more/.
SOAP ziņojumi, kas plūst starp pakalpojumu pieprasītājiem un pakalpojumu sniedzējiem, bieži nav redzami, un tie tiek nodoti kā pieprasījumi un atbildes starp viņu tīmekļa pakalpojumu protokola SOAP bibliotēkām. Tomēr ir iespējams tieši piekļūt šiem ziņojumiem, kā jūs uzzināsit vēlāk šajā sērijā.
Lielie tīmekļa pakalpojumi
SOAP bāzes tīmekļa pakalpojumi ir pazīstami arī kā lieli tīmekļa pakalpojumi jo tie ir balstīti uz daudzām specifikācijām, piemēram, iepriekš pieminētajiem WS-I profiliem.
RESTful tīmekļa pakalpojumi
Uz SOAP balstītos tīmekļa pakalpojumus var piegādāt, izmantojot tādus protokolus kā HTTP, SMTP, FTP un Blocks Extensible Exchange Protocol (BEEP). SOAP ziņojumu piegādi, izmantojot HTTP, var uzskatīt par īpaša veida RESTful tīmekļa pakalpojumu.
A RESTful tīmekļa pakalpojums ir plaši izmantota tīmekļa pakalpojumu kategorija, kuras pamatā ir Pārstāvniecības valsts nodošana (REST), programmatūras arhitektūras stils izplatītam hipermēdijas sistēmas (sistēmas, kurās attēli, teksts un citi resursi atrodas ap tīkliem un ir pieejami, izmantojot hipersaites). Hipermediju sistēma, kas interesē tīmekļa pakalpojumu kontekstā, ir globālais tīmeklis.
REST vēsture
Rojs Fīldings (galvenais HTTP specifikāciju 1.0 un 1.1 versiju autors un Apache programmatūras fonda līdzdibinātājs) jau 2000. gadā savā doktora disertācijā ieviesa un definēja REST. Fielding REST paredzēja kā tīmekļa arhitektūras stilu, lai gan viņš rakstīja ilgi pēc tam, kad tīmeklis turpināja darboties. REST tiek plaši uzskatīts par risinājumu tam, kas tiek uzskatīts par arvien pieaugošo SOAP balstīto tīmekļa pakalpojumu sarežģītību.
REST centrālā daļa ir URI identificējams resurss. REST resursus identificē pēc to daudzfunkcionālajiem interneta pasta paplašinājumu (MIME) tipiem (piemēram, text / xml). Arī resursiem ir valstis, kuras uztver viņu pārstāvniecības. Kad klients pieprasa resursu no RESTful tīmekļa pakalpojuma, pakalpojums klientam nosūta MIME rakstītu resursa attēlojumu.
Klienti izmanto HTTP POST, GET, PUT un DELETE darbības vārdus, lai izgūtu resursu attēlojumus un manipulētu ar resursiem. REST šos darbības vārdus datu bāzē Izveidot, lasīt, atjaunināt un dzēst (CRUD) veic šādas darbības:
- POST: izveidojiet jaunu resursu, pamatojoties uz pieprasījuma datiem.
- IEGŪT: lasiet esošo resursu, neradot blakusparādības (nemodificējiet resursu).
- PUT: atjauniniet esošo resursu ar pieprasījuma datiem.
- DZĒST: Dzēsiet esošo resursu.
Katram darbības vārdam seko URI, kas identificē resursu. (Šī ārkārtīgi vienkāršā pieeja ir būtībā nesaderīga ar SOAP pieeju kodētu ziņojumu sūtīšanai uz vienu resursu.) URI var atsaukties uz kolekciju, piemēram, //javajeff.ca/libraryvai kolekcijas elementam, piemēram, //javajeff.ca/library/9781484219157 - šie URI ir tikai ilustrācijas.
POST un PUT pieprasījumiem uz XML balstīti resursu dati tiek nodoti kā pieprasījuma pamatteksts. Piemēram, jūs varētu interpretēt POST //javajeff.ca/bibliotēka HTTP / 1.1 (kur HTTP / 1.1 apraksta pieprasītāja HTTP versiju) kā pieprasījumu ievietot POSTXML datus //javajeff.ca/library kolekcijas resurss.
GET un DELETE pieprasījumiem dati parasti tiek nodoti kā vaicājuma virknes, kur a vaicājuma virkne ir tā URI daļa, kas sākas ar a ? raksturs. Piemēram, kur IEGŪT //javajeff.ca/library var atgriezt visu a. grāmatu identifikatoru sarakstu bibliotēka resurss, IEGŪT //javajeff.ca/library?isbn=9781484219157 iespējams, atgriezīs grāmatas resursa attēlojumu, kura vaicājuma virkne identificē starptautisko standarta grāmatas numuru (ISBN) 9781484219157.
Uzziniet vairāk par HTTP-CRUD kartēšanu
Lai iegūtu pilnu aprakstu par kartēm starp HTTP darbības vārdiem un to CRUD kolēģiem, skatiet Vikipēdijas ieraksta Pārstāvniecības stāvokļa pārsūtīšana tabulu "RESTful Web Service HTTP metodes".
REST paļaujas arī uz HTTP standarta atbildes kodiem, piemēram, 404 (pieprasītais resurss nav atrasts) un 200 (resursu darbība ir veiksmīga), kā arī MIME tipiem (kad tiek izgūti resursu attēlojumi).
RESTful vs lielie tīmekļa pakalpojumi
Ja jūs domājat par to, vai attīstīt tīmekļa pakalpojumu, izmantojot SOAP vai REST, skatiet sadaļu RESTful Web Services vs "Big" Web Services: Pareiza arhitektūras lēmuma pieņemšana.
Tīmekļa pakalpojumu atbalsts Java SE
Pirms Java SE 6 Java balstīti tīmekļa pakalpojumi tika izstrādāti tikai ar Java Enterprise Edition (EE) SDK. Lai gan Java EE ir priekšroka tīmekļa pakalpojumu izstrādei no ražošanas viedokļa, jo Java EE bāzes serveri nodrošina ļoti augstu mērogojamību, drošības infrastruktūru, uzraudzības iespējas un tā tālāk, atkārtotu tīmekļa pakalpojuma izvietošanu Java EE konteiners bieži ir bijis laikietilpīgs, palēninot attīstību. Java SE 6 vienkāršoja un paātrināja tīmekļa pakalpojumu izstrādi, savā kodolā pievienojot API, anotācijas, rīkus un vieglu HTTP serveri (lai Web pakalpojumus izvietotu vienkāršā tīmekļa serverī un pārbaudītu tos šajā vidē).
API
Java SE nodrošina vairākas API, kas atbalsta tīmekļa pakalpojumus. Kopā ar dažādiem JAXP API (SAX, DOM, StAX un tā tālāk), kurus es apspriežu Java XML un JSON, Java SE nodrošina JAX-WS, JAXB un SAAJ API:
