Programiranje

Spletne storitve v Java SE, 1. del: Pregled orodij

Java Standard Edition (SE) 6 je vključeval podporo za spletne storitve. Ta objava začne s štiridelno serijo o spletnih storitvah v Java SE z razlago, kaj so spletne storitve, in s pregledom podpore Java SE zanje. Prihodnji prispevki bodo to podporo uporabili za izdelavo spletnih storitev, ki temeljijo na SOAP in RESTful, zajemale pa bodo tudi napredne teme spletnih storitev.

Java XML in JSON

V tej seriji predvidevam, da razumete XML in JSON. Če ne, boste morda želeli preveriti mojo Java XML in JSON knjiga, ki je objavljena na koncu tega prispevka.

Kaj so spletne storitve?

Wikipedia opredeljuje Spletna storitev kot "programski sistem, zasnovan za podporo interoperabilni interakciji med stroji in omrežjem." Podrobnejšo opredelitev lahko dobite tako, da najprej definirate dele tega izraza:

  • Splet: Ogromno medsebojno povezano omrežje virov, kjer a vir je vir podatkov z imenom Uniform Resource Identifier (URI), kot je dokument na osnovi PDF, video tok, spletna stran ali celo aplikacija. Do teh virov je mogoče dostopati s standardnimi internetnimi protokoli, kot sta protokol za prenos HyperText (HTTP) ali protokol za preprost prenos pošte (SMTP).
  • Storitev: Strežniška aplikacija ali komponenta programske opreme, ki odkrije vir odjemalcem prek izmenjave sporočil v skladu z vzorcem izmenjave sporočil (MEP). Evropski poslanec s prošnjo in odzivom je tipičen.

Glede na te opredelitve a Spletna storitev je strežniška aplikacijska / programska komponenta, ki strankam prek izmenjave sporočil izpostavi spletni vir. Ta sporočila so lahko oblikovana v skladu z razširljivim označevalnim jezikom (XML) ali JavaScript Object Notation (JSON). Ta sporočila lahko štejemo tudi za klicanje funkcij spletnih storitev in prejemanje rezultatov klicev. Slika 1 prikazuje to izmenjavo sporočil.

Slika 1. Naročnik dostopa do vira z izmenjavo sporočil s spletno storitvijo

Podjetja in spletne storitve

Podjetja uporabljajo spletne storitve, ker premagajo tradicionalne težave z vmesno programsko opremo (npr. Drage za pridobivanje in vzdrževanje, nezmožnosti komuniciranja z zaledno programsko opremo in odjemalskimi aplikacijami prek interneta ter nefleksibilnost), tako da temeljijo na brezplačnih in odprtih standardih, zaradi njihove vzdrževalnosti in splet in s prilagodljivostjo. Poleg tega večjim podjetjem pomagajo ohraniti pogosto pomembne naložbe v staro programsko opremo.

Spletne storitve lahko razvrstimo kot enostavne ali zapletene. Preproste spletne storitve ne delujejo z drugimi spletnimi storitvami (npr. Samostojna strežniška aplikacija z eno samo funkcijo, ki vrne trenutni čas za določen časovni pas). Nasprotno pa kompleksne spletne storitve pogosto komunicirajo z drugimi spletnimi storitvami. Na primer, splošna spletna storitev socialnega omrežja lahko komunicira s spletnimi storitvami Twitter in Facebook, da odjemalcu pridobi in vrne vse informacije o Twitterju in vse Facebook podatke za določenega posameznika. Kompleksne spletne storitve so znane tudi kot mešanice ker oni kaša (kombiniranje) podatkov iz več spletnih storitev.

Storitveno usmerjena arhitektura

Spletne storitve so izvedba Storitveno usmerjena arhitektura (SOA), ki je slog oblikovanja programske opreme, kjer se različne komunikacijske komponente zagotavljajo prek komunikacijskega protokola prek omrežja. SOA si predstavljajte kot sklop oblikovalskih načel ali okvir za izvajanje poslovne logike kot storitve za večkratno uporabo, ki jih je mogoče kombinirati na različne načine za izpolnjevanje spreminjajočih se poslovnih potreb.

