Java Standard Edition (SE) 6 inkluderte støtte for webtjenester. Dette innlegget starter en firedelts serie om webtjenester i Java SE ved å forklare hva webtjenester er og oversikt over Java SEs støtte for dem. Fremtidige innlegg vil bruke denne støtten til å bygge SOAP-baserte og RESTful-baserte webtjenester, og vil også dekke avanserte emner for webtjenester.
Java XML og JSON
I denne serien antar jeg at du forstår XML og JSON. Hvis ikke, vil du kanskje sjekke ut min Java XML og JSON bok, som blir annonsert på slutten av dette innlegget.
Hva er nettjenester?
Wikipedia definerer nettjeneste som "et programvaresystem designet for å støtte interoperabel maskin-til-maskin-interaksjon over et nettverk." En mer detaljert definisjon kan oppnås ved først å definere delene av dette begrepet:
- Internett: Et enormt sammenkoblet nettverk av ressurser, der en ressurs er en Uniform Resource Identifier (URI) -kalt datakilde, for eksempel et PDF-basert dokument, en videostrøm, en webside eller til og med en applikasjon. Du kan få tilgang til disse ressursene ved å bruke standard internettprotokoller som HyperText Transfer Protocol (HTTP) eller Simple Mail Transfer Protocol (SMTP).
- Service: En serverbasert applikasjon eller programvarekomponent som avslører en ressurs for klienter via utveksling av meldinger i henhold til et meldingsutvekslingsmønster (MEP). MEP-en forespørselssvar er typisk.
Gitt disse definisjonene, a nettjeneste er en serverbasert applikasjons- / programvarekomponent som eksponerer en nettbasert ressurs for klienter via utveksling av meldinger. Disse meldingene kan være formatert i henhold til Extensible Markup Language (XML) eller JavaScript Object Notation (JSON). Disse meldingene kan også betraktes som å påkalle nettjenestefunksjoner og motta påkallingsresultater. Figur 1 illustrerer denne meldingsutvekslingen.
Figur 1. En klient får tilgang til en ressurs ved å utveksle meldinger med en webtjeneste
Bedrifter og webtjenester
Bedrifter bruker webtjenester fordi de overvinner tradisjonelle mellomvareproblemer (f.eks. Dyre å skaffe og vedlikeholde, ute av stand til å kommunisere med backend-programvare og klientapplikasjoner over Internett og ufleksible) ved å være basert på gratis og åpne standarder, ved å vedlikeholde dem, ved å involvere Internett, og ved å være fleksibel. Videre hjelper de større bedrifter med å bevare sine ofte betydelige investeringer i eldre programvare.
Webtjenester kan klassifiseres som enkle eller komplekse. Enkle webtjenester samhandler ikke med andre webtjenester (f.eks. Et frittstående serverbasert program med en enkelt funksjon som returnerer gjeldende tid for en spesifisert tidssone). I motsetning til dette kommuniserer ofte komplekse webtjenester med andre webtjenester. For eksempel kan et generelt sosialt nettverkstjeneste samhandle med Twitter og Facebook Web-tjenester for å skaffe og returnere til sin klient all Twitter og all Facebook-informasjon for et bestemt individ. Komplekse webtjenester er også kjent som mashups fordi de Mos (kombinere) data fra flere webtjenester.
Service Orientert Arkitektur
Webtjenester er en implementering av Serviceorientert arkitektur (SOA), som er en stil med programvaredesign der tjenester leveres til forskjellige programvarekomponenter gjennom en kommunikasjonsprotokoll over et nettverk. Tenk på SOA som et sett med designprinsipper eller et rammeverk for implementering av forretningslogikk som gjenbrukbare tjenester som kan kombineres på forskjellige måter for å møte utviklende forretningskrav.
SOAP-baserte nettjenester
EN SOAP-basert nettjeneste er en mye brukt webtjenestekategori som er basert på SÅPE, et XML-språk for å definere meldinger (abstrakte funksjonsinnkallinger eller deres svar) som kan forstås av begge ender av en nettverkstilkobling. En utveksling av SOAP-meldinger kalles en operasjon, som tilsvarer et funksjonsanrop og dets respons, og som er avbildet i figur 2.
Figur 2. En nettjenesteoperasjon innebærer inn- og utgangsmeldinger
Beslektede operasjoner er ofte gruppert i en grensesnitt, som konseptuelt ligner på et Java-grensesnitt. EN bindende gir konkrete detaljer om hvordan et grensesnitt er bundet til en meldingsprotokoll (spesielt SOAP) for å kommunisere kommandoer, feilkoder og andre elementer over ledningen. Bindingen og a nettverksadresse (en IP-adresse og en port) URI er kjent som en endepunkt, og en samling endepunkter er en nettjeneste. Figur 3 presenterer denne arkitekturen.
Figur 3. Grensesnitt for operasjoner er tilgjengelige via endepunktene
SOAP brukes ofte med Webtjenester Beskrivelse språk (WSDL, uttalt whiz-kjedelig), et XML-språk for å definere en nettjenestes virksomhet. EN WSDL-dokument er en formell kontrakt mellom en SOAP-basert webtjeneste og dens klienter, som gir alle detaljer for samhandling med nettjenesten. Dette dokumentet lar deg gruppere meldinger i operasjoner og operasjoner i grensesnitt. Den lar deg også definere en binding for hvert grensesnitt, samt endepunktadressen.
I tillegg til å støtte WSDL-dokumenter, har SOAP-baserte webtjenester følgende egenskaper:
- Evnen til å håndtere komplekse ikke-funksjonelle krav som sikkerhet og transaksjoner: Disse kravene gjøres tilgjengelige via forskjellige spesifikasjoner. For å fremme interoperabilitet mellom disse spesifikasjonene, har Web Services Interoperability Organization (WS-I) (et industrikonsortium) ble dannet. WS-I har etablert et sett med profiler, der en profil er et sett med navngitte spesifikasjoner for webtjenester på bestemte revisjonsnivåer, sammen med et sett med implementerings- og interoperabilitetsretningslinjer som anbefaler hvordan spesifikasjonene kan brukes til å utvikle interoperable webtjenester. For eksempel den aller første profilen, WS-I grunnleggende profil 1.0, består av følgende sett med ikke-eiendomsspesifikasjoner for nettjenester:
- SÅPE 1.1
- WSDL 1.1
- Universal Description Discovery and Integration (UDDI) 2.0
- XML 1.0 (andre utgave)
- XML-skjema Del 1: Strukturer
- XML-skjema Del 2: Datatyper
- RFC2246: Transport Layer Security Protocol versjon 1.0
- RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
- RFC2616: HyperText Transfer Protocol 1.1
- RFC2818: HTTP over TLS
- RFC2965: HTTP State Management Mechanism
- Secure Sockets Layer Protocol versjon 3.0
Ytterligere profileksempler inkluderer WS-I Basic Security Profile og Simple SOAP Binding Profile. For mer informasjon om disse og andre profiler, besøk WS-I nettstedet. Java SE støtter WS-I Basic Profile.
- Evnen til å samhandle med en webtjeneste asynkront: Webtjeneste-klienter skal kunne samhandle med en web-tjeneste på en ikke-blokkerende, asynkron måte. Kundestøttes asynkron påkallingsstøtte for webtjenesteoperasjoner er gitt i Java SE.
SOAP-baserte webtjenester utføres i et miljø som inkluderer en tjenesteanmoder (klienten), en tjenesteleverandør og en tjenestemegler. Dette miljøet er vist i figur 4.
Figur 4. En SOAP-basert webtjeneste involverer en tjenesteanmoder, en tjenesteleverandør og en tjenestemegler (f.eks. UDDI)
Tjenesteanmoderen, vanligvis en klientapplikasjon (f.eks. En nettleser), eller kanskje en annen webtjeneste, finner først tjenesteleverandøren på en eller annen måte. Serviceanmoderen kan for eksempel sende et WSDL-dokument til en tjenestemegler, som svarer med et annet WSDL-dokument som identifiserer tjenesteleverandørens beliggenhet. Tjenesteanmoderen kommuniserer deretter med tjenesteleverandøren via SOAP-meldinger.
Tjenesteleverandører må publiseres slik at andre kan finne og bruke dem. I august 2000 ble et åpent bransjeinitiativ kjent som Universell beskrivelse, oppdagelse og integrasjon (UDDI) ble lansert for å la bedrifter publisere tjenestelister, oppdage hverandre og definere hvordan tjenestene eller programvareapplikasjonene samhandler over Internett. Dette plattformuavhengige, XML-baserte registeret ble imidlertid ikke adoptert mye og brukes for øyeblikket ikke. Mange utviklere syntes at UDDI var for komplisert og mangelfull funksjonalitet, og valgte alternativer som å publisere informasjonen på et nettsted. For eksempel gjorde Google en gang sine offentlige nettjenester (f.eks. Google Maps) tilgjengelige på //code.google.com/more/.
SOAP-meldingene som flyter mellom tjenesteforespørere og tjenesteleverandører, blir ofte ikke sett, og blir sendt som forespørsler og svar mellom SOAP-bibliotekene i deres webtjenesteprotokollstabler. Det er imidlertid mulig å få tilgang til disse meldingene direkte, som du vil oppdage senere i denne serien.
Store webtjenester
SOAP-baserte webtjenester er også kjent som store nettjenester fordi de er basert på mange spesifikasjoner, for eksempel WS-I-profilene som er nevnt tidligere.
RESTfulle nettjenester
SOAP-baserte webtjenester kan leveres via protokoller som HTTP, SMTP, FTP og Blocks Extensible Exchange Protocol (BEEP). Å levere SOAP-meldinger via HTTP kan sees på som en spesiell type RESTful Web-tjeneste.
EN RESTful Web Service er en mye brukt webtjenestekategori som er basert på Representativ statsoverføring (REST), en programvarearkitekturstil for distribuert hypermediasystemer (systemer der bilder, tekst og andre ressurser er lokalisert rundt nettverk og er tilgjengelige via hyperkoblinger). Hypermediasystemet av interesse i en webtjenestekontekst er World Wide Web.
REST-historien
Roy Fielding (en hovedforfatter av HTTP-spesifikasjon versjon 1.0 og 1.1, og medstifter av Apache Software Foundation) introduserte og definerte REST i doktorgradsavhandlingen tilbake i 2000. Fielding så for seg REST som den arkitektoniske stilen på nettet, selv om han skrev det opp lenge etter at nettet var en fortsatt bekymring. REST blir ansett som løsningen på det som anses å være den økende kompleksiteten av SOAP-baserte webtjenester.
Den sentrale delen av REST er den URI-identifiserbare ressursen. REST identifiserer ressurser etter deres MIME-typer Multipurpose Internet Mail Extensions (for eksempel tekst / xml). Ressurser har også stater som er fanget av deres representasjoner. Når en klient ber om en ressurs fra en RESTful Web-tjeneste, sender tjenesten en MIME-typet representasjon av ressursen til klienten.
Klienter bruker HTTPs POST-, GET-, PUT- og DELETE-verb for å hente frem ressursrepresentasjoner og for å manipulere ressurser. REST tilordner disse verbene til databasen Opprett, Les, Oppdater og Slett (CRUD) -operasjoner, som følger:
- POST: Opprett ny ressurs basert på forespørselsdata.
- FÅ: Les eksisterende ressurs uten å produsere bivirkninger (ikke modifiser ressursen).
- PUT: Oppdater eksisterende ressurs med forespørselsdata.
- SLETT: Slett eksisterende ressurs.
Hvert verb etterfølges av en URI som identifiserer ressursen. (Denne utrolig enkle tilnærmingen er grunnleggende uforenlig med SOAPs tilnærming til å sende kodede meldinger til en enkelt ressurs.) URI kan referere til en samling, som f.eks. //javajeff.ca/bibliotek, eller til et element i samlingen, for eksempel //javajeff.ca/library/9781484219157 - disse URI-ene er bare illustrasjoner.
For POST- og PUT-forespørsler sendes XML-baserte ressursdata som forespørselens brødtekst. For eksempel kan du tolke POST //javajeff.ca/bibliotek HTTP / 1.1 (hvor HTTP / 1.1 beskriver rekvirentens HTTP-versjon) som en forespørsel om å sette inn POSTXML-data i //javajeff.ca/bibliotek innsamlingsressurs.
For GET- og DELETE-forespørsler sendes dataene vanligvis som spørringsstrenger, der a spørringsstreng er den delen av en URI som begynner med en ? karakter. For eksempel hvor FÅ //javajeff.ca/bibliotek kan returnere en liste over identifikatorer for alle bøker i en bibliotek ressurs, FÅ //javajeff.ca/library?isbn=9781484219157 vil sannsynligvis returnere en representasjon av bokressursen hvis spørringsstreng identifiserer International Standard Book Number (ISBN) 9781484219157.
Lær mer om HTTP-CRUD-kartlegginger
For en fullstendig beskrivelse av kartleggingen mellom HTTP-verb og deres CRUD-kolleger, sjekk ut "RESTful Web Service HTTP-metoder" -tabellen i Wikipedia's Representational State Transfer-oppføring.
REST er også avhengig av HTTPs standard responskoder, for eksempel 404 (forespurt ressurs ikke funnet) og 200 (ressursoperasjon vellykket), sammen med MIME-typer (når ressursrepresentasjoner blir hentet).
RESTful vs store webtjenester
Hvis du lurer på om du skal utvikle en webtjeneste ved hjelp av SOAP eller REST, kan du sjekke ut RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision.
Webtjenestestøtte i Java SE
Før Java SE 6 ble Java-baserte webtjenester utviklet eksklusivt med Java Enterprise Edition (EE) SDK. Selv om Java EE er foretrukket for å utvikle webtjenester fra et produksjonsperspektiv, fordi Java EE-baserte servere gir en veldig høy grad av skalerbarhet, en sikkerhetsinfrastruktur, overvåkingsanlegg og så videre, den gjentatte distribusjonen av en webtjeneste til en Java EE containeren har ofte vært tidkrevende og bremset utviklingen. Java SE 6 forenklet og akselererte utvikling av webtjenester ved å legge til API-er, merknader, verktøy og en lett HTTP-server (for å distribuere webtjenester til en enkel webserver og teste dem i dette miljøet) i kjernen.
APIer
Java SE tilbyr flere APIer som støtter webtjenester. Sammen med forskjellige JAXP APIer (SAX, DOM, StAX, og så videre) som jeg diskuterer i Java XML og JSON, Java SE tilbyr JAX-WS, JAXB og SAAJ APIer:
