Java Standard Edition (SE) 6 sisälsi verkkopalvelujen tuen. Tämä viesti aloittaa neliosaisen sarjan Java SE: n verkkopalveluista selittämällä, mitkä verkkopalvelut ovat, ja esittelemällä Java SE: n tuen heille. Tulevat viestit käyttävät tätä tukea SOAP- ja RESTful-pohjaisten verkkopalvelujen rakentamiseen, ja ne kattavat myös edistyneet verkkopalvelun aiheet.
Java XML ja JSON
Oletan, että tässä sarjassa ymmärrät XML: n ja JSON: n. Jos ei, haluat ehkä tarkistaa minun Java XML ja JSON kirja, jota mainostetaan tämän viestin lopussa.
Mitä verkkopalvelut ovat?
Wikipedia määrittelee Verkkopalvelu "ohjelmistojärjestelmänä, joka on suunniteltu tukemaan yhteentoimivaa koneiden välistä vuorovaikutusta verkon kautta". Tarkempi määritelmä saadaan määrittelemällä ensin tämän termin osat:
- Verkko: Valtava yhteenliitetty resurssiverkosto, jossa a resurssi on Uniform Resource Identifier (URI) -niminen tietolähde, kuten PDF-pohjainen asiakirja, videovirta, verkkosivu tai jopa sovellus. Näihin resursseihin pääsee käyttämällä tavallisia Internet-protokollia, kuten HyperText Transfer Protocol (HTTP) tai Simple Mail Transfer Protocol (SMTP).
- Palvelu: Palvelinpohjainen sovellus tai ohjelmistokomponentti, joka paljastaa resurssin asiakkaille viestinvaihdon avulla viestinvaihtomallin (MEP) mukaisesti. Pyyntö-vastaus MEP on tyypillinen.
Näiden määritelmien perusteella a Verkkopalvelu on palvelinpohjainen sovellus / ohjelmistokomponentti, joka paljastaa verkkopohjaisen resurssin asiakkaille viestien vaihdon kautta. Nämä viestit voidaan muotoilla XML (Extensible Markup Language) - tai JavaScriptiobjektikirjauksen (JSON) mukaan. Näiden viestien voidaan myös ajatella kutsuvan verkkopalvelutoimintoja ja vastaanottavan kutsutuloksia. Kuva 1 kuvaa tätä sanomanvaihtoa.
Kuva 1. Asiakas käyttää resurssia vaihtamalla viestejä verkkopalvelun kanssa
Yritykset ja verkkopalvelut
Yritykset käyttävät verkkopalveluja, koska ne selviävät perinteisistä väliohjelmisto-ongelmista (esim. Kalliit hankkia ja ylläpitää, eivät pysty kommunikoimaan taustajärjestelmien ja asiakassovellusten kanssa Internetissä ja joustamattomat) perustuen vapaisiin ja avoimiin standardeihin, ylläpidettävyytensä avulla, mukaan lukien webissä ja olemalla joustava. Lisäksi ne auttavat suurempia yrityksiä säilyttämään usein merkittävät investoinnit vanhoihin ohjelmistoihin.
Verkkopalvelut voidaan luokitella yksinkertaisiksi tai monimutkaisiksi. Yksinkertaiset verkkopalvelut eivät ole vuorovaikutuksessa muiden verkkopalvelujen kanssa (esim. Erillinen palvelinpohjainen sovellus, jossa on yksi toiminto, joka palauttaa nykyisen ajan tietylle aikavyöhykkeelle). Sitä vastoin monimutkaiset verkkopalvelut ovat usein vuorovaikutuksessa muiden verkkopalvelujen kanssa. Esimerkiksi yleinen sosiaalisen verkoston verkkopalvelu voi olla vuorovaikutuksessa Twitterin ja Facebookin verkkopalvelujen kanssa saadakseen ja palauttamaan asiakkaalleen kaikki Twitterin ja kaikki tietyn henkilön Facebook-tiedot. Monimutkaiset verkkopalvelut tunnetaan myös nimellä mashups koska he mash (yhdistää) tietoja useista verkkopalveluista.
Palvelukeskeinen arkkitehtuuri
Verkkopalvelut ovat Palvelukeskeinen arkkitehtuuri (SOA), joka on ohjelmistosuunnittelutyyli, jossa palveluja tarjotaan eri ohjelmistokomponenteille tietoliikenneprotokollan kautta verkon kautta. Ajattele SOA: ta joukkoa suunnitteluperiaatteita tai kehystä liiketoimintalogiikan toteuttamiseksi uudelleenkäytettävinä palveluina, jotka voidaan yhdistää eri tavoin vastaamaan muuttuvia liiketoiminnan vaatimuksia.
SOAP-pohjaiset verkkopalvelut
A SOAP-pohjainen verkkopalvelu on laajalti käytetty verkkopalveluluokka, joka perustuu SAIPPUA, XML-kieli määrittelyä varten viestejä (abstraktit funktiokutsut tai niiden vastaukset), jotka voidaan ymmärtää verkkoyhteyden molemmissa päissä. SOAP-sanomien vaihtoa kutsutaan operaatio, joka vastaa toimintokutsua ja sen vastausta ja joka on esitetty kuvassa 2.
Kuva 2. Verkkopalvelutoiminto sisältää tulo- ja lähtöviestejä
Aiheeseen liittyvät toiminnot ryhmitellään usein käyttöliittymä, joka on käsitteellisesti samanlainen kuin Java-käyttöliittymä. A sitova tarjoaa konkreettisia yksityiskohtia siitä, kuinka rajapinta on sidottu viestintäkäytäntöihin (erityisesti SOAP: iin) komentojen, virhekoodien ja muiden kohteiden kommunikoimiseksi langan kautta. Sidonta ja a verkko-osoite (IP-osoite ja portti) URI tunnetaan nimellä päätepiste, ja kokoelma päätepisteitä on a Verkkopalvelu. Kuvassa 3 on esitetty tämä arkkitehtuuri.
Kuva 3. Operaatioiden rajapinnoille pääsee niiden päätepisteiden kautta
SOAPia käytetään usein Verkkopalvelujen kuvauskieli (WSDL, lausutaan hiljaiseksi), XML-kieli verkkopalvelun toiminnan määrittelemiseksi. A WSDL-asiakirja on muodollinen sopimus SOAP-pohjaisen verkkopalvelun ja sen asiakkaiden välillä, joka sisältää kaikki tiedot verkkopalvelun kanssa tapahtuvasta vuorovaikutuksesta. Tämän asiakirjan avulla voit ryhmitellä viestit toimintoihin ja operaatiot rajapintoihin. Sen avulla voit myös määrittää sitomisen kullekin käyttöliittymälle sekä päätepisteosoitteen.
SOAP-pohjaisilla verkkopalveluilla on WSDL-asiakirjojen tukemisen lisäksi seuraavat ominaisuudet:
- Kyky vastata monimutkaisiin ei-toiminnallisiin vaatimuksiin, kuten tietoturva ja tapahtumat: Nämä vaatimukset asetetaan saataville useiden eritelmien avulla. Edistääkseen näiden eritelmien yhteentoimivuutta, Verkkopalvelujen yhteentoimivuusorganisaatio (WS-I) (teollisuuden yhteenliittymä) perustettiin. WS-I on perustanut joukon profiileja, joissa a profiili on joukko nimettyjä verkkopalvelumäärityksiä tietyillä versiotasoilla sekä joukko toteutus- ja yhteentoimivuusohjeita, joissa suositellaan, kuinka eritelmiä voidaan käyttää yhteentoimivien verkkopalvelujen kehittämiseen. Esimerkiksi ensimmäinen profiili, WS-I-perusprofiili 1.0, koostuu seuraavista joukosta ei-patentoituja verkkopalvelumäärityksiä:
- Saippua 1.1
- WSDL 1.1
- Universal Description Discovery and Integration (UDDI) 2.0
- XML 1.0 (toinen painos)
- XML-malli 1: Rakenteet
- XML-skeema, osa 2: tietotyypit
- RFC2246: Kuljetustason suojausprotokollan versio 1.0
- RFC2459: Internet X.509 julkisen avaimen infrastruktuurin varmenne ja CRL-profiili
- RFC2616: HyperText Transfer Protocol 1.1
- RFC2818: HTTP TLS: n kautta
- RFC2965: HTTP-tilan hallintamekanismi
- Secure Sockets Layer Protocol Version 3.0
Muita profiiliesimerkkejä ovat WS-I Basic Security Profile ja Simple SOAP Binding Profile. Lisätietoja näistä ja muista profiileista on WS-I-verkkosivustolla. Java SE tukee WS-I Basic -profiilia.
- Kyky olla vuorovaikutuksessa verkkopalvelun kanssa asynkronisesti: Verkkopalveluasiakkaiden tulisi pystyä olemaan vuorovaikutuksessa verkkopalvelun kanssa estämättömällä, asynkronisella tavalla. Web-palvelutoimintojen asiakaspuolen asynkroninen kutsutuki tarjotaan Java SE: ssä.
SOAP-pohjaiset verkkopalvelut suoritetaan ympäristössä, johon kuuluvat palvelun pyytäjä (asiakas), palveluntarjoaja ja palvelujen välittäjä. Tämä ympäristö on esitetty kuvassa 4.
Kuva 4. SOAP-pohjainen verkkopalvelu sisältää palvelun pyynnön tekijän, palveluntarjoajan ja palvelun välittäjän (esim. UDDI)
Palvelun pyytäjä, tyypillisesti asiakassovellus (esim. Verkkoselain) tai kenties toinen verkkopalvelu, etsii ensin palveluntarjoajan jollakin tavalla. Esimerkiksi palvelun pyytäjä saattaa lähettää WSDL-asiakirjan palvelunvälittäjälle, joka vastaa toisella WSDL-asiakirjalla, joka tunnistaa palveluntarjoajan sijainnin. Palvelupyynnön esittäjä kommunikoi sitten palveluntarjoajan kanssa SOAP-viesteillä.
Palveluntarjoajat on julkaistava, jotta muut voivat löytää ja käyttää niitä. Elokuussa 2000 avoimen teollisuuden aloite tunnetaan nimellä Yleinen kuvaus, haku ja integrointi (UDDI) käynnistettiin, jotta yritykset voivat julkaista palveluluetteloita, löytää toisiaan ja määritellä, miten palvelut tai ohjelmistosovellukset ovat vuorovaikutuksessa Internetin kautta. Tätä alustasta riippumatonta, XML-pohjaista rekisteriä ei kuitenkaan otettu laajalti käyttöön, eikä sitä tällä hetkellä käytetä. Monet kehittäjät havaitsivat UDDI: n olevan liian monimutkainen ja puutteellinen toiminnallisuudessa, ja valitsivat vaihtoehtoja, kuten tietojen julkaisemisen verkkosivustolla. Esimerkiksi Google on kerran asettanut julkiset verkkopalvelunsa (esim. Google Maps) saataville osoitteeseen //code.google.com/more/.
Palvelun pyytäjien ja palveluntarjoajien välillä kulkevat SOAP-viestit ovat usein näkymättömiä, ja ne välitetään pyynnöinä ja vastauksina heidän verkkopalveluprotokollansa SOAP-kirjastojen välillä. Näihin viesteihin on kuitenkin mahdollista päästä suoraan, kuten huomaat myöhemmin tässä sarjassa.
Suuret verkkopalvelut
SOAP-pohjaiset verkkopalvelut tunnetaan myös nimellä suuret verkkopalvelut koska ne perustuvat moniin eritelmiin, kuten aiemmin mainittuihin WS-I-profiileihin.
RESTful-verkkopalvelut
SOAP-pohjaiset verkkopalvelut voidaan toimittaa protokollien, kuten HTTP, SMTP, FTP ja Blocks Extensible Exchange Protocol (BEEP), kautta. SOAP-viestien toimittamista HTTP: n kautta voidaan pitää erityisenä RESTful-verkkopalveluna.
A RESTful-verkkopalvelu on laajalti käytetty verkkopalveluluokka, joka perustuu Edustavan valtion siirto (REST), hajautetun ohjelmistoarkkitehtuurin tyyli hypermediajärjestelmät (järjestelmät, joissa kuvat, teksti ja muut resurssit sijaitsevat verkkojen ympärillä ja joihin pääsee hyperlinkkien kautta). Web-palvelujen yhteydessä kiinnostava hypermediajärjestelmä on World Wide Web.
REST-historia
Roy Fielding (HTTP-määritysversioiden 1.0 ja 1.1 pääkirjailija ja Apache Software Foundationin perustaja) esitteli ja määritteli REST-väitöskirjassaan vuonna 2000. Fielding kuvitteli REST: n olevan verkon arkkitehtoninen tyyli, vaikka hän kirjoitti. se kesti kauan sen jälkeen kun verkko oli jatkuva ongelma. REST: ää pidetään laajalti ratkaisuna siihen, mitä pidetään SOAP-pohjaisten verkkopalvelujen kasvavana monimutkaisuutena.
REST: n keskeinen osa on URI-tunnistettavissa oleva resurssi. REST tunnistaa resurssit niiden monikäyttöisten Internet Mail Extensions (MIME) -tyyppien (kuten teksti / xml) perusteella. Resursseilla on myös tiloja, jotka heidän edustuksensa vangitsevat. Kun asiakas pyytää resurssia RESTful-verkkopalvelulta, palvelu lähettää resurssille MIME-tyypin esityksen asiakkaalle.
Asiakkaat käyttävät HTTP: n POST-, GET-, PUT- ja DELETE-verbejä resurssien esitysten noutamiseen ja resurssien käsittelyyn. REST yhdistää nämä verbit tietokantaan Luo, Lue, Päivitä ja Poista (CRUD) -operaatiot seuraavasti:
- POST: Luo uusi resurssi pyyntötietojen perusteella.
- GET: Lue olemassa oleva resurssi tuottamatta sivuvaikutuksia (älä muokkaa resurssia).
- PUT: Päivitä nykyinen resurssi pyyntötiedoilla.
- POISTA: Poista olemassa oleva resurssi.
Kutakin verbiä seuraa URI, joka tunnistaa resurssin. (Tämä äärimmäisen yksinkertainen lähestymistapa on pohjimmiltaan yhteensopimaton SOAP: n lähestymistavan kanssa lähettää koodatut viestit yhdelle resurssille.) URI saattaa viitata kokoelmaan, kuten //javajeff.ca/librarytai kokoelman osaan, kuten //javajeff.ca/library/9781484219157 - nämä URI: t ovat vain piirroksia.
POST- ja PUT-pyynnöille XML-pohjaiset resurssitiedot välitetään pyynnön rungoksi. Voit esimerkiksi tulkita POST //javajeff.ca/kirjasto HTTP / 1.1 (missä HTTP / 1.1 kuvaa pyynnön esittäjän HTTP-versiota) lisäyspyynnönä LÄHETTÄÄXML - tiedot //javajeff.ca/library kokoelmaresurssi.
GET- ja DELETE-pyynnöissä tiedot välitetään yleensä kyselymerkkijonoina, joissa a kyselymerkkijono on se osa URI: sta, joka alkaa a: lla ? merkki. Esimerkiksi missä GET //javajeff.ca/kirjasto saattaa palauttaa luettelon tunnisteista kaikille a. kirjoille kirjasto resurssi, GET //javajeff.ca/library?isbn=9781484219157 palauttaisi todennäköisesti kirjan resurssin esityksen, jonka kyselymerkkijono identifioi kansainvälisen standardin kirjanumeron (ISBN) 9781484219157.
Lisätietoja HTTP-CRUD-kartoituksista
Täydellinen kuvaus HTTP-verbien ja niiden CRUD-vastineiden välisestä yhdistämisestä on Wikipedian edustustilan siirron merkinnän "RESTful Web Service HTTP method" -taulukossa.
REST luottaa myös HTTP: n vakiovastekoodeihin, kuten 404 (pyydettyä resurssia ei löydy) ja 200 (resurssioperaatio onnistui), yhdessä MIME-tyyppien kanssa (kun resurssien esityksiä haetaan).
RESTful vs suuret verkkopalvelut
Jos mietit, kehitätkö verkkopalvelua SOAP: lla tai REST: llä, tutustu kohtaan RESTful Web Services vs. "Big" Web Services: oikean arkkitehtonisen päätöksen tekeminen.
Verkkopalvelutuki Java SE: ssä
Ennen Java SE 6: ta Java-pohjaiset verkkopalvelut kehitettiin yksinomaan Java Enterprise Edition (EE) SDK: n avulla. Vaikka Java EE on suositeltava verkkopalvelujen kehittämiseksi tuotannon näkökulmasta, koska Java EE-pohjaiset palvelimet tarjoavat erittäin suuren skaalautuvuuden, tietoturvainfrastruktuurin, valvontatilat ja niin edelleen, verkkopalvelun toistuva käyttöönotto Java EE: ssä kontti on usein ollut aikaa vievää, hidastanut kehitystä. Java SE 6 yksinkertaisti ja nopeutti verkkopalvelujen kehittämistä lisäämällä sen ytimeen API: t, merkinnät, työkalut ja kevyen HTTP-palvelimen (verkkopalvelujen käyttöönottamiseksi yksinkertaiseen Web-palvelimeen ja niiden testaamiseen tässä ympäristössä).
Sovellusliittymät
Java SE tarjoaa useita sovellusliittymiä, jotka tukevat verkkopalveluita. Yhdessä useiden JAXP-sovellusliittymien (SAX, DOM, StAX ja niin edelleen) kanssa, joista keskustelen Java XML ja JSON, Java SE tarjoaa JAX-WS-, JAXB- ja SAAJ-sovellusliittymät:
