Handleiding voor SOAP-webservices: Wat is het SOAP-protocol?

Wat is SOAP?

SOAP is een op XML gebaseerd protocol voor toegang tot webdiensten via HTTP. Het heeft een aantal specificaties die in alle toepassingen gebruikt kunnen worden.

SOAP staat voor Simple Object Access Protocol, maar werd later afgekort tot SOAP v1.2. SOAP is een protocol, ofwel een definitie van hoe webdiensten met elkaar communiceren of met clientapplicaties die ze aanroepen.

SOAP is ontwikkeld als tussentaal, zodat applicaties die op verschillende programmeertalen zijn gebouwd gemakkelijk met elkaar kunnen praten en de extreme ontwikkelingsinspanningen kunnen vermijden.

SOAP-introductie

In de huidige wereld zijn er enorm veel applicaties die gebouwd zijn met verschillende programmeertalen. Zo kan er bijvoorbeeld een webapplicatie zijn die ontworpen is in... Java, een andere in .Net, en nog een in PHP.

Gegevensuitwisseling tussen applicaties is cruciaal in de huidige netwerkwereld. Maar gegevensuitwisseling tussen deze heterogene applicaties zou complex zijn. En dat geldt ook voor de complexiteit van de code om deze gegevensuitwisseling te realiseren.

Een van de methoden die wordt gebruikt om deze complexiteit aan te pakken, is het gebruik van XML (Extensible Markup Language) als tussenliggende taal voor het uitwisselen van gegevens tussen applicaties.

Elke programmeertaal kan de XML-opmaaktaal begrijpen. Daarom werd XML gebruikt als het onderliggende medium voor gegevensuitwisseling.

Er bestaan ​​echter geen standaardspecificaties voor het gebruik van XML in alle programmeertalen voor gegevensuitwisseling. Dat is waar SOAP-software van pas komt.

SOAP is ontworpen om te werken met XML over HTTP en heeft een soort specificatie die in alle applicaties gebruikt kan worden. We zullen in de volgende hoofdstukken dieper ingaan op het SOAP-protocol.

Voordelen van SOAP

SOAP is het protocol dat wordt gebruikt voor gegevensuitwisseling tussen applicaties. Hieronder staan ​​enkele redenen waarom SOAP wordt gebruikt.

• Wanneer ontwikkelenping Voor op SOAP gebaseerde webservices heb je een taal nodig waarmee webservices met clientapplicaties kunnen communiceren. SOAP is hiervoor het perfecte medium, speciaal ontwikkeld. Dit protocol wordt ook aanbevolen door het W3C-consortium, de overkoepelende organisatie voor alle webstandaarden.
• SOAP is een lichtgewicht protocol dat wordt gebruikt voor gegevensuitwisseling tussen applicaties. Let op het trefwoord 'lichtOmdat SOAP-programmering gebaseerd is op de XML-taal, die zelf een lichtgewicht data-uitwisselingstaal is, valt SOAP als protocol ook in dezelfde categorie.
• SOAP is ontworpen om platformonafhankelijk en besturingssysteemonafhankelijk te zijn. Het SOAP-protocol kan dus werken met applicaties die gebaseerd zijn op elke programmeertaal, zowel op platformen als op besturingssystemen. Windows en Linux platforms.
• Het werkt met het HTTP-protocol – SOAP werkt met het HTTP-protocol, het standaardprotocol dat door alle webapplicaties wordt gebruikt. Daarom is er geen enkele aanpassing nodig om webdiensten die op het SOAP-protocol zijn gebouwd, op het World Wide Web te laten werken.

SOAP-bouwstenen

De SOAP-specificatie definieert iets dat bekend staat als een “SOAP bericht", dat is wat naar de webservice en de clientapplicatie wordt verzonden.

Het onderstaande diagram van de SOAP-architectuur toont de verschillende bouwstenen van een SOAP-bericht.

Het SOAP-bericht is niets anders dan een louter XML-document dat de onderstaande componenten bevat.

