Vad är webbtjänster? Architecture, Typer, Exempel

Hur fungerar webbtjänster?

Diagrammet ovan visar en mycket förenklad bild av hur en webbtjänst faktiskt skulle fungera. Klienten skulle anropa en serie webbtjänstanrop via förfrågningar till en server som skulle vara värd för den faktiska webbtjänsten.

Dessa förfrågningar görs genom så kallade fjärranrop. Remote Procedure Calls (RPC) är anrop som görs till metoder som är värd för den relevanta webbtjänsten.

Som ett exempel, Amazon tillhandahåller en webbtjänst som ger priser för produkter som säljs online via amazon.com. Användargränssnittet eller presentationslagret kan vara i .Net eller Java men båda programmeringsspråken skulle ha förmågan att kommunicera med webbtjänsten.

Huvudkomponenten i en webbtjänstdesign är den data som överförs mellan klienten och servern, och det är XML. XML (Extensible Markup Language) är en motsvarighet till HTML och lätt att förstå det mellanspråk som förstås av många programmeringsspråk.

Så när applikationer pratar med varandra pratar de faktiskt i XML. Detta ger en gemensam plattform för applikationer utvecklade i olika programmeringsspråk för att prata med varandra.

Webbtjänster använder något som kallas SOAP (Simple Object Access Protocol) för att skicka XML-data mellan applikationer. Data skickas över normal HTTP. Den data som skickas från webbtjänsten till applikationen kallas SOAP-meddelande. SOAP-meddelandet är inget annat än ett XML-dokument. Eftersom dokumentet är skrivet i XML kan klientapplikationen som anropar webbtjänsten skrivas på vilket programmeringsspråk som helst.

Varför behöver du en webbtjänst?

Moderna affärsapplikationer använder en mängd olika programmeringsplattformar för att utveckla webbaserade applikationer. Vissa applikationer kan utvecklas i Java, andra i .Net, medan några andra i Angular JS, Node.js, etc.

Oftast än inte behöver dessa heterogena applikationer någon form av kommunikation för att hända dem emellan. Eftersom de är byggda med olika utvecklingsspråk blir det verkligen svårt att säkerställa korrekt kommunikation mellan applikationer.

Här kommer webbtjänster in. Webbtjänster tillhandahåller en gemensam plattform som tillåter flera applikationer som bygger på olika programmeringsspråk att ha förmågan att kommunicera med varandra.

Typ av webbtjänst

Det finns huvudsakligen två typer av webbtjänster.

1. SOAP webbtjänster.
2. RESTful webbtjänster.

För att en webbtjänst ska vara fullt fungerande är det vissa komponenter som måste finnas på plats. Dessa komponenter måste finnas oavsett vilket utvecklingsspråk som används för att programmera webbtjänsten.

Låt oss titta på dessa komponenter mer i detalj.

SOAP (Simple Object Access Protocol)

SOAP är känt som ett transportoberoende meddelandeprotokoll. SOAP bygger på att överföra XML-data som SOAP-meddelanden. Varje meddelande har något som är känt som ett XML-dokument. Endast strukturen i XML-dokumentet följer ett specifikt mönster, men inte innehållet. Det bästa med webbtjänster och SOAP är att allt skickas via HTTP, vilket är standardwebbprotokollet.

Här är vad ett SOAP-meddelande består av

• Varje SOAP-dokument måste ha ett rotelement som kallas element. Rotelementet är det första elementet i ett XML-dokument.
• "kuvertet" är i sin tur uppdelat i 2 delar. Den första är rubriken och nästa är kroppen.
• Rubriken innehåller routingdata som i princip är informationen som talar om för XML-dokumentet till vilken klient det måste skickas.
• Brödtexten kommer att innehålla det faktiska meddelandet.

Diagrammet nedan visar ett enkelt exempel på kommunikation via SOAP.

Vi kommer att diskutera SOAP i detalj i detta handledning.

