Wat zijn webservices? Architectuur, typen, voorbeeld

Hoe webservices werken?

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 externe procedureaanroepen. Remote Procedure Calls (RPC) zijn oproepen naar methoden die worden gehost door de relevante 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 Java maar beide programmeertalen zouden met de webservice kunnen communiceren.

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

Dus als applicaties met elkaar praten, praten ze feitelijk in XML. Dit biedt een gemeenschappelijk platform voor applicaties die in verschillende programmeertalen zijn ontwikkeld om met elkaar te praten.

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 verschillende programmeerplatforms om webgebaseerde applicaties te ontwikkelen. Sommige toepassingen kunnen worden ontwikkeld in Java, andere in .Net, terwijl andere in Angular JS, Node.js, enz.

Meestal hebben deze heterogene applicaties een vorm van communicatie nodig om tussen hen te kunnen plaatsvinden. Omdat ze zijn gebouwd met behulp van verschillende ontwikkeltalen, wordt het erg moeilijk om nauwkeurige communicatie tussen 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.

Type webservice

Er zijn hoofdzakelijk twee soorten webservices.

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

Om een ​​webservice volledig functioneel te laten zijn, moeten er bepaalde componenten aanwezig zijn. Deze componenten moeten aanwezig zijn, ongeacht welke ontwikkeltaal wordt gebruikt voor het programmeren van de webservice.

Laten we deze componenten in meer detail bekijken.

SOAP (Simple Object Access Protocol)

SOAP staat bekend als een transportonafhankelijk berichtenprotocol. SOAP is gebaseerd op het overbrengen van XML-gegevens als SOAP-berichten. Elk bericht heeft iets dat bekend staat als een XML-document. Alleen de structuur van het XML-document volgt een specifiek patroon, maar niet de inhoud. Het beste van webservices en SOAP is dat het allemaal via HTTP wordt verzonden, het standaard webprotocol.

Hier ziet u 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, wat in feite de informatie is die het XML-document vertelt naar welke klant 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 (beschrijvingstaal voor webservices)

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 clientapplicatie weten wat de webservice daadwerkelijk doet, zodat deze de juiste webservice kan aanroepen. Dit gebeurt met behulp van de WSDL, bekend als de beschrijvingstaal voor webservices. Het WSDL-bestand is opnieuw een op XML gebaseerd bestand dat de clientapplicatie feitelijk 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 berichtparameter in de WSDL-definitie wordt gebruikt om de verschillende data-elementen te definiëren voor elke bewerking die door de webservice wordt uitgevoerd. Dus in de bovenstaande voorbeelden van webservices hebben we 2 berichten die kunnen worden uitgewisseld tussen de webservice en de clienttoepassing, één is de "TutorialRequest" en de andere is de "TutorialResponse"-bewerking. De TutorialRequest bevat een element genaamd "TutorialID" dat van het type string is. Op dezelfde manier bevat de TutorialResponse-bewerking een element genaamd "TutorialName" dat ook van het type string is.
2. – Dit beschrijft eigenlijk de bewerking die kan worden uitgevoerd door de webservice, die in ons geval Tutorial wordt genoemd. Deze bewerking kan 2 berichten bevatten; één is een invoerbericht en de andere is het uitvoerbericht.
3. – Dit element bevat het protocol dat wordt gebruikt. Dus in ons geval definiëren we het om http (http://schemas.xmlsoap.org/soap/http). We specificeren ook andere details voor de hoofdtekst van de bewerking, zoals de naamruimte en of het bericht moet worden gecodeerd.

We zullen “WDSL” hierin uitgebreid bespreken 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 telefoongids de naam, het adres en het telefoonnummer van een bepaalde persoon bevat, op dezelfde manier zal het UDDI-register de relevante informatie voor de webservice hebben. Zodat een clientapplicatie weet waar deze te vinden is.

Voordelen van webservices

We begrijpen al waarom webservices überhaupt ontstonden, namelijk om een ​​platform te bieden waarmee verschillende applicaties met elkaar konden praten.

Maar laten we eens kijken naar de lijst met voordelen van webservices en waarom het belangrijk is om webservices te gebruiken.

1. Bedrijfsfunctionaliteit op het netwerk blootleggen – Een webservice is een beheerde code-eenheid die een bepaalde functionaliteit biedt aan clienttoepassingen of eindgebruikers. Deze functionaliteit kan worden aangeroepen via het HTTP-protocol, wat betekent dat deze ook via internet kan worden aangeroepen. Tegenwoordig bevinden alle applicaties zich op internet, wat het doel van webservices nuttiger maakt. Dat betekent dat de webservice overal op internet kan staan ​​en naar behoefte de benodigde functionaliteit kan bieden.
2. Interoperabiliteit tussen applicaties – Via webservices kunnen verschillende applicaties met elkaar praten en gegevens en diensten onderling delen. Alle soorten applicaties kunnen met elkaar praten. Dus in plaats van specifieke code te schrijven die alleen door specifieke applicaties kan worden begrepen, kunt u nu generieke code schrijven die door alle applicaties kan worden begrepen.
3. Een gestandaardiseerd protocol dat iedereen begrijpt – Webservices gebruiken voor de communicatie een gestandaardiseerd industrieprotocol. Alle vier de lagen (Service Transport, XML Messaging, Service Description- en Service Discovery-lagen) maakt gebruik van goed gedefinieerde protocollen in de protocolstapel van 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.

1. leverancier – De provider maakt de webservice en stelt deze beschikbaar aan de clientapplicatie die deze wil gebruiken.
2. Aanvrager – Een aanvrager is niets anders dan de clientapplicatie die contact moet maken met een webservice. De clienttoepassing kan een .Net-, Java, of een andere taalgebaseerde applicatie die via een webservice naar een bepaalde functionaliteit zoekt.
3. Makelaar – De makelaar is niets anders dan de applicatie die toegang biedt tot de UDDI. Met de UDDI, zoals besproken in het eerdere onderwerp, kan de clienttoepassing de webservice lokaliseren.

Het onderstaande diagram laat zien hoe de Dienstverlener, de Dienstaanvrager en het Dienstregister met elkaar omgaan.

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

Kenmerken van de webservice

Webservices hebben de volgende speciale gedragskenmerken:

1. Ze zijn op XML gebaseerd – Web Services gebruikt XML om de data te representeren op de representation en data transportation lagen. Door XML te gebruiken elimineer je elke netwerk-, besturingssysteem- of platformafhankelijkheid, aangezien XML de gemeenschappelijke taal is die iedereen begrijpt.
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.