• An Envelop Het element dat het XML-document identificeert als een SOAP-bericht – Dit is het omhullende deel van het SOAP-bericht en wordt gebruikt om alle details in het SOAP-bericht te omvatten. Dit is het hoofdelement in het SOAP-bericht.
• A Voorvoegsel Element dat headerinformatie bevat – Het headerelement kan informatie bevatten zoals authenticatiegegevens die door de aanroepende applicatie kunnen worden gebruikt. Het kan ook de definitie van complexe gegevenstypen bevatten die in het SOAP-bericht kunnen worden gebruikt. Standaard kan een SOAP-bericht parameters bevatten van eenvoudige typen zoals tekenreeksen en getallen, maar ook van complexe objecttypen.

Een eenvoudig SOAP-servicevoorbeeld van een complex gegevenstype wordt hieronder weergegeven. Stel dat we een gestructureerd gegevenstype willen verzenden dat een combinatie bevat van een "Tutorialnaam" en een "Tutorial". DescriptAls we het type "ion" gebruiken, definiëren we het complexe type zoals hieronder weergegeven. Het complexe type wordt gedefinieerd door de elementtag. Alle benodigde elementen van de structuur, samen met hun respectievelijke gegevenstypen, worden vervolgens gedefinieerd in de verzameling van complexe typen.

<xsd:complexType>
   <xsd:sequence>
      <xsd:element name="Tutorial Name" type="string"/>
      <xsd:element name="Tutorial Description" type="string"/>
   </xsd:sequence>
</xsd:complexType>

A Lichaam Element dat informatie over de aanroep en het antwoord bevat – Dit element bevat de daadwerkelijke gegevens die tussen de webservice en de aanroepende applicatie moeten worden verzonden. Hieronder staat een voorbeeld van een SOAP-webservice met een SOAP-body die werkt met het complexe gegevenstype dat in de header is gedefinieerd. Hieronder staat het antwoord met de tekst "Tutorial Name" en "Tutorial". Description die wordt verzonden naar de oproepende toepassing die deze webservice aanroept.

<soap:Body>
   <GetTutorialInfo>
      <TutorialName>Web Services</TutorialName>
      <TutorialDescription>All about web services</TutorialDescription>
   </GetTutorialInfo>
</soap:Body>

SOAP-berichtstructuur

Een ding om op te merken is dat SOAP-berichten normaal gesproken automatisch worden gegenereerd door de webservice wanneer deze wordt aangeroepen.

Wanneer een clienttoepassing een methode in de webservice aanroept, genereert de webservice automatisch een SOAP-bericht met de benodigde details van de gegevens die van de webservice naar de clienttoepassing worden verzonden.

Zoals besproken in het vorige hoofdstuk van deze SOAP-handleiding, bevat een eenvoudig SOAP-bericht de volgende elementen:

• Het Envelop-element
• Het header-element, en
• Het lichaamselement
• Het foutelement (optioneel)

Laten we hieronder een voorbeeld van een eenvoudig SOAP-bericht bekijken en zien wat elk element precies doet.

1. Zoals uit het bovenstaande SOAP-bericht blijkt, is het eerste deel van het SOAP-bericht het envelopelement dat wordt gebruikt om het gehele SOAP-bericht in te kapselen.
2. Het volgende element is de SOAP-body, die de details van het eigenlijke bericht bevat.
3. Ons bericht bevat een webservice met de naam "Guru99WebService”.
4. De "Guru"99Webservice" accepteert een parameter van het type 'int' en heeft de naam TutorialID.

Nu wordt het bovenstaande SOAP-bericht doorgegeven tussen de webservice en de clientapplicatie.

Je kunt zien hoe nuttig bovenstaande informatie is voor de clientapplicatie. Het SOAP-bericht vertelt de clientapplicatie wat de naam van de webservice is, welke parameters deze verwacht en wat het type van elke parameter is die door de webservice wordt geaccepteerd.

SOAP-envelopelement

Het eerste deel van de bouwsteen is de SOAP-envelop.

De SOAP-envelop wordt gebruikt om alle benodigde details van de SOAP-berichten in te kapselen die tussen de webservice en de clienttoepassing worden uitgewisseld.

Het SOAP-envelopelement wordt gebruikt om het begin en einde van een SOAP-bericht aan te geven. Hierdoor weet de clienttoepassing die de webservice aanroept wanneer het SOAP-bericht eindigt.

De volgende punten kunnen worden opgemerkt over het SOAP-envelop-element.

• Elk SOAP-bericht moet een hoofd-Envelope-element bevatten. Het is absoluut verplicht voor een SOAP-bericht om een ​​envelope-element te hebben.
• Elk Envelop-element moet ten minste één zeeplichaamselement hebben.
• Als een Envelope-element een header-element bevat, mag het er niet meer dan één bevatten en moet het verschijnen als het eerste kind van de Envelope, vóór het body-element.
• De envelop verandert wanneer SOAP-versies veranderen.
• Een v1.1-compatibele SOAP-processor genereert een fout bij ontvangst van een bericht met de v1.2-envelopnaamruimte.
• Een v1.2-compatibele SOAP-processor genereert een versiemismatch-fout als deze een bericht ontvangt dat de v1.2-envelopnaamruimte niet bevat.

Hieronder vindt u een SOAP API-voorbeeld van versie 1.2 van het SOAP-envelope-element.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
   <soap:Body>
      <Guru99WebService xmlns="http://tempuri.org/">
         <TutorialID>int</TutorialID>
      </Guru99WebService>
   </soap:Body>
</SOAP-ENV:Envelope>

Het foutbericht

Wanneer een verzoek wordt gedaan aan een SOAP-webservice, kan het antwoord twee vormen aannemen: een succesvol antwoord of een foutantwoord. Bij een succesvol antwoord stuurt de server altijd een SOAP-bericht terug. Bij SOAP-fouten wordt een "HTTP 500"-foutmelding geretourneerd.

Het SOAP-foutbericht bestaat uit de volgende elementen.

1. <faultCode> – Dit is de code die de foutcode aangeeft. De foutcode kan een van de onderstaande waarden zijn:
   1. SOAP-ENV:VersionMismatch – Dit is wanneer een ongeldige naamruimte voor het SOAP Envelope-element wordt aangetroffen.
   2. SOAP-ENV:MustUnderstand – Een direct onderliggend element van het Header-element, met het mustUnderstand-attribuut ingesteld op “1”, werd niet begrepen.
   3. SOAP-ENV:Client – ​​Het bericht is onjuist samengesteld of bevat onjuiste informatie.
   4. SOAP-ENV:Server – Er was een probleem met de server, dus het bericht kon niet doorgaan.
2. – Dit is het sms-bericht met een gedetailleerde beschrijving van de fout.
3. (Optioneel) – Dit is een tekstreeks die aangeeft wie de fout heeft veroorzaakt.
4. (Optioneel) – Dit is het element voor applicatiespecifieke foutmeldingen. De applicatie kan dus een specifiek foutbericht bevatten voor verschillende bedrijfslogische scenario's.

Voorbeeld voor foutmelding

Hieronder staat een voorbeeld van een foutmelding. De fout treedt op wanneer de client probeert een methode genaamd TutorialID in de klasse GetTutorial te gebruiken. De onderstaande foutmelding wordt gegenereerd als de methode niet bestaat in de gedefinieerde klasse.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
      <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
      <faultstring xsi:type="xsd:string">
         Failed to locate method (GetTutorialID) in class (GetTutorial)
      </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Output:

Wanneer je de bovenstaande code uitvoert, krijg je een foutmelding zoals "Failed to locate method (GetTutorialID) in class (GetTutorial)".

SOAP-communicatiemodel

Alle communicatie via SOAP verloopt via het HTTP-protocol. Vóór SOAP waren er veel webservices gebruikte de standaard RPC-stijl (Remote Procedure Call) voor communicatie. Dit was de eenvoudigste vorm van communicatie, maar had veel beperkingen.

Laten we in deze SOAP API-tutorial het onderstaande diagram bekijken om te zien hoe deze communicatie werkt. In dit voorbeeld gaan we ervan uit dat de server een webservice host die twee methoden aanbiedt:

• Werknemer ophalen – Hiermee worden alle werknemersgegevens opgehaald.
• Werknemer instellen – Dit zou de waarde van details zoals de afdeling, het salaris, enzovoort van een medewerker dienovereenkomstig instellen.

Bij normale communicatie in RPC-stijl zou de client gewoon de methoden in zijn verzoek aanroepen en de vereiste parameters naar de server sturen, waarna de server het gewenste antwoord zou sturen.

Het bovenstaande communicatiemodel kent de volgende ernstige beperkingen:

1. Niet taalonafhankelijk De server waarop de methoden draaien, is in een specifieke programmeertaal geschreven, en normaal gesproken worden de aanroepen naar de server ook alleen in diezelfde programmeertaal gedaan.
2. Niet het standaardprotocol – Wanneer er een oproep wordt gedaan naar de procedure op afstand, wordt de oproep niet uitgevoerd via het standaardprotocol. Dit was een probleem omdat vrijwel alle communicatie via internet via het HTTP-protocol moest plaatsvinden.
3. firewalls – Omdat RPC-oproepen niet via het normale protocol verlopen, moeten er afzonderlijke poorten op de server open zijn zodat de client met de server kan communiceren. Normaal gesproken zouden alle firewalls dit soort verkeer blokkeren, en er was doorgaans veel configuratie nodig om ervoor te zorgen dat dit soort communicatie tussen de client en de server zou werken.

Om alle bovengenoemde beperkingen te overkomen, zou SOAP vervolgens het onderstaande communicatiemodel gebruiken.

1. De client formatteerde de informatie over de procedureaanroep en eventuele argumenten in een SOAP-bericht en verstuurde dit naar de server als onderdeel van een HTTP-verzoek. Dit proces van het inkapselen van de gegevens in een SOAP-bericht stond bekend als Marshalleren.
2. De server zou vervolgens het bericht van de client uitpakken, nagaan wat de client had aangevraagd en vervolgens het juiste antwoord als een SOAP-bericht terugsturen naar de client. Dit proces van uitpakkenping Een verzoek dat door de klant wordt verzonden, staat bekend als Demarshalling.

Praktisch zeepvoorbeeld

Nu in dit SoapUI Laten we in deze tutorial een praktisch SOAP-voorbeeld bekijken. Een van de beste manieren om te zien hoe SOAP-berichten worden gegenereerd, is door een webservice in actie te zien.

In dit onderwerp wordt gekeken naar het gebruik van de Microsoft.Net-framework om een ​​ASMX-webservice te bouwen. Dit type webservice ondersteunt zowel SOAP versie 1.1 als versie 1.2.

ASMX-webservices genereren automatisch de Webservicedefinitietaal (WSDL) document. Dit WSDL-document is vereist voor de aanroepende clientapplicatie, zodat de applicatie weet waartoe de webservice in staat is.

In ons voorbeeld gaan we een eenvoudige webservice maken die een tekenreeks terugstuurt naar de applicatie die de webservice aanroept. Deze webservice wordt gehost in een Asp.Net web applicatie. We zullen dan de webservice aanroepen en het resultaat zien dat door de webservice wordt geretourneerd.

Visual Studio laat ons ook zien wat het SOAP-bericht is dat tussen de webservice en de aanroepende applicatie wordt uitgewisseld. De eerste voorwaarde voor het instellen van onze webservice-applicatie kan worden vervuld door de onderstaande stappen te volgen. Zorg ervoor dat Visual Studio 2013 op uw systeem is geïnstalleerd voor dit voorbeeld.

Stap 1) De eerste stap is het maken van een lege ASP.Net-webtoepassing. Klik in Visual Studio 2013 op de menuoptie Bestand->Nieuw project.

Zodra u op de optie Nieuw project klikt, geeft Visual Studio u een ander dialoogvenster om het type project te kiezen en de benodigde details van het project te geven. Dit wordt in de volgende stap uitgelegd.

Stap 2) In deze stap,

1. Zorg ervoor dat u eerst de C# Websjabloon voor ASP.NET-webtoepassingen. Het project moet van dit type zijn om een ​​SOAP-serviceproject te kunnen maken. Door deze optie te kiezen, voert Visual Studio de nodige stappen uit om de vereiste bestanden toe te voegen die nodig zijn voor elke webtoepassing.
2. Geef je project een naam, in ons geval webservice.asmx. Zorg er vervolgens voor dat je een locatie opgeeft waar de projectbestanden worden opgeslagen.

