Programmering

Webtjenester i Java SE, del 1: Oversigt over værktøjer

Java Standard Edition (SE) 6 inkluderede support til webtjenester. Dette indlæg begynder en firedeltsserie om webtjenester i Java SE ved at forklare, hvad webservices er og oversigt over Java SE's support til dem. Fremtidige stillinger vil bruge denne support til at opbygge SOAP-baserede og RESTful-baserede webtjenester og vil også dække avancerede webservicetemaer.

Java XML og JSON

I denne serie antager jeg, at du forstår XML og JSON. Hvis ikke, kan du tjekke min Java XML og JSON bog, der annonceres i slutningen af ​​dette indlæg.

Hvad er webtjenester?

Wikipedia definerer Webtjeneste som "et softwaresystem designet til at understøtte interoperabel maskine-til-maskine-interaktion over et netværk." En mere detaljeret definition kan opnås ved først at definere dette udtryks dele:

  • Web: Et enormt sammenkoblet netværk af ressourcer, hvor en ressource er en URI (Uniform Resource Identifier) ​​datakilde, såsom et PDF-baseret dokument, en videostream, en webside eller endda en applikation. Disse ressourcer kan tilgås ved hjælp af standardinternetprotokoller, såsom HyperText Transfer Protocol (HTTP) eller Simple Mail Transfer Protocol (SMTP).
  • Service: En serverbaseret applikation eller softwarekomponent, der udsætter en ressource for klienter via udveksling af meddelelser i henhold til et meddelelsesudvekslingsmønster (MEP). MEP'en med anmodning-svar er typisk.

I betragtning af disse definitioner er a Webtjeneste er en serverbaseret applikations- / softwarekomponent, der udsætter en webbaseret ressource for klienter via udveksling af meddelelser. Disse meddelelser kan formateres i henhold til Extensible Markup Language (XML) eller JavaScript Object Notation (JSON). Disse meddelelser kan også betragtes som påkaldende webservicefunktioner og modtagelse af påkaldsresultater. Figur 1 illustrerer denne meddelelsesudveksling.

Figur 1. En klient får adgang til en ressource ved at udveksle meddelelser med en webservice

Virksomheder og webtjenester

Virksomheder bruger webservices, fordi de overvinder traditionelle middlewareproblemer (f.eks. Dyre at skaffe og vedligeholde, ude af stand til at kommunikere med backend-software og klientapplikationer på tværs af Internettet og ufleksible) ved at være baseret på gratis og åbne standarder ved deres vedligeholdelsesevne ved at involvere dem Internettet og ved at være fleksibel. Desuden hjælper de større virksomheder med at bevare deres ofte betydelige investeringer i ældre software.

Webtjenester kan klassificeres som enkle eller komplekse. Enkle webtjenester interagerer ikke med andre webtjenester (f.eks. En enkeltstående serverbaseret applikation med en enkelt funktion, der returnerer det aktuelle tidspunkt for en bestemt tidszone). I modsætning hertil interagerer komplekse webtjenester ofte med andre webtjenester. For eksempel kan en generaliseret social netværkstjeneste interagere med Twitter- og Facebook-webtjenester for at få og returnere sin klient al Twitter og alle Facebook-oplysninger til en bestemt person. Komplekse webtjenester er også kendt som mashups fordi de Mose (kombiner) data fra flere webtjenester.

Serviceorienteret arkitektur

Webtjenester er en implementering af Serviceorienteret arkitektur (SOA), som er en stil med softwaredesign, hvor tjenester leveres til forskellige softwarekomponenter gennem en kommunikationsprotokol over et netværk. Tænk på SOA som et sæt designprincipper eller en ramme til implementering af forretningslogik som genanvendelige tjenester, der kan kombineres på forskellige måder for at imødekomme skiftende forretningskrav.

SOAP-baserede webtjenester

EN SOAP-baseret webservice er en meget brugt webservicekategori, der er baseret på SÆBE, et XML-sprog til definition Beskeder (abstrakte funktionsopkald eller deres svar), der kan forstås i begge ender af en netværksforbindelse. En udveksling af SOAP-meddelelser kaldes en operation, der svarer til et funktionsopkald og dets svar, og som er afbildet i figur 2.

Figur 2. En webservicefunktion involverer input- og outputmeddelelser

Relaterede operationer er ofte grupperet i en interface, som konceptuelt ligner en Java-grænseflade. EN bindende giver konkrete detaljer om, hvordan en grænseflade er bundet til en beskedprotokol (især SOAP) til at kommunikere kommandoer, fejlkoder og andre genstande over ledningen. Bindingen og a netværksadresse (en IP-adresse og en port) URI er kendt som en slutpunkt, og en samling af slutpunkter er en Webtjeneste. Figur 3 viser denne arkitektur.

Figur 3. Operationsgrænseflader er tilgængelige via deres slutpunkter