WSDL (Web Services Description Language)

En webbtjänst kan inte användas om den inte kan hittas. Klienten som anropar webbtjänsten bör veta var webbtjänsten faktiskt finns.

För det andra behöver klientapplikationen veta vad webbtjänsten faktiskt gör, så att den kan anropa rätt webbtjänst. Detta görs med hjälp av WSDL, känt som webbtjänstens beskrivningsspråk. WSDL-filen är återigen en XML-baserad fil som i princip talar om för klientapplikationen vad webbtjänsten gör. Genom att använda WSDL-dokumentet skulle klientapplikationen kunna förstå var webbtjänsten finns och hur den kan användas.

Exempel på webbtjänst

Ett webbtjänstexempel på en WSDL-fil ges nedan.

<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 viktiga aspekterna att notera om ovanstående WSDL-deklarationsexempel på webbtjänster är följande:

1. – Meddelandeparametern i WSDL-definitionen används för att definiera de olika dataelementen för varje operation som utförs av webbtjänsten. Så i exemplen på webbtjänster ovan har vi två meddelanden som kan utbytas mellan webbtjänsten och klientapplikationen, det ena är "TutorialRequest" och det andra är "TutorialResponse"-operationen. TutorialRequest innehåller ett element som heter "TutorialID" som är av typen sträng. På liknande sätt innehåller TutorialResponse-operationen ett element som heter "TutorialName" som också är en typsträng.
2. – Det här beskriver faktiskt operationen som kan utföras av webbtjänsten, som i vårt fall heter Tutorial. Denna operation kan ta 2 meddelanden; det ena är ett ingångsmeddelande och det andra är det utgående meddelandet.
3. – Detta element innehåller det protokoll som används. Så i vårt fall definierar vi det för att använda http (http://schemas.xmlsoap.org/soap/http). Vi anger också andra detaljer för operationens kropp, som namnutrymmet och om meddelandet ska kodas.

Vi kommer att diskutera "WDSL" i detalj i detta handledning.

Universell Descriptjon, upptäckt och integration (UDDI)

UDDI är en standard för att beskriva, publicera och upptäcka de webbtjänster som tillhandahålls av en viss tjänsteleverantör. Den tillhandahåller en specifikation som hjälper till att lagra informationen på webbtjänster.

Nu diskuterade vi i föregående ämne om WSDL och hur det innehåller information om vad webbtjänsten faktiskt gör. Men hur kan en klientapplikation hitta en WSDL-fil för att förstå de olika funktionerna som erbjuds av en webbtjänst? Så UDDI är svaret på detta och tillhandahåller ett arkiv där WSDL-filer kan lagras. Så klientapplikationen kommer att ha fullständig åtkomst till UDDI, som fungerar som en databas som innehåller alla WSDL-filer.

Precis som en telefonkatalog har namn, adress och telefonnummer till en viss person, på samma sätt som UDDI-registret kommer att ha relevant information för webbtjänsten. Så att en klientapplikation vet var den kan hittas.

Fördelar med webbtjänster

Vi förstår redan varför webbtjänster kom till i första hand, vilket var att tillhandahålla en plattform som kunde tillåta olika applikationer att prata med varandra.

Men låt oss titta på listan över webbtjänsters fördelar för varför det är viktigt att använda webbtjänster.

1. Exponera affärsfunktioner i nätverket – En webbtjänst är en enhet av hanterad kod som tillhandahåller någon form av funktionalitet till klientapplikationer eller slutanvändare. Denna funktion kan anropas över HTTP-protokollet, vilket innebär att den även kan anropas över internet. Nuförtiden finns alla applikationer på internet vilket gör syftet med webbtjänster mer användbart. Det betyder att webbtjänsten kan finnas var som helst på internet och tillhandahålla den nödvändiga funktionaliteten efter behov.
2. Interoperabilitet mellan applikationer – Webbtjänster tillåter olika applikationer att prata med varandra och dela data och tjänster sinsemellan. Alla typer av applikationer kan prata med varandra. Så istället för att skriva specifik kod som bara kan förstås av specifika applikationer, kan du nu skriva generisk kod som kan förstås av alla applikationer
3. Ett standardiserat protokoll som alla förstår – Webbtjänster använder standardiserat industriprotokoll för kommunikationen. Alla fyra lager (Service Transport, XML Messaging, Service Description och Service Discovery-lager) använder väldefinierade protokoll i webbtjänsters protokollstacken.
4. Minska kostnader för kommunikation – Webbtjänster använder SOAP över HTTP-protokoll, så att du kan använda ditt befintliga lågkostnadsinternet för att implementera webbtjänster.

1. Provider – Leverantören skapar webbtjänsten och gör den tillgänglig för klientapplikationer som vill använda den.
2. Begäran – En begärande är inget annat än klientapplikationen som behöver kontakta en webbtjänst. Klientapplikationen kan vara en .Net, Java, eller någon annan språkbaserad applikation som letar efter någon form av funktionalitet via en webbtjänst.
3. Mäklare – Mäklaren är inget annat än applikationen som ger tillgång till UDDI. UDDI, som diskuterades i det tidigare ämnet, gör det möjligt för klientapplikationen att lokalisera webbtjänsten.

Diagrammet nedan visar hur tjänsteleverantören, tjänstebeställaren och tjänsteregistret interagerar med varandra.

1. Publicera – En leverantör informerar mäklaren (tjänsteregistret) om webbtjänstens existens genom att använda mäklarens publiceringsgränssnitt för att göra tjänsten tillgänglig för kunder
2. hitta – Beställaren konsulterar mäklaren för att hitta en publicerad webbtjänst
3. bind – Med informationen som den erhållit från mäklaren (tjänsteregistret) om webbtjänsten kan begäranden binda, eller åberopa, webbtjänsten.

Webbtjänstens egenskaper

Webbtjänster har följande speciella beteendeegenskaper:

1. De är XML-baserade – Web Services använder XML för att representera data i representations- och datatransportskikten. Att använda XML eliminerar alla slags beroende av nätverk, operativsystem eller plattformar eftersom XML är det vanliga språket som alla förstår.
2. Löst kopplade – Löst kopplat innebär att klienten och webbtjänsten inte är bundna till varandra, vilket innebär att även om webbtjänsten förändras över tid så ska den inte förändra hur klienten anropar webbtjänsten. Att anta en löst kopplad arkitektur tenderar att göra mjukvarusystemen mer hanterbara och möjliggör enklare integration mellan olika system.
3. Synchronös eller asynkron funktionalitet - Synchronicitet avser klientens bindning till utförandet av tjänsten. I synkrona operationer kommer klienten faktiskt att vänta på att webbtjänsten ska slutföra en operation. Ett exempel på detta är förmodligen ett scenario där en databasläs- och skrivoperation utförs. Om data läses från en databas och därefter skrivs till en annan, måste operationerna göras på ett sekventiellt sätt. Asynkrona operationer tillåter en klient att anropa en tjänst och sedan utföra andra funktioner parallellt. Detta är en av de vanligaste och förmodligen mest föredragna teknikerna för att säkerställa att andra tjänster inte stoppas när en viss operation utförs.
4. Möjlighet att stödja Remote Procedure Calls (RPC) – Webbtjänster gör det möjligt för klienter att anropa procedurer, funktioner och metoder på fjärrobjekt med hjälp av ett XML-baserat protokoll. Fjärrprocedurer avslöjar in- och utdataparametrar som en webbtjänst måste stödja.
5. Stöder Document Exchange – En av de viktigaste fördelarna med XML är dess generiska sätt att representera inte bara data utan även komplexa dokument. Dessa dokument kan vara så enkla som att representera en aktuell adress, eller de kan vara lika komplexa som att representera en hel bok.