Spletne storitve na osnovi SOAP

A Spletna storitev na osnovi SOAP je široko uporabljena kategorija spletnih storitev, ki temelji na MILO, jezik XML za definiranje sporočila (klici abstraktnih funkcij ali njihovi odzivi), ki jih lahko razumemo oba konca omrežne povezave. Izmenjava sporočil SOAP se imenuje delovanje, ki ustreza klicu funkcije in njegovemu odzivu ter prikazano na sliki 2.

Slika 2. Delovanje spletne storitve vključuje vhodna in izhodna sporočila

Povezane operacije so pogosto združene v vmesnik, ki je pojmovno podoben vmesniku Java. A zavezujoča ponuja konkretne podrobnosti o tem, kako je vmesnik vezan na protokol za sporočanje (zlasti SOAP), da prek žice sporoča ukaze, kode napak in druge elemente. Vezava in a omrežni naslov (naslov IP in vrata) URI je znan kot končna točka, in zbirka končnih točk je Spletna storitev. Slika 3 predstavlja to arhitekturo.

Slika 3. Vmesniki operacij so dostopni prek njihovih končnih točk

SOAP se pogosto uporablja z Jezik za opis spletnih storitev (WSDL, izrazito pisano dolgočasno), jezik XML za definiranje delovanja spletne storitve. A Dokument WSDL je uradna pogodba med spletno storitvijo, ki temelji na SOAP, in njenimi strankami, ki vsebuje vse podrobnosti za interakcijo s spletno storitvijo. Ta dokument vam omogoča združevanje sporočil v operacije in operacije v vmesnike. Omogoča vam tudi določitev vezave za vsak vmesnik in naslov končne točke.

Spletne storitve, ki temeljijo na SOAP, podpirajo dokumente WSDL in imajo naslednje lastnosti:

  • Sposobnost obravnavanja zapletenih nefunkcionalnih zahtev, kot so varnost in transakcije: Te zahteve so na voljo v različnih specifikacijah. Za spodbujanje interoperabilnosti med temi specifikacijami je Organizacija za interoperabilnost spletnih storitev (WS-I) (industrijski konzorcij). WS-I je vzpostavil nabor profilov, kjer a profil je nabor imenovanih specifikacij spletnih storitev na določenih revizijskih ravneh, skupaj z nizom smernic za izvajanje in interoperabilnost, ki priporočajo, kako se lahko specifikacije uporabijo za razvoj interoperabilnih spletnih storitev. Na primer, prvi profil, Osnovni profil WS-I 1.0, je sestavljen iz naslednjega niza lastniških specifikacij spletnih storitev:
  • MILO 1.1
  • WSDL 1.1
  • Univerzalni opis Odkrivanje in integracija (UDDI) 2.0
  • XML 1.0 (druga izdaja)
  • Shema XML 1. del: Strukture
  • Shema XML 2. del: Tipi podatkov
  • RFC2246: Varnostni protokol transportnega sloja različice 1.0
  • RFC2459: Potrdilo o infrastrukturi javnih ključev interneta X.509 in profil CRL
  • RFC2616: Protokol za prenos hiperteksta 1.1
  • RFC2818: HTTP prek TLS
  • RFC2965: Mehanizem upravljanja stanja HTTP
  • Protokol sloja Secure Sockets različice 3.0

Dodatna primera profila sta WS-I Basic Security Profile in Simple SOAP Binding Profile. Za več informacij o teh in drugih profilih obiščite spletno mesto WS-I. Java SE podpira osnovni profil WS-I.

  • Možnost asinhrone interakcije s spletno storitvijo: Stranke spletnih storitev bi morale imeti možnost, da s spletno storitvijo sodelujejo na neblokirajoč, asinhroni način. Podpora asinhronega klica na strani odjemalca pri operacijah spletnih storitev je na voljo v Java SE.