SOAP bruges ofte med Web Services Description Language (WSDL, udtales whiz-kedelig), et XML-sprog til at definere en webservices operationer. EN WSDL-dokument er en formel kontrakt mellem en SOAP-baseret webtjeneste og dens klienter, der indeholder alle detaljer til interaktion med webtjenesten. Dette dokument giver dig mulighed for at gruppere meddelelser i operationer og operationer i grænseflader. Det lader dig også definere en binding til hver grænseflade såvel som slutpunktsadressen.

Ud over at understøtte WSDL-dokumenter har SOAP-baserede webservices følgende egenskaber:

  • Evnen til at løse komplekse ikke-funktionelle krav såsom sikkerhed og transaktioner: Disse krav stilles til rådighed via forskellige specifikationer. For at fremme interoperabilitet mellem disse specifikationer, er Web Services Interoperability Organization (WS-I) (et industrikonsortium) blev dannet. WS-I har oprettet et sæt profiler, hvor a profil er et sæt navngivne webservicespecifikationer på specifikke revisionsniveauer sammen med et sæt implementerings- og interoperabilitetsretningslinjer, der anbefaler, hvordan specifikationerne kan bruges til at udvikle interoperable webtjenester. For eksempel den allerførste profil, WS-I grundlæggende profil 1.0, består af følgende sæt ikke-ejendomsspecifikationer for webservices:
  • SÆBE 1.1
  • WSDL 1.1
  • Universal Description Discovery and Integration (UDDI) 2.0
  • XML 1.0 (anden udgave)
  • XML-skema del 1: strukturer
  • XML-skema del 2: Datatyper
  • RFC2246: Transport Layer Security Protocol version 1.0
  • RFC2459: Internet X.509-certifikat for offentlig nøgleinfrastruktur og CRL-profil
  • RFC2616: HyperText Transfer Protocol 1.1
  • RFC2818: HTTP over TLS
  • RFC2965: HTTP-tilstandsstyringsmekanisme
  • Secure Sockets Layer Protocol version 3.0

Yderligere profileksempler inkluderer WS-I Basic Security Profile og Simple SOAP Binding Profile. For mere information om disse og andre profiler, besøg WS-I webstedet. Java SE understøtter WS-I Basic Profile.

  • Evnen til at interagere med en webtjeneste asynkront: Webtjeneste-klienter skal være i stand til at interagere med en webservice på en ikke-blokerende, asynkron måde. Asynkron påkaldssupport på klientsiden til webservicefunktioner leveres i Java SE.

SOAP-baserede webtjenester udføres i et miljø, der inkluderer en serviceanmoder (klienten), en tjenesteudbyder og en servicemægler. Dette miljø er vist i figur 4.

Figur 4. En SOAP-baseret webservice involverer en serviceanmoder, en tjenesteudbyder og en servicemægler (f.eks. UDDI)

Tjenesteanmoderen, typisk en klientapplikation (f.eks. En webbrowser) eller måske en anden webtjeneste, lokaliserer først tjenesteudbyderen på en eller anden måde. For eksempel kan serviceanmoderen sende et WSDL-dokument til en servicemægler, der svarer med et andet WSDL-dokument, der identificerer tjenesteudbyderens placering. Serviceanmoderen kommunikerer derefter med tjenesteudbyderen via SOAP-meddelelser.

Tjenesteudbydere skal offentliggøres, så andre kan finde og bruge dem. I august 2000 blev et åbent industriinitiativ kendt som Universel beskrivelse, opdagelse og integration (UDDI) blev lanceret for at lade virksomheder offentliggøre tjenestelister, opdage hinanden og definere, hvordan tjenesterne eller softwareapplikationerne interagerer over Internettet. Denne platformuafhængige, XML-baserede registreringsdatabase blev imidlertid ikke bredt vedtaget og bruges i øjeblikket ikke. Mange udviklere fandt, at UDDI var alt for kompliceret og manglede funktionalitet og valgte alternativer såsom at offentliggøre oplysningerne på et websted. For eksempel gjorde Google engang sine offentlige webtjenester (f.eks. Google Maps) tilgængelige på //code.google.com/more/.

SOAP-meddelelserne, der flyder mellem serviceanmodere og tjenesteudbydere, ses ofte ikke og sendes som anmodninger og svar mellem SOAP-bibliotekerne i deres webtjenesteprotokolstakke. Det er dog muligt at få adgang til disse meddelelser direkte, som du vil opdage senere i denne serie.

Store webtjenester

SOAP-baserede webtjenester er også kendt som store webtjenester fordi de er baseret på mange specifikationer, såsom de tidligere nævnte WS-I-profiler.

RESTfulde webtjenester

SOAP-baserede webtjenester kan leveres via protokoller som HTTP, SMTP, FTP og Blocks Extensible Exchange Protocol (BEEP). At levere SOAP-meddelelser via HTTP kan ses som en særlig form for RESTful Web-tjeneste.

