Hva er webtjenester? Architecture, Typer, Eksempel

Hvordan fungerer webtjenester?

Diagrammet ovenfor viser et veldig forenklet syn på hvordan en webtjeneste faktisk vil fungere. Klienten vil påkalle en serie webtjenesteanrop via forespørsler til en server som vil være vert for den faktiske webtjenesten.

Disse forespørslene gjøres gjennom det som er kjent som eksterne prosedyrekall. Remote Procedure Calls (RPC) er anrop som gjøres til metoder som er vert for den aktuelle webtjenesten.

Som et eksempel, Amazon tilbyr en webtjeneste som gir priser for produkter som selges online via amazon.com. Frontend- eller presentasjonslaget kan være i .Net eller Java men begge programmeringsspråkene vil ha muligheten til å kommunisere med webtjenesten.

Hovedkomponenten i en webtjenestedesign er dataene som overføres mellom klienten og serveren, og det er XML. XML (Extensible Markup Language) er et motstykke til HTML og lett å forstå mellomspråket som forstås av mange programmeringsspråk.

Så når applikasjoner snakker med hverandre, snakker de faktisk i XML. Dette gir en felles plattform for applikasjoner utviklet på ulike programmeringsspråk for å snakke med hverandre.

Webtjenester bruker noe kjent som SOAP (Simple Object Access Protocol) for å sende XML-data mellom applikasjoner. Dataene sendes over vanlig HTTP. Dataene som sendes fra nettjenesten til applikasjonen kalles en SOAP-melding. SOAP-meldingen er ikke annet enn et XML-dokument. Siden dokumentet er skrevet i XML, kan klientapplikasjonen som kaller nettjenesten skrives i et hvilket som helst programmeringsspråk.

Hvorfor trenger du en webtjeneste?

Moderne forretningsapplikasjoner bruker en rekke programmeringsplattformer for å utvikle nettbaserte applikasjoner. Noen applikasjoner kan utvikles i Java, andre i .Net, mens noen andre i Angular JS, Node.js, etc.

Oftest enn ikke trenger disse heterogene applikasjonene en slags kommunikasjon for å skje mellom dem. Siden de er bygget med forskjellige utviklingsspråk, blir det virkelig vanskelig å sikre nøyaktig kommunikasjon mellom applikasjoner.

Det er her webtjenester kommer inn. Webtjenester gir en felles plattform som tillater flere applikasjoner bygget på forskjellige programmerings språk å ha evnen til å kommunisere med hverandre.

Type webtjeneste

Det er hovedsakelig to typer webtjenester.

1. SOAP webtjenester.
2. RESTful webtjenester.

For at en webtjeneste skal være fullt funksjonell, er det visse komponenter som må på plass. Disse komponentene må være tilstede uavhengig av hvilket utviklingsspråk som brukes for å programmere webtjenesten.

La oss se på disse komponentene mer detaljert.

SOAP (Simple Object Access Protocol)

SOAP er kjent som en transportuavhengig meldingsprotokoll. SOAP er basert på overføring av XML-data som SOAP-meldinger. Hver melding har noe som er kjent som et XML-dokument. Bare strukturen til XML-dokumentet følger et spesifikt mønster, men ikke innholdet. Den beste delen av webtjenester og SOAP er at alt sendes via HTTP, som er standard nettprotokoll.

Her er hva en SOAP-melding består av

• Hvert SOAP-dokument må ha et rotelement kjent som element. Rotelementet er det første elementet i et XML-dokument.
• "Konvolutten" er igjen delt i 2 deler. Den første er overskriften, og den neste er kroppen.
• Overskriften inneholder rutingdata som i utgangspunktet er informasjonen som forteller XML-dokumentet til hvilken klient det må sendes til.
• Brødteksten vil inneholde selve meldingen.

Diagrammet nedenfor viser et enkelt eksempel på kommunikasjon via SOAP.

Vi vil diskutere SOAP i detalj i dette tutorial.

WSDL (Web Services Description Language)

En nettjeneste kan ikke brukes hvis den ikke blir funnet. Klienten som påkaller webtjenesten bør vite hvor webtjenesten faktisk befinner seg.

For det andre må klientapplikasjonen vite hva webtjenesten faktisk gjør, slik at den kan påkalle den riktige webtjenesten. Dette gjøres ved hjelp av WSDL, kjent som Web Services Description Language. WSDL-filen er igjen en XML-basert fil som i utgangspunktet forteller klientapplikasjonen hva webtjenesten gjør. Ved å bruke WSDL-dokumentet vil klientapplikasjonen kunne forstå hvor webtjenesten befinner seg og hvordan den kan brukes.

Eksempel på netttjeneste

Et netttjenesteeksempel på en WSDL-fil er gitt nedenfor.

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

De viktige aspektene å merke seg om de ovennevnte WSDL-erklæringseksemplene på webtjenester er som følger:

1. – Meldingsparameteren i WSDL-definisjonen brukes til å definere de forskjellige dataelementene for hver operasjon utført av webtjenesten. Så i netttjenesteeksemplene ovenfor har vi 2 meldinger som kan utveksles mellom nettjenesten og klientapplikasjonen, den ene er "TutorialRequest", og den andre er "TutorialResponse" -operasjonen. TutorialRequest inneholder et element kalt "TutorialID" som er av typen streng. På samme måte inneholder TutorialResponse-operasjonen et element kalt "TutorialName" som også er en typestreng.
2. – Dette beskriver faktisk operasjonen som kan utføres av nettjenesten, som i vårt tilfelle kalles Tutorial. Denne operasjonen kan ta 2 meldinger; den ene er en inngangsmelding, og den andre er utgangsmeldingen.
3. – Dette elementet inneholder protokollen som brukes. Så i vårt tilfelle definerer vi det til å bruke http (http://schemas.xmlsoap.org/soap/http). Vi spesifiserer også andre detaljer for hoveddelen av operasjonen, som navneområdet og om meldingen skal kodes.

Vi vil diskutere "WDSL" i detalj i dette tutorial.

Universell Description, oppdagelse og integrasjon (UDDI)

UDDI er en standard for å beskrive, publisere og oppdage nettjenestene som tilbys av en bestemt tjenesteleverandør. Den gir en spesifikasjon som hjelper til med å være vert for informasjonen på webtjenester.

Nå diskuterte vi i forrige emne om WSDL og hvordan den inneholder informasjon om hva webtjenesten faktisk gjør. Men hvordan kan en klientapplikasjon finne en WSDL-fil for å forstå de ulike operasjonene som tilbys av en webtjeneste? Så UDDI er svaret på dette og gir et depot som WSDL-filer kan være vert for. Så klientapplikasjonen vil ha full tilgang til UDDI, som fungerer som en database som inneholder alle WSDL-filene.

Akkurat som en telefonkatalog har navn, adresse og telefonnummer til en bestemt person, på samme måte som UDDI-registeret vil ha relevant informasjon for nettjenesten. Slik at en klientapplikasjon vet hvor den kan finnes.

Fordeler med webtjenester

Vi forstår allerede hvorfor webtjenester ble til i utgangspunktet, som skulle gi en plattform som kunne tillate forskjellige applikasjoner å snakke med hverandre.

Men la oss se på listen over netttjenesters fordeler for hvorfor det er viktig å bruke webtjenester.

1. Eksponering av forretningsfunksjonalitet på nettverket – En webtjeneste er en enhet med administrert kode som gir en slags funksjonalitet til klientapplikasjoner eller sluttbrukere. Denne funksjonaliteten kan påkalles over HTTP-protokollen, noe som betyr at den også kan påkalles over internett. I dag er alle applikasjoner på internett, noe som gjør formålet med webtjenester mer nyttig. Det betyr at webtjenesten kan være hvor som helst på internett og gi den nødvendige funksjonaliteten etter behov.
2. Interoperabilitet mellom applikasjoner – Nettjenester lar ulike applikasjoner snakke med hverandre og dele data og tjenester seg imellom. Alle typer applikasjoner kan snakke med hverandre. Så i stedet for å skrive spesifikk kode som bare kan forstås av spesifikke applikasjoner, kan du nå skrive generisk kode som kan forstås av alle applikasjoner
3. En standardisert protokoll som alle forstår – Webtjenester bruker standardisert industriprotokoll for kommunikasjonen. Alle de fire lagene (Service Transport, XML Messaging, Service Description- og Service Discovery-lag) bruker veldefinerte protokoller i netttjenesters protokollstabel.
4. Reduksjon i kommunikasjonskostnader – Webtjenester bruker SOAP over HTTP-protokoll, slik at du kan bruke ditt eksisterende lavkostinternett for å implementere webtjenester.

1. Provider – Leverandøren oppretter webtjenesten og gjør den tilgjengelig for klientapplikasjoner som ønsker å bruke den.
2. Anmoder – En forespørsel er ikke annet enn klientapplikasjonen som må kontakte en webtjeneste. Klientapplikasjonen kan være en .Net, Java, eller en hvilken som helst annen språkbasert applikasjon som ser etter en slags funksjonalitet via en nettjeneste.
3. Megler – Megleren er ikke annet enn applikasjonen som gir tilgang til UDDI. UDDI, som diskutert i det tidligere emnet, gjør det mulig for klientapplikasjonen å finne webtjenesten.

Diagrammet nedenfor viser hvordan tjenesteleverandøren, tjenesteanmoderen og tjenesteregisteret samhandler med hverandre.

1. Publiser – En tilbyder informerer megleren (tjenesteregisteret) om eksistensen av nettjenesten ved å bruke meglerens publiseringsgrensesnitt for å gjøre tjenesten tilgjengelig for kunder
2. Finn – Anmoderen konsulterer megleren for å finne en publisert nettjeneste
3. Binde – Med informasjonen den har fått fra megleren (tjenesteregisteret) om nettjenesten, kan rekvirenten binde, eller påberope seg, nettjenesten.

Egenskaper for webtjeneste

Nettjenester har følgende spesielle atferdsegenskaper:

1. De er XML-baserte – Web Services bruker XML for å representere dataene på representasjon og datatransport lag. Bruk av XML eliminerer enhver form for avhengighet av nettverk, operativsystem eller plattform, siden XML er det vanlige språket som alle forstår.
2. Løst koblet – Løst koblet betyr at klienten og nettjenesten ikke er bundet til hverandre, noe som betyr at selv om nettjenesten endrer seg over tid, skal den ikke endre måten klienten ringer nettjenesten på. Å ta i bruk en løst koblet arkitektur har en tendens til å gjøre programvaresystemer mer håndterbare og tillater enklere integrasjon mellom ulike systemer.
3. Synchronous eller asynkron funksjonalitet - Synchronicity refererer til klientens binding til utførelsen av tjenesten. Ved synkrone operasjoner vil klienten faktisk vente på at webtjenesten skal fullføre en operasjon. Et eksempel på dette er sannsynligvis et scenario der en databaselese- og skriveoperasjon blir utført. Hvis data leses fra en database og deretter skrives til en annen, må operasjonene gjøres på en sekvensiell måte. Asynkrone operasjoner lar en klient påkalle en tjeneste og deretter utføre andre funksjoner parallelt. Dette er en av de vanlige og sannsynligvis mest foretrukne teknikkene for å sikre at andre tjenester ikke stoppes når en bestemt operasjon utføres.
4. Evne til å støtte Remote Procedure Calls (RPCer) – Webtjenester gjør det mulig for klienter å påkalle prosedyrer, funksjoner og metoder på eksterne objekter ved hjelp av en XML-basert protokoll. Eksterne prosedyrer avslører inngangs- og utdataparametere som en webtjeneste må støtte.
5. Støtter dokumentutveksling – En av hovedfordelene med XML er dens generiske måte å representere ikke bare data på, men også komplekse dokumenter. Disse dokumentene kan være så enkle som å representere en gjeldende adresse, eller de kan være like komplekse som å representere en hel bok.