Spletne storitve, ki temeljijo na SOAP, se izvajajo v okolju, ki vključuje zahtevnika storitev (odjemalca), ponudnika storitev in posrednika storitev. To okolje je prikazano na sliki 4.

Slika 4. Spletna storitev, ki temelji na SOAP, vključuje zahtevnika storitev, ponudnika storitev in posrednika storitev (npr. UDDI)

Zahtevalec storitve, običajno odjemalska aplikacija (npr. Spletni brskalnik) ali morda druga spletna storitev, na nek način najprej najde ponudnika storitve. Naročnik storitve lahko na primer pošlje dokument WSDL posredniku storitev, ki odgovori z drugim dokumentom WSDL, ki določa lokacijo ponudnika storitev. Zahtevalec storitve nato komunicira s ponudnikom storitev prek sporočil SOAP.

Ponudnike storitev je treba objaviti, da jih bodo drugi lahko našli in uporabljali. Avgusta 2000 je odprta industrijska pobuda, znana kot Univerzalni opis, odkrivanje in integracija (UDDI) je bil uveden, da je podjetjem omogočil objavo seznamov storitev, odkrivanje drug drugega in opredelitev medsebojnega delovanja storitev ali programske opreme prek interneta. Vendar ta sistem, neodvisen od platforme, temelji na XML, ni bil splošno sprejet in se trenutno ne uporablja. Številni razvijalci so ugotovili, da je UDDI preveč zapleten in nima funkcionalnosti, zato so se odločili za druge možnosti, kot je objava informacij na spletnem mestu. Google je na primer svoje javne spletne storitve (npr. Google Zemljevide) nekoč dal na voljo na //code.google.com/more/.

Sporočila SOAP, ki se pretakajo med zahtevniki storitev in ponudniki storitev, so pogosto nevidna in se posredujejo kot zahteve in odgovori med knjižnicami SOAP njihovih skladov protokolov spletnih storitev. Vendar je do teh sporočil možen neposreden dostop, kot boste ugotovili kasneje v tej seriji.

Velike spletne storitve

Spletne storitve na osnovi SOAP so znane tudi kot velike spletne storitve ker temeljijo na številnih specifikacijah, kot so prej omenjeni profili WS-I.

RESTful spletne storitve

Spletne storitve, ki temeljijo na SOAP, je mogoče dostavljati prek protokolov, kot so HTTP, SMTP, FTP in Blocks Extensible Exchange Protocol (BEEP). Pošiljanje sporočil SOAP prek HTTP je mogoče obravnavati kot posebno vrsto spletne storitve RESTful.

A Spletna storitev RESTful je široko uporabljena kategorija spletnih storitev, ki temelji na Reprezentativni državni prenos (REST), slog arhitekturne programske opreme za distribucijo hipermedijski sistemi (sistemi, v katerih se slike, besedilo in drugi viri nahajajo okoli omrežij in so dostopni prek hiperpovezav). Hipermedijski sistem, ki nas zanima v kontekstu spletnih storitev, je svetovni splet.

Zgodovina REST

Roy Fielding (glavni avtor različic specifikacij HTTP 1.0 in 1.1 ter soustanovitelj fundacije Apache Software Foundation) je v svoji doktorski disertaciji predstavil in opredelil REST že leta 2000. Fielding si je REST zamislil kot arhitekturni slog spleta, čeprav je napisal dolgo po tem, ko je splet deloval. REST velja za rešitev vse večje zapletenosti spletnih storitev, ki temeljijo na SOAP.

Osrednji del REST-a je vir, ki ga je mogoče prepoznati po URI-ju. REST identificira vire po njihovih vrstah večnamenskih razširitev internetne pošte (MIME) (na primer text / xml). Tudi viri imajo države, ki jih zajamejo njihove predstavitve. Ko odjemalec zahteva vir od spletne storitve RESTful, storitev pošlje odjemalcu predstavitev vira v obliki MIME.

