Wat zijn webservices? Architectuur, typen, voorbeeld

Wat is webservice?

webservice is een gestandaardiseerd medium om de communicatie tussen de client- en serverapplicaties op het WWW (World Wide Web) te verspreiden. Een webservice is een softwaremodule die is ontworpen om een ​​bepaald aantal taken uit te voeren.

• Webservices in cloud computing kunnen via het netwerk worden gezocht en ook dienovereenkomstig worden opgeroepen.
• Wanneer de webservice wordt aangeroepen, kan deze de functionaliteit bieden aan de client, die de webservice aanroept.

Hoe werken webdiensten?

Het bovenstaande diagram toont een zeer simplistisch beeld van hoe een webservice daadwerkelijk zou werken. De client zou een reeks webservice-aanroepen oproepen via verzoeken aan een server die de daadwerkelijke webservice zou hosten.

Deze verzoeken worden gedaan via zogenaamde remote procedure calls. Remote procedure calls (RPC) zijn aanroepen naar methoden die worden gehost door de betreffende webservice.

Als voorbeeld Amazon biedt een webservice die prijzen biedt voor producten die online worden verkocht via amazon.com. De front-end of presentatielaag kan in .Net of JavaMaar beide programmeertalen zouden in staat zijn om met de webservice te communiceren.

Het belangrijkste onderdeel van een webserviceontwerp zijn de gegevens die worden overgedragen tussen de client en de server, en dat is XML. XML (Extensible Markup Language) is een tegenhanger van HTML en een gemakkelijk te begrijpen tussentaal die door veel programmeertalen wordt begrepen.

Wanneer applicaties met elkaar communiceren, doen ze dat in feite via XML. Dit biedt een gemeenschappelijk platform voor applicaties die in verschillende programmeertalen zijn ontwikkeld om met elkaar te communiceren.

Webservices gebruiken iets dat bekend staat als SOAP (Simple Object Access Protocol) voor het verzenden van de XML-gegevens tussen applicaties. De gegevens worden via normale HTTP verzonden. De gegevens die vanuit de webservice naar de applicatie worden verzonden, worden een SOAP-bericht genoemd. Het SOAP-bericht is niets anders dan een XML-document. Omdat het document in XML is geschreven, kan de clienttoepassing die de webservice aanroept, in elke programmeertaal worden geschreven.

Waarom heeft u een webservice nodig?

Moderne zakelijke applicaties maken gebruik van diverse programmeerplatformen om webgebaseerde applicaties te ontwikkelen. Sommige applicaties kunnen worden ontwikkeld in JavaSommige gebruiken .Net, andere AngularJS, Node.js, enzovoort.

In de meeste gevallen is er bij deze heterogene applicaties een vorm van communicatie tussen de applicaties nodig. Omdat ze met verschillende programmeertalen zijn ontwikkeld, is het erg lastig om een ​​accurate communicatie tussen de applicaties te garanderen.

Hier komen webservices in beeld. Webservices bieden een gemeenschappelijk platform waarmee meerdere applicaties op verschillende kunnen worden gebouwd programmeertalen het vermogen hebben om met elkaar te communiceren.

Soorten webservices

Er zijn hoofdzakelijk twee soorten webdiensten:

1. SOAP-webservices.
2. REST-webservices.

Om een ​​webservice volledig functioneel te laten zijn, zijn er bepaalde componenten nodig. Deze componenten moeten aanwezig zijn, ongeacht de programmeertaal die gebruikt wordt voor de webservice. Laten we deze componenten eens nader bekijken.

SOAP (Simple Object Access Protocol)

SOAP staat bekend als een transportonafhankelijk berichtenprotocol. SOAP is gebaseerd op het overdragen van XML-gegevens als SOAP-berichten. Elk bericht bevat een zogenaamd XML-document. Alleen de structuur van het XML-document volgt een specifiek patroon, niet de inhoud. Het grote voordeel van webservices en SOAP is dat alles via HTTP wordt verzonden, het standaard webprotocol.

Dit is waaruit een SOAP-bericht bestaat:

• Elk SOAP-document moet een hoofdelement hebben dat bekend staat als de element. Het rootelement is het eerste element in een XML-document.
• De “envelop” is op zijn beurt verdeeld in 2 delen. De eerste is de koptekst en de volgende is de hoofdtekst.
• De header bevat de routeringsgegevens, oftewel de informatie die het XML-document vertelt naar welke client het moet worden verzonden.
• De hoofdtekst bevat het daadwerkelijke bericht.