EN RESTful Web Service er en meget anvendt webservicekategori, der er baseret på Repræsentativ statsoverførsel (REST), en softwarearkitekturstil til distribueret hypermediesystemer (systemer, hvor billeder, tekst og andre ressourcer er placeret omkring netværk og er tilgængelige via hyperlinks). Hypermediasystemet af interesse i en webservicesammenhæng er World Wide Web.

REST historie

Roy Fielding (en hovedforfatter af HTTP-specifikationen version 1.0 og 1.1 og medstifter af Apache Software Foundation) introducerede og definerede REST i sin doktorafhandling tilbage i 2000. Fielding forestillede sig REST som den arkitektoniske stil på Internettet, skønt han skrev det længe efter, at Internettet var en igangværende bekymring. REST betragtes bredt som løsningen på, hvad der anses for at være den voksende kompleksitet af SOAP-baserede webtjenester.

Den centrale del af REST er den URI-identificerbare ressource. REST identificerer ressourcer efter deres MIME-typer (Multipurpose Internet Mail Extensions) (såsom tekst / xml). Ressourcer har også stater, der er fanget af deres repræsentationer. Når en klient anmoder om en ressource fra en RESTful Web-tjeneste, sender tjenesten en MIME-typet repræsentation af ressourcen til klienten.

Klienter bruger HTTPs POST-, GET-, PUT- og DELETE-verber til at hente ressourcerepræsentationer og til at manipulere ressourcer. REST kortlægger disse verb på databasen Opret, læs, opdater og slet (CRUD) -handlinger som følger:

  • POST: Opret ny ressource baseret på anmodningsdata.
  • FÅ: Læs eksisterende ressource uden at producere bivirkninger (modificer ikke ressourcen).
  • PUT: Opdater eksisterende ressource med anmodningsdata.
  • SLET: Slet eksisterende ressource.

Hvert verb efterfølges af en URI, der identificerer ressourcen. (Denne uhyre enkle tilgang er grundlæggende uforenelig med SOAPs tilgang til at sende kodede meddelelser til en enkelt ressource.) URI henviser muligvis til en samling, såsom //javajeff.ca/bibliotekeller til et element i samlingen, såsom //javajeff.ca/library/9781484219157 - disse URI'er er kun illustrationer.

For POST- og PUT-anmodninger sendes XML-baserede ressourcedata som anmodningens brødtekst. For eksempel kan du fortolke POST //javajeff.ca/bibliotek HTTP / 1.1 (hvor HTTP / 1.1 beskriver ansøgerens HTTP-version) som en anmodning om at indsætte STOLPEXML-data i //javajeff.ca/bibliotek indsamlingsressource.

For GET- og DELETE-anmodninger sendes dataene typisk som forespørgselsstrenge, hvor a forespørgselsstreng er den del af en URI, der begynder med en ? Karakter. For eksempel hvor FÅ //javajeff.ca/bibliotek returnerer muligvis en liste med identifikatorer for alle bøger i en bibliotek ressource, FÅ //javajeff.ca/library?isbn=9781484219157 ville sandsynligvis returnere en repræsentation af bogressourcen, hvis forespørgselsstreng identificerer International Standard Book Number (ISBN) 9781484219157.

Lær mere om HTTP-CRUD-kortlægninger

For en komplet beskrivelse af tilknytningerne mellem HTTP-verber og deres CRUD-modstykker, se tabellen "RESTful Web Service HTTP-metoder" i Wikipedia's repræsentative statsoverførselspost.

REST er også afhængig af HTTPs standardresponcodekoder, såsom 404 (anmodet ressource ikke fundet) og 200 (ressourcehandling er vellykket) sammen med MIME-typer (når ressourcerepræsentationer hentes).

RESTful vs store webtjenester

Hvis du spekulerer på, om du skal udvikle en webtjeneste ved hjælp af SOAP eller REST, skal du tjekke RESTful Web Services vs. "Big" Web Services: At træffe den rigtige arkitektoniske beslutning.

Webservicesupport i Java SE

Før Java SE 6 blev Java-baserede webtjenester udelukkende udviklet med Java Enterprise Edition (EE) SDK. Selvom Java EE foretrækkes til udvikling af webtjenester fra et produktionsperspektiv, fordi Java EE-baserede servere giver en meget høj grad af skalerbarhed, en sikkerhedsinfrastruktur, overvågningsfaciliteter osv., Gentagen implementering af en webservice til en Java EE container har ofte været tidskrævende og bremset udviklingen. Java SE 6 forenklede og fremskyndede udvikling af webservices ved at tilføje API'er, kommentarer, værktøjer og en let HTTP-server (til at implementere webservices til en simpel webserver og teste dem i dette miljø) i kernen.

API'er

Java SE leverer flere API'er, der understøtter webservices. Sammen med forskellige JAXP API'er (SAX, DOM, StAX osv.), Som jeg diskuterer i Java XML og JSON, Java SE leverer JAX-WS, JAXB og SAAJ API'erne:

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