Odjemalci uporabljajo HTTP-jeve glagole POST, GET, PUT in DELETE za pridobivanje predstavitev virov in za manipulacijo virov. REST preslika te glagole v operacije ustvarjanja, branja, posodabljanja in brisanja (CRUD) baze podatkov, kot sledi:

  • POST: Ustvari nov vir na podlagi podatkov o zahtevah.
  • GET: preberite obstoječi vir brez povzročanja stranskih učinkov (vira ne spreminjajte).
  • PUT: posodobite obstoječi vir s podatki o zahtevah.
  • IZBRIŠI: Izbriši obstoječi vir.

Vsakemu glagolu sledi URI, ki identificira vir. (Ta izjemno preprost pristop je v osnovi nezdružljiv s pristopom SOAP k pošiljanju kodiranih sporočil enemu viru.) URI se lahko nanaša na zbirko, kot je npr. //javajeff.ca/library, ali elementu zbirke, kot je //javajeff.ca/library/9781484219157 - ti URI so samo ilustracije.

Za zahteve POST in PUT se podatki o virih, ki temeljijo na XML, posredujejo kot telo zahteve. Na primer, lahko tolmačite POST //javajeff.ca/library HTTP / 1.1 (kje HTTP / 1.1 opisuje različico HTTP prosilca) kot zahtevo za vstavljanje OBJAVIpodatki XML v //javajeff.ca/library vir zbiranja.

Pri zahtevah GET in DELETE se podatki običajno posredujejo kot nizi poizvedb, kjer a niz poizvedbe je tisti del URI-ja, ki se začne z ? znak. Na primer, kje GET //javajeff.ca/library lahko vrne seznam identifikatorjev za vse knjige v knjižnica vir, GET //javajeff.ca/library?isbn=9781484219157 bi verjetno vrnil predstavitev knjižnega vira, katerega poizvedbeni niz identificira mednarodno standardno številko knjige (ISBN) 9781484219157.

Spoznavanje več o preslikavah HTTP-CRUD

Za popoln opis preslikav med glagoli HTTP in njihovimi nasprotniki CRUD si oglejte tabelo »Metode HTTP RESTful Web Service« v Wikipedijinem vnosu Reprezentativni prenos države.

REST se zanaša tudi na standardne odzivne kode HTTP, na primer 404 (zahtevanega vira ni mogoče najti) in 200 (delovanje vira uspešno), skupaj z vrstami MIME (ko se pridobivajo predstavitve virov).

RESTful vs velike spletne storitve

Če se sprašujete, ali razviti spletno storitev z uporabo SOAP ali REST, si oglejte RESTful Web Services v primerjavi z "Big" spletnimi storitvami: sprejemanje pravilne arhitekturne odločitve.

Podpora za spletne storitve v Java SE

Pred Java SE 6 so bile spletne storitve, ki temeljijo na Javi, razvite izključno s programsko opremo Java Enterprise Edition (EE) SDK. Čeprav je Java EE prednostna za razvoj spletnih storitev s proizvodnega vidika, ker strežniki, ki temeljijo na Java EE, zagotavljajo zelo visoko stopnjo razširljivosti, varnostno infrastrukturo, nadzorne naprave in tako naprej, večkratno uvajanje spletne storitve v Java EE posoda je bila pogosto zamudna in upočasnjuje razvoj. Java SE 6 je poenostavil in pospešil razvoj spletnih storitev, tako da je v svoje jedro dodal API-je, pripise, orodja in lahek strežnik HTTP (za uvajanje spletnih storitev na preprost spletni strežnik in njihovo preizkušanje v tem okolju).

API-ji

Java SE ponuja več API-jev, ki podpirajo spletne storitve. Skupaj z različnimi API-ji JAXP (SAX, DOM, StAX itd.), O katerih razpravljam v Java XML in JSON, Java SE ponuja API-je JAX-WS, JAXB in SAAJ:

$config[zx-auto] not found$config[zx-overlay] not found