Zodra dit is voltooid, ziet u het aangemaakte projectbestand in de Solution Explorer van Visual Studio 2013.

Stap 3) In deze stap gaan we een webservicebestand aan ons project toevoegen.

1. Klik eerst met de rechtermuisknop op het projectbestand, zoals hieronder weergegeven.

2. Als je met de rechtermuisknop op het projectbestand klikt, kun je de optie 'Toevoegen -> Webservice (ASMX)' kiezen om een ​​webservicebestand toe te voegen. Geef het webservicebestand de naam 'Tutorial Service'.

Stap 4) Voeg de volgende code toe aan uw Tutorial Service asmx-bestand.

Code Uitleg:

1. Deze coderegel geeft een naam voor uw webservicebestand. Dit is een belangrijke stap omdat het de clientapplicatie de mogelijkheid geeft om de webservice aan te roepen via de naam van de webservice.
2. Normaal gesproken wordt een klassenbestand gebruikt om de functionaliteit van een webservice in te kapselen. Het klassenbestand zal dus de definitie hebben van alle webmethoden die enige functionaliteit aan de clienttoepassing zullen bieden.
3. Hier wordt [WebMethod] gezien als een attribuut dat een functie beschrijft. De volgende stap creëert een functie genaamd “Guru99WebService”, maar door deze stap toe te voegen, namelijk het toevoegen van een [WebMethod]-attribuut, wordt ervoor gezorgd dat deze methode door een clienttoepassing kan worden aangeroepen. Zonder dit attribuut kan de methode nooit door een clienttoepassing worden aangeroepen.
4. Hier definiëren we een functie genaamd 'Guru'99WebService' wordt gebruikt om een ​​tekenreeks terug te sturen naar de aanroepende clienttoepassing. Deze functie is een webservice die door elke clienttoepassing kan worden aangeroepen.
5. We gebruiken de return-instructie om de tekenreeks "Dit is een" terug te geven. Guru99 Webservice” naar de clientapplicatie.

Als de code succesvol is uitgevoerd, wordt de volgende uitvoer weergegeven wanneer u uw code in de browser uitvoert.

Output:

• De uitvoer laat duidelijk zien dat de naam van onze webservice "Guru"99 Web Service", wat het resultaat is van het bedenken van een naam voor onze webservice.
• We zien ook dat we de webservice kunnen aanroepen. Als we op de knop 'Aanroepen' klikken, krijgen we onderstaande reactie in de webbrowser.

De bovenstaande uitvoer:

• Het laat duidelijk zien dat door het aanroepen van de webmethode de tekenreeks "Dit is een Guru"Webservice" wordt geretourneerd.
• Met Visual Studio kunt u ook de SOAP-berichtaanvraag en -respons bekijken die worden gegenereerd wanneer de bovenstaande webservice wordt aangeroepen.

Hieronder ziet u het SOAP-verzoek dat wordt gegenereerd wanneer de webservice wordt aangeroepen.

Code Uitleg:

1. Het eerste deel van een SOAP-bericht is het envelop-element, dat in de voorgaande hoofdstukken is besproken. Dit is het omhullende element dat in elk SOAP-bericht aanwezig is.
2. De SOAP Body is het volgende element en bevat de feitelijke details van het SOAP-bericht.
3. Het derde deel is het element dat aangeeft dat we de service willen aanroepen die ' heet'.Guru99WebService'.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <Guru99WebServiceResponse xmlns="http://tempuri.org/">
         <Guru99WebServiceResult>string</Guru99WebServiceResult>
      </Guru99WebServiceResponse>
   </soap:Body>
</soap:Envelope>

Code Uitleg:

1. Het eerste deel van een SOAP-bericht is het envelop-element, dat in de voorgaande hoofdstukken is besproken. Dit is het omhullende element dat in elk SOAP-bericht aanwezig is.
2. De SOAP Body is het volgende element en bevat de feitelijke details van het SOAP-bericht.
3. Het interessante gedeelte dat u nu zult zien, is het 'string'-attribuut. Dit vertelt de clientapplicatie dat de aangeroepen webservice een object van het type string retourneert. Dit is erg handig, omdat de clientapplicatie anders niet zou weten wat de webservice retourneert.

Veelgestelde vragen