SOAP Web Services-zelfstudie: Wat is het SOAP-protocol? VOORBEELD
Elia Hall
Wat is SOAP?
SOAP is een op XML gebaseerd protocol voor toegang tot webservices via HTTP. Het heeft een aantal specificaties die voor alle toepassingen kunnen worden gebruikt.
SOAP staat bekend als het Simple Object Access Protocol, maar werd later afgekort tot SOAP v1.2. SOAP is een protocol of, met andere woorden, een definitie van hoe webservices met elkaar communiceren of met clienttoepassingen 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 wereld van vandaag is er een groot aantal applicaties die op verschillende programmeertalen zijn gebouwd. Er kan bijvoorbeeld een webapplicatie in zijn ontworpen Java, nog een 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.
Maar er zijn geen standaardspecificaties voor het gebruik van XML in alle programmeertalen voor gegevensuitwisseling. Dat is waar SOAP-software in beeld 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 u op SOAP gebaseerde webservices ontwikkelt, moet u over een deel van de taal beschikken die door webservices kan worden gebruikt om met clienttoepassingen te communiceren. SOAP is het perfecte medium dat ontwikkeld is om dit doel te bereiken. Dit protocol wordt ook aanbevolen door het W3C-consortium, het bestuursorgaan voor alle webstandaarden.
- SOAP is een lichtgewicht protocol dat wordt gebruikt voor gegevensuitwisseling tussen applicaties. Let op het trefwoord 'licht.' Omdat SOAP-programmering gebaseerd is op de XML-taal, die zelf een lichtgewicht taal voor gegevensuitwisseling is, valt SOAP als protocol ook in dezelfde categorie.
- SOAP is ontworpen om platformonafhankelijk te zijn en is ook ontworpen om besturingssysteemonafhankelijk te zijn. Dus het SOAP-protocol kan elke programmeertaal gebaseerde applicatie op beide laten werken Windows maximaliseren en Linux platform.
- Het werkt op het HTTP-protocol – SOAP werkt op het HTTP-protocol, het standaardprotocol dat door alle webapplicaties wordt gebruikt. Daarom is er geen enkele vorm van maatwerk nodig om de webservices 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', 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.
- Een Envelope-element dat het XML-document identificeert als een SOAP-bericht – Dit is het bevattende deel van het SOAP-bericht en wordt gebruikt om alle details in het SOAP-bericht in te kapselen. Dit is het root-element in het SOAP-bericht.
- Een headerelement 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 typen bevatten die in het SOAP-bericht kunnen worden gebruikt. Standaard kan het SOAP-bericht parameters bevatten die van eenvoudige typen kunnen zijn, zoals strings en getallen, maar ook een complex objecttype kunnen zijn.
Hieronder ziet u een eenvoudig voorbeeld van een SOAP-service van een complex type.
Stel dat we een gestructureerd gegevenstype willen verzenden met een combinatie van een 'Tutorialnaam' en een 'Tutorialnaam'. Description,” dan zouden we het complexe type definiëren zoals hieronder weergegeven.
Het complexe type wordt gedefinieerd door de elementtag Alle vereiste elementen van de structuur, samen met hun respectieve gegevenstypen, worden vervolgens gedefinieerd in de complexe typeverzameling.
<xsd:complexType> <xsd:sequence> <xsd:element name="Tutorial Name" type="string"/> <xsd:element name="Tutorial Description" type="string"/> </xsd:sequence> </xsd:complexType>
- Een Body-element dat oproep- en responsinformatie bevat – Dit element bevat de feitelijke gegevens die tussen de webservice en de aanroepende toepassing moeten worden verzonden. Hieronder ziet u een SOAP-webservicevoorbeeld van de SOAP-body die daadwerkelijk werkt op het complexe type dat is gedefinieerd in de headersectie. Hier is de respons van de 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 onderwerp van deze SOAP-zelfstudie, heeft een eenvoudig SOAP-bericht de volgende elementen:
- Het Envelop-element
- Het kopelement en
- Het lichaamselement
- Het foutelement (optioneel)
Laten we een voorbeeld hieronder bekijken van een eenvoudig SOAP-bericht en kijken welk element daadwerkelijk doet.
- 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.
- Het volgende element is de SOAP-body, die de details van het eigenlijke bericht bevat.
- Ons bericht bevat een webservice met de naam “Guru99WebService”.
- De “Guru99Webservice” 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.
U kunt zien hoe nuttig de bovenstaande informatie is voor de clienttoepassing. Het SOAP-bericht vertelt de clienttoepassing wat de naam is van de webservice, en ook welke parameters deze verwacht, en ook wat het type is van elke parameter die door de webservice wordt gebruikt.
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 root Envelope-element hebben. Het is absoluut verplicht dat een SOAP-bericht een envelopelement bevat.
- 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 ziet u een SOAP API-voorbeeld van versie 1.2 van het SOAP-envelopelement.
<?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 geretourneerde antwoord twee vormen hebben: een succesvol antwoord of een foutantwoord. Wanneer er een succes wordt gegenereerd, zal het antwoord van de server altijd een SOAP-bericht zijn. Maar als er SOAP-fouten worden gegenereerd, worden deze geretourneerd als 'HTTP 2'-fouten.
Het SOAP-foutbericht bestaat uit de volgende elementen.
- – Dit is de code die de code van de fout aangeeft. De foutcode kan een van onderstaande waarden zijn
- SOAP-ENV:VersionMismatch – Dit is wanneer een ongeldige naamruimte voor het SOAP Envelope-element wordt aangetroffen.
- SOAP-ENV:MustUnderstand – Een direct onderliggend element van het Header-element, met het mustUnderstand-attribuut ingesteld op “1”, werd niet begrepen.
- SOAP-ENV:Client – Het bericht is onjuist samengesteld of bevat onjuiste informatie.
- SOAP-ENV:Server – Er was een probleem met de server, dus het bericht kon niet doorgaan.
- – Dit is het sms-bericht met een gedetailleerde beschrijving van de fout.
- (Optioneel)– Dit is een tekstreeks die aangeeft wie de fout heeft veroorzaakt.
- (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 vindt u een voorbeeld van een foutmelding. De fout wordt gegenereerd als het scenario waarin de client een methode probeert te gebruiken met de naam TutorialID in de klasse GetTutorial.
Het onderstaande foutbericht 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 u de bovenstaande code uitvoert, wordt de fout weergegeven zoals 'Kan de methode (GetTutorialID) niet vinden in de klasse (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 nu in deze SOAP API-tutorial het onderstaande diagram bekijken om te zien hoe deze communicatie werkt. Laten we in dit voorbeeld aannemen dat de server een webservice host die twee methoden biedt:
- Werknemer ophalen – Hiermee worden alle werknemersgegevens opgehaald
- Werknemer instellen – Hiermee wordt de waarde van details zoals personeelsafdeling, salaris, enz. dienovereenkomstig ingesteld.
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 heeft de onderstaande ernstige beperkingen
- Niet taalonafhankelijk – De server die de methoden host, zou in een bepaalde programmeertaal zijn en normaal gesproken zouden de oproepen naar de server alleen in die programmeertaal plaatsvinden.
- 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.
- 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 overwinnen, zou SOAP het onderstaande communicatiemodel gebruiken
- De client formatteert de informatie over de procedureaanroep en eventuele argumenten in een SOAP-bericht en stuurt 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 Marshalling.
- De server pakt vervolgens het bericht uit dat door de client is verzonden, kijkt waar de client om heeft gevraagd en stuurt vervolgens het juiste antwoord terug naar de client als een SOAP-bericht. De praktijk van het uitpakken van een door de klant verzonden verzoek staat bekend als Demarshalling.
Praktisch zeepvoorbeeld
Laten we nu in deze SoapUI-tutorial een praktisch SOAP-voorbeeld bekijken,
Waarschijnlijk een van de beste manieren om te zien hoe SOAP-berichten worden gegenereerd, is door een webservice daadwerkelijk 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 wordt gebruikt om een string terug te sturen 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 welk SOAP-bericht er tussen de webservice en de aanroepende applicatie wordt verzonden.
De eerste vereiste voor het instellen van onze webservicetoepassing is het volgen van de onderstaande stappen.
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,
- Zorg ervoor dat u eerst de C# websjabloon van ASP.NET-webtoepassing. Het project moet van dit type zijn om een SOAP-servicesproject te kunnen maken. Door deze optie te kiezen, voert Visual Studio vervolgens de benodigde stappen uit om vereiste bestanden toe te voegen die vereist zijn door een webgebaseerde toepassing.
- Geef een naam voor uw project, die in ons geval webservice.asmx is. Zorg er vervolgens voor dat u een locatie opgeeft waar de projectbestanden zullen worden opgeslagen.
Zodra u klaar bent, ziet u het projectbestand dat is gemaakt in uw Solution Explorer in Visual Studio 2013.
Stap 3) In deze stap,
We gaan een webservicebestand aan ons project toevoegen
- Klik eerst met de rechtermuisknop op het projectbestand, zoals hieronder weergegeven
- Zodra u met de rechtermuisknop op het projectbestand klikt, kunt u de optie “Toevoegen->Webservice (ASMX) kiezen om een webservicebestand toe te voegen. Geef gewoon de naam Tutorial Service op voor het naambestand van de webservice.
Stap 4) Voeg de volgende code toe aan uw Tutorial Service asmx-bestand.
Code Verklaring:
- 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.
- 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.
- Hier staat [WebMethod] bekend als een attribuut dat een functie beschrijft. De volgende stap creëert een functie met de naam “Guru99WebService”, maar door het toevoegen van een [WebMethod]-attribuut in deze stap, wordt ervoor gezorgd dat deze methode kan worden aangeroepen door een clienttoepassing. Als dit attribuut niet aanwezig is, kan de methode nooit door een clienttoepassing worden aangeroepen.
- Hier definiëren we een functie genaamd 'Guru99WebService' die zal worden gebruikt om een string terug te sturen naar de aanroepende clientapplicatie. Deze functie is een webservice die door elke clienttoepassing kan worden aangeroepen.
- We gebruiken de return-instructie om de string “Dit is een Guru99-webservice” terug te sturen naar de clienttoepassing.
Als de code succesvol is uitgevoerd, wordt de volgende uitvoer weergegeven wanneer u uw code in de browser uitvoert.
Output:
- Uit de uitvoer blijkt duidelijk dat de naam van onze webservice “Guru99 Web Service” is, wat het resultaat is van het geven van een naam aan onze webservice.
- We kunnen ook zien dat we de webservice kunnen aanroepen. Als we op de knop Aanroepen klikken, krijgen we het onderstaande antwoord in de webbrowser.
De bovenstaande uitvoer,
- Het laat duidelijk zien dat door het aanroepen van de webmethode de string “This is a Guru99 Web service” 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 Verklaring:
- Het eerste deel van het SOAP-bericht is het envelopelement, dat in de voorgaande hoofdstukken is besproken. Dit is het omhullende element dat in elk SOAP-bericht aanwezig is.
- De SOAP Body is het volgende element en bevat de feitelijke details van het SOAP-bericht.
- Het derde deel is het element dat specificeert dat we de service willen aanroepen die 'Guru99WebService' heet.
<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 Verklaring:
- Het eerste deel van het SOAP-bericht is het envelopelement, dat in de voorgaande hoofdstukken is besproken. Dit is het omhullende element dat in elk SOAP-bericht aanwezig is.
- De SOAP Body is het volgende element en bevat de feitelijke details van het SOAP-bericht.
- Het interessante deel dat u nu zult zien is het 'string'-attribuut. Dit vertelt de clienttoepassing dat de aangeroepen webservice een object van het type string retourneert. Dit is erg handig omdat de clienttoepassing anders niet zou weten wat de webservice retourneert.
Samenvatting
- SOAP is een protocol dat wordt gebruikt om gegevens uit te wisselen tussen applicaties die op verschillende applicaties zijn gebouwd programmeertalen.
- SOAP is gebaseerd op de XML-specificatie en werkt met het HTTP-protocol. Dit maakt het perfect voor gebruik binnen webapplicaties.
- De SOAP-bouwstenen bestaan uit een SOAP-bericht. Elk SOAP-bericht bestaat uit een envelopelement, een header en een body-element.
- Het envelopelement is het verplichte element in het SOAP-bericht en wordt gebruikt om alle gegevens in het SOAP-bericht in te kapselen.
- Het header-element kan worden gebruikt om informatie te bevatten, zoals authenticatiegegevens of de definitie van complexe gegevenstypen.
- Het body-element is het hoofdelement dat de definitie van de webmethoden bevat, samen met eventuele parameterinformatie, indien nodig.