In onderstaand schema is een eenvoudig voorbeeld weergegeven van de communicatie via SOAP.

Hierin zullen we SOAP uitgebreid bespreken zelfstudie.

WSDL (webservices Description Taal)

Een webservice kan niet worden gebruikt als deze niet kan worden gevonden. De client die de webservice aanroept, moet weten waar de webservice zich daadwerkelijk bevindt.

Ten tweede moet de clienttoepassing weten wat de webservice precies doet, zodat de juiste webservice kan worden aangeroepen. Dit gebeurt met behulp van de WSDL, ook wel bekend als de webservices. Description Language. Het WSDL-bestand is wederom een ​​XML-bestand dat de clientapplicatie in principe vertelt wat de webservice doet. Door het WSDL-document te gebruiken, kan de clientapplicatie begrijpen waar de webservice zich bevindt en hoe deze kan worden gebruikt.

Voorbeeld van webservice

Hieronder vindt u een voorbeeld van een webservice van een WSDL-bestand.

<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 belangrijke aspecten om op te merken over de bovenstaande WSDL-declaratievoorbeelden van webservices zijn als volgt:

1. De parameter 'message' in de WSDL-definitie wordt gebruikt om de verschillende gegevenselementen te definiëren voor elke bewerking die door de webservice wordt uitgevoerd. In het bovenstaande voorbeeld van de webservice hebben we dus twee berichten die kunnen worden uitgewisseld tussen de webservice en de clienttoepassing: een 'TutorialRequest' en een 'TutorialResponse'. De 'TutorialRequest' bevat een element genaamd 'TutorialID' van het type string. Op dezelfde manier bevat de 'TutorialResponse' een element genaamd 'TutorialName', dat ook van het type string is.
2. – Dit beschrijft de bewerking die de webservice kan uitvoeren, in ons geval genaamd 'Tutorial'. Deze bewerking kan twee berichten ontvangen: een invoerbericht en een uitvoerbericht.
3. – Dit element bevat het gebruikte protocol. In ons geval definiëren we HTTP (http://schemas.xmlsoap.org/soap/http). We specificeren ook andere details voor de inhoud van de bewerking, zoals de namespace en of het bericht gecodeerd moet worden.

We zullen "WSDL" in detail bespreken in dit artikel. zelfstudie.

Universeel Description, ontdekking en integratie (UDDI)

UDDI is een standaard voor het beschrijven, publiceren en ontdekken van de webservices die door een bepaalde serviceprovider worden geleverd. Het biedt een specificatie die helpt bij het hosten van de informatie over webservices.

We hebben het in het vorige onderwerp gehad over WSDL en hoe het informatie bevat over wat de webservice eigenlijk doet. Maar hoe kan een clienttoepassing een WSDL-bestand vinden om de verschillende bewerkingen te begrijpen die door een webservice worden aangeboden? UDDI is dus het antwoord hierop en biedt een repository waarop WSDL-bestanden kunnen worden gehost. De clienttoepassing heeft dus volledige toegang tot de UDDI, die fungeert als een database met alle WSDL-bestanden.

Net zoals een telefoonboek de naam, het adres en het telefoonnummer van een persoon bevat, zo bevat het UDDI-register de relevante informatie voor de webdienst.zodat een clientapplicatie weet waar deze te vinden is.

Voordelen van webservices

We begrijpen al waarom webdiensten in eerste instantie zijn ontstaan: om een ​​platform te bieden waarmee verschillende applicaties met elkaar kunnen communiceren. Maar laten we eens kijken naar de voordelen van webdiensten en waarom het belangrijk is om ze te gebruiken.

1. Bedrijfsfunctionaliteit op het netwerk blootleggen Een webservice is een stukje beheerde code dat een bepaalde functionaliteit biedt aan clientapplicaties of eindgebruikers. Deze functionaliteit kan worden aangeroepen via het HTTP-protocol, wat betekent dat deze ook via internet toegankelijk is. Tegenwoordig zijn alle applicaties online, waardoor webservices steeds nuttiger worden. Dit betekent dat een webservice overal op internet beschikbaar kan zijn en de benodigde functionaliteit kan leveren.
2. Interoperabiliteit tussen applicaties – Webdiensten stellen verschillende applicaties in staat om met elkaar te communiceren en gegevens en diensten met elkaar te delen. Alle soorten applicaties kunnen met elkaar communiceren. In plaats van specifieke code te schrijven die alleen door specifieke applicaties begrepen kan worden, kun je nu generieke code schrijven die door alle applicaties begrepen kan worden.
3. Een gestandaardiseerd protocol dat iedereen begrijpt – Webdiensten gebruiken een gestandaardiseerd industrieprotocol voor de communicatie. Alle vier de lagen (Service Transport, XML Messaging, Service) maken gebruik van dit protocol. DescriptDe lagen voor ion en service discovery maken gebruik van goed gedefinieerde protocollen in de protocolstack voor webservices.
4. Verlaging van de communicatiekosten – Webservices gebruiken het SOAP via HTTP-protocol, zodat u uw bestaande, goedkope internet kunt gebruiken voor het implementeren van webservices.

Web Services Architectuur

Elk framework heeft een bepaalde architectuur nodig om ervoor te zorgen dat het hele framework naar behoren functioneert. Hetzelfde geldt voor webservices. Web Services Architectuur bestaat uit drie verschillende rollen, zoals hieronder weergegeven:

1. leverancier De aanbieder creëert de webservice en stelt deze beschikbaar aan clientapplicaties die er gebruik van willen maken.
2. Aanvrager – Een aanvrager is niets anders dan de clientapplicatie die contact moet maken met een webservice. De clienttoepassing kan een .Net-, Java, of elke andere op een programmeertaal gebaseerde applicatie die via een webservice naar een bepaalde functionaliteit zoekt.
3. Makelaar De broker is niets anders dan de applicatie die toegang biedt tot de UDDI. De UDDI, zoals eerder besproken, stelt de clientapplicatie in staat om de webservice te vinden.

Het onderstaande diagram laat zien hoe de serviceprovider, de serviceaanvrager en het serviceregister met elkaar communiceren.

1. Publiceer – Een aanbieder informeert de broker (serviceregister) over het bestaan ​​van de webdienst door gebruik te maken van de publicatie-interface van de broker, zodat de dienst toegankelijk wordt voor klanten.
2. Find De aanvrager raadpleegt de makelaar om een ​​gepubliceerde webdienst te vinden.
3. binder Met de informatie die de aanvrager van de broker (serviceregister) over de webservice heeft ontvangen, kan hij de webservice binden of aanroepen.

Kenmerken van webservices

Webservices hebben de volgende speciale gedragskenmerken:

1. Ze zijn op XML gebaseerd – Webdiensten gebruiken XML om de gegevens weer te geven op de representatie- en transportlaag. Het gebruik van XML elimineert elke afhankelijkheid van netwerken, besturingssystemen of platforms, aangezien XML de gemeenschappelijke taal is die door iedereen wordt begrepen.
2. Los verbonden – Loosely coupled betekent dat de client en de webservice niet aan elkaar gebonden zijn, wat betekent dat zelfs als de webservice in de loop van de tijd verandert, de manier waarop de client de webservice aanroept, niet zou moeten veranderen. Het aannemen van een loosely coupled architectuur maakt softwaresystemen doorgaans beter beheersbaar en maakt eenvoudigere integratie tussen verschillende systemen mogelijk.
3. Syncchronologische of asynchrone functionaliteit - Synchronicity verwijst naar de binding van de client aan de uitvoering van de service. Bij synchrone bewerkingen wacht de client feitelijk tot de webservice een bewerking voltooit. Een voorbeeld hiervan is waarschijnlijk een scenario waarin een lees- en schrijfbewerking van een database wordt uitgevoerd. Als gegevens van de ene database worden gelezen en vervolgens naar een andere worden geschreven, moeten de bewerkingen op een sequentiële manier worden uitgevoerd. Asynchrone bewerkingen stellen een client in staat een service aan te roepen en vervolgens andere functies parallel uit te voeren. Dit is een van de meest voorkomende en waarschijnlijk de meest geprefereerde technieken om ervoor te zorgen dat andere services niet worden gestopt wanneer een bepaalde bewerking wordt uitgevoerd.
4. Mogelijkheid om Remote Procedure Calls (RPC's) te ondersteunen – Webservices stellen clients in staat procedures, functies en methoden op externe objecten aan te roepen met behulp van een op XML gebaseerd protocol. Externe procedures leggen invoer- en uitvoerparameters bloot die een webservice moet ondersteunen.
5. Ondersteunt documentuitwisseling – Een van de belangrijkste voordelen van XML is de generieke manier om niet alleen data, maar ook complexe documenten weer te geven. Deze documenten kunnen zo simpel zijn als het weergeven van een huidig ​​adres, of zo complex als het weergeven van een heel boek.

Veelgestelde vragen