Handledning för SOAP-webbtjänster: Vad är SOAP-protokollet?

Vad är SOAP?

SOAP är ett XML-baserat protokoll för åtkomst till webbtjänster via HTTP. Det har vissa specifikationer som kan användas i alla applikationer.

SOAP är känt som Simple Object Access Protocol, men förkortades senare till SOAP v1.2. SOAP är ett protokoll eller, med andra ord, en definition av hur webbtjänster kommunicerar med varandra eller kommunicerar med klientapplikationer som anropar dem.

SOAP utvecklades som ett mellanspråk så att applikationer byggda på olika programmeringsspråk lätt kunde prata med varandra och undvika den extrema utvecklingsansträngningen.

SOAP Introduktion

I dagens värld finns det ett stort antal applikationer som är byggda på olika programmeringsspråk. Till exempel kan det finnas en webbapplikation designad i Java, en annan i .Net och en annan i PHP.

Att utbyta data mellan applikationer är avgörande i dagens nätverksbaserade värld. Men datautbytet mellan dessa heterogena tillämpningar skulle vara komplext. Så kommer att vara komplexiteten i koden för att åstadkomma detta datautbyte.

En av metoderna som används för att bekämpa denna komplexitet är att använda XML (Extensible Markup Language) som mellanspråk för utbyte av data mellan applikationer.

Varje programmeringsspråk kan förstå XML-markeringsspråket. Därför användes XML som det underliggande mediet för datautbyte.

Men det finns inga standardspecifikationer för användningen av XML i alla programmeringsspråk för datautbyte. Det är där SOAP-programvara kommer in i bilden.

SOAP designades för att fungera med XML över HTTP och har någon sorts specifikation som kan användas i alla applikationer. Vi kommer att undersöka ytterligare detaljer om SOAP-protokollet i de efterföljande kapitlen.

Fördelar med SOAP

SOAP är protokollet som används för datautbyte mellan applikationer. Nedan finns några av anledningarna till varför SOAP används.

• När utvecklasping För SOAP-baserade webbtjänster behöver du ett språk som kan användas för att webbtjänster ska kunna kommunicera med klientapplikationer. SOAP är det perfekta mediet som utvecklades för att uppnå detta syfte. Detta protokoll rekommenderas också av W3C-konsortiet, som är det styrande organet för alla webbstandarder.
• SOAP är ett lättviktsprotokoll som används för datautbyte mellan applikationer. Notera nyckelordet 'ljusEftersom SOAP-programmering är baserad på XML-språket, som i sig är ett lättviktsspråk för datautbyte, faller SOAP som protokoll också i samma kategori.
• SOAP är utformat för att vara plattformsoberoende och även operativsystemsoberoende. Så SOAP-protokollet kan fungera med alla programmeringsspråksbaserade applikationer på båda Windows och Linux plattformar.
• Det fungerar med HTTP-protokollet – SOAP fungerar med HTTP-protokollet, vilket är standardprotokollet som används av alla webbapplikationer. Därför krävs ingen form av anpassning för att köra webbtjänsterna som är byggda med SOAP-protokollet för att fungera på World Wide Web.

SOAP byggstenar

SOAP-specifikationen definierar något som kallas "SOAP meddelande", vilket är det som skickas till webbtjänsten och klientapplikationen.

Diagrammet nedan över SOAP-arkitektur visar de olika byggstenarna i ett SOAP-meddelande.

SOAP-meddelandet är inget annat än bara ett XML-dokument som har komponenterna nedan.

• An Brev element som identifierar XML-dokumentet som ett SOAP-meddelande – Detta är den innehållande delen av SOAP-meddelandet och används för att inkapsla alla detaljer i SOAP-meddelandet. Detta är rotelementet i SOAP-meddelandet.
• A Sidhuvud element som innehåller headerinformation – Headerelementet kan innehålla information såsom autentiseringsuppgifter som kan användas av den anropande applikationen. Det kan också innehålla definitionen av komplexa typer som kan användas i SOAP-meddelandet. Som standard kan SOAP-meddelandet innehålla parametrar som kan vara av enkla typer såsom strängar och tal, men kan också vara en komplex objekttyp.

Ett enkelt SOAP-tjänstexempel av en komplex typ visas nedan. Anta att vi ville skicka en strukturerad datatyp som hade en kombination av ett "Handledningsnamn" och ett "Handledningsnamn". Descriptjon”, så skulle vi definiera den komplexa typen som visas nedan. Den komplexa typen definieras av elementtaggen Alla nödvändiga element i strukturen tillsammans med deras respektive datatyper definieras sedan i den komplexa typsamlingen.

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

A Kaross element som innehåller information om samtal och svar – Detta element innehåller de faktiska data som behöver skickas mellan webbtjänsten och den anropande applikationen. Nedan följer ett exempel på en SOAP-webbtjänst där SOAP-kroppen faktiskt fungerar på den komplexa typen som definieras i rubrikavsnittet. Här är svaret för handledningsnamnet och handledningen. Description som skickas till den anropande applikationen som anropar denna webbtjänst.

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

SOAP meddelande struktur

En sak att notera är att SOAP-meddelanden normalt genereras automatiskt av webbtjänsten när den anropas.

Närhelst en klientapplikation anropar en metod i webbtjänsten, kommer webbtjänsten automatiskt att generera ett SOAP-meddelande som kommer att ha de nödvändiga uppgifterna om data som kommer att skickas från webbtjänsten till klientapplikationen.

Som diskuterats i föregående avsnitt i denna SOAP-handledning har ett enkelt SOAP-meddelande följande element:

• Kuvertelementet
• Header-elementet, och
• Kroppselementet
• Felelementet (valfritt)

Låt oss titta på ett exempel nedan på ett enkelt SOAP-meddelande och se vad varje element faktiskt gör.

1. Som framgår av ovanstående SOAP-meddelande är den första delen av SOAP-meddelandet kuvertelementet som används för att kapsla in hela SOAP-meddelandet.
2. Nästa element är SOAP-kroppen som innehåller detaljerna om det faktiska meddelandet.
3. Vårt meddelande innehåller en webbtjänst som heter ”Guru99Webtjänst”.
4. Den "Guru99Webservice” accepterar en parameter av typen 'int' och har namnet TutorialID.

Nu kommer ovanstående SOAP-meddelande att skickas mellan webbtjänsten och klientapplikationen.

Du kan se hur användbar informationen ovan är för klientapplikationen. SOAP-meddelandet anger för klientapplikationen vad webbtjänsten heter, vilka parametrar den förväntar sig och vilken typ av parameter som används av webbtjänsten är.

SOAP Kuvert Element

Den första biten av byggstenen är SOAP Envelope.

SOAP Envelope används för att kapsla in alla nödvändiga detaljer för SOAP-meddelanden, som utbyts mellan webbtjänsten och klientapplikationen.

SOAP-enveloppelementet används för att indikera början och slutet av ett SOAP-meddelande. Detta gör det möjligt för klientapplikationen som anropar webbtjänsten att veta när SOAP-meddelandet slutar.

Följande punkter kan noteras på SOAP-kuvertelementet.

• Varje SOAP-meddelande måste ha ett rot-Envelope-element. Det är absolut obligatoriskt att ett SOAP-meddelande har ett envelope-element.
• Varje kuvertelement måste ha minst ett tvålelement.
• Om ett kuvertelement innehåller ett rubrikelement får det inte innehålla mer än ett, och det måste visas som det första underordnade kuvertet före huvudelementet.
• Kuvertet ändras när SOAP-versionerna ändras.
• En v1.1-kompatibel SOAP-processor genererar ett fel vid mottagande av ett meddelande som innehåller v1.2-enveloppnamnområdet.
• En v1.2-kompatibel SOAP-processor genererar ett versionsfel om den tar emot ett meddelande som inte inkluderar v1.2-enveloppens namnutrymme.

Nedan visas ett SOAP API-exempel på version 1.2 av SOAP-kuvertelementet.

<?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>

Felmeddelandet

När en begäran görs till en SOAP-webbtjänst kan svaret som returneras ha två former: ett lyckat svar eller ett felsvar. När en begäran har genererats kommer svaret från servern alltid att vara ett SOAP-meddelande. Men om SOAP-fel genereras returneras de som "HTTP 500"-fel.

SOAP Fault-meddelandet består av följande element.

1. <faultCode> – Detta är koden som anger felkoden. Felkoden kan vara något av värdena nedan:
   1. SOAP-ENV:VersionMismatch – Det här är när ett ogiltigt namnområde för SOAP Envelope-elementet påträffas.
   2. SOAP-ENV:MustUnderstand – Ett omedelbart underordnat element av Header-elementet, med mustUnderstand-attributet satt till "1", förstods inte.
   3. SOAP-ENV:Client – ​​Meddelandet var felaktigt format eller innehöll felaktig information.
   4. SOAP-ENV:Server – Det var ett problem med servern, så meddelandet kunde inte fortsätta.
2. – Det här är textmeddelandet som ger en detaljerad beskrivning av felet.
3. (Frivillig) – Det här är en textsträng som anger vem som orsakade felet.
4. (Frivillig) – Detta är elementet för applikationsspecifika felmeddelanden. Så applikationen kan ha ett specifikt felmeddelande för olika affärslogiska scenarier.

Exempel på felmeddelande

Ett exempel på ett felmeddelande ges nedan. Felet genereras i ett scenario där klienten försöker använda en metod som heter TutorialID i klassen GetTutorial. Felmeddelandet nedan genereras om metoden inte finns i den definierade klassen.

<?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>

Produktion:

När du kör koden ovan visas felet "Det gick inte att hitta metoden (GetTutorialID) i klassen (GetTutorial)".

SOAP kommunikationsmodell

All kommunikation via SOAP sker via HTTP-protokollet. Före SOAP, en hel del webbservice använde standardformatet RPC (Remote Procedure Call) för kommunikation. Detta var den enklaste typen av kommunikation, men den hade många begränsningar.

I den här SOAP API-handledningen ska vi titta på diagrammet nedan för att se hur kommunikationen fungerar. I det här exemplet antar vi att servern är värd för en webbtjänst som tillhandahåller två metoder:

• Get Employee – Detta skulle hämta alla anställdas uppgifter.
• Ställ anställd – Detta skulle sätta värdet på detaljer som en anställds avdelning, lön etc. i enlighet därmed.

I den normala kommunikationen i RPC-stil skulle klienten bara anropa metoderna i sin begäran och skicka de nödvändiga parametrarna till servern, och servern skulle sedan skicka det önskade svaret.

Ovanstående kommunikationsmodell har följande allvarliga begränsningar:

1. Inte språkoberoende – Servern som är värd för metoderna skulle vara på ett visst programmeringsspråk, och normalt skulle anropen till servern endast vara på det programmeringsspråket.
2. Inte standardprotokollet – När ett anrop görs till fjärrproceduren utförs inte samtalet via standardprotokollet. Detta var ett problem eftersom mestadels all kommunikation över webben måste ske via HTTP-protokollet.
3. brandväggar – Eftersom RPC-anrop inte går via det vanliga protokollet måste separata portar vara öppna på servern för att klienten ska kunna kommunicera med servern. Normalt sett skulle alla brandväggar blockera denna typ av trafik, och det krävdes i allmänhet mycket konfiguration för att säkerställa att den här typen av kommunikation mellan klienten och servern skulle fungera.

För att övervinna alla ovan nämnda begränsningar skulle SOAP sedan använda kommunikationsmodellen nedan.

1. Klienten skulle formatera informationen om proceduranropet och eventuella argument till ett SOAP-meddelande och skicka det till servern som en del av en HTTP-begäran. Denna process att inkapsla data i ett SOAP-meddelande var känd som Range.
2. Servern skulle sedan packa upp meddelandet som skickats av klienten, se vad klienten begärde och sedan skicka tillbaka lämpligt svar till klienten som ett SOAP-meddelande. Utvecklingen av paketeringping en begäran som skickas av klienten kallas Demarshalling.

Praktiskt SOAP-exempel

Nu i detta SoapUI handledning, låt oss se ett praktiskt SOAP-exempel. Förmodligen ett av de bästa sätten att se hur SOAP-meddelanden genereras är att faktiskt se en webbtjänst i aktion.

Det här ämnet kommer att titta på hur du använder Microsoft.Net framework för att bygga en ASMX webbtjänst. Denna typ av webbtjänst stöder både SOAP version 1.1 och version 1.2.

ASMX webbtjänster genererar automatiskt Web Service Definition Language (WSDL) dokumentera. Detta WSDL-dokument krävs av den anropande klientapplikationen så att applikationen vet vad webbtjänsten kan göra.

I vårt exempel ska vi skapa en enkel webbtjänst som kommer att användas för att returnera en sträng till applikationen som anropar webbtjänsten. Denna webbtjänst kommer att finnas i en Asp.Net webbapplikation. Vi kommer då att anropa webbtjänsten och se resultatet som returneras av webbtjänsten.

Visual Studio visar oss också vilket SOAP-meddelande som skickas mellan webbtjänsten och den anropande applikationen. Den första förutsättningen för att konfigurera vår webbtjänstapplikation är genom att följa stegen nedan. Se till att du har Visual Studio 2013 installerat på ditt system för det här exemplet.

Steg 1) Det första steget är att skapa en tom ASP.Net webbapplikation. Från Visual Studio 2013, klicka på menyalternativet Arkiv->Nytt projekt.

När du klickar på alternativet Nytt projekt kommer Visual Studio att ge dig en annan dialogruta för att välja typ av projekt och för att ge nödvändiga detaljer om projektet. Detta förklaras i nästa steg.

Steg 2) I detta steg

1. Se till att först välja C# webbmall för ASP.NET-webbapplikation. Projektet måste vara av den här typen för att skapa ett SOAP-tjänsteprojekt. Genom att välja det här alternativet kommer Visual Studio sedan att utföra de nödvändiga stegen för att lägga till nödvändiga filer som behövs av alla webbaserade applikationer.
2. Ge ditt projekt ett namn, vilket i vårt fall har angetts som webservice.asmx. Se sedan till att ange en plats där projektfilerna ska lagras.

När det är klart ser du projektfilen som skapats i din lösningsutforskare i Visual Studio 2013.

Steg 3) I det här steget ska vi lägga till en webbtjänstfil i vårt projekt.

1. Högerklicka först på projektfilen som visas nedan.

2. När du högerklickar på projektfilen har du möjlighet att välja alternativet "Lägg till->Webbtjänst (ASMX)" för att lägga till en webbtjänstfil. Ange bara namnet på Handledningstjänsten för webbtjänstnamnfilen.

Steg 4) Lägg till följande kod till din Tutorial Service asmx-fil.

Code Förklaring:

1. Denna kodrad ger ett namn för din webbtjänstfil. Detta är ett viktigt steg eftersom det ger vika för klientapplikationen att anropa webbtjänsten via namnet på webbtjänsten.
2. Normalt används en klassfil för att kapsla in funktionaliteten hos en webbtjänst. Så klassfilen kommer att ha definitionen av alla webbmetoder som kommer att ge viss funktionalitet till klientapplikationen.
3. Här är [WebMethod] känt som ett attribut som beskriver en funktion. I det efterföljande steget skapas en funktion som kallas "Guru99WebService”, men med inkluderingen av detta steg att lägga till ett [WebMethod]-attribut säkerställs att den här metoden kan anropas av en klientapplikation. Om detta attribut inte finns på plats kan metoden aldrig anropas av en klientapplikation.
4. Här definierar vi en funktion som heter 'Guru99WebService' som kommer att användas för att returnera en sträng till den anropande klientapplikationen. Denna funktion är en webbtjänst som kan anropas av vilken klientapplikation som helst.
5. Vi använder return-satsen för att returnera strängen "Detta är en Guru99 Webbtjänst” till klientapplikationen.

Om koden exekveras framgångsrikt kommer följande utdata att visas när du kör din kod i webbläsaren.

Produktion:

• Utdata visar tydligt att namnet på vår webbtjänst är "Guru99 Webbtjänst”, vilket är resultatet av att vi gett vår webbtjänst ett namn.
• Vi kan också se att vi kan anropa webbtjänsten. Om vi ​​klickar på knappen Anrop får vi svaret nedan i webbläsaren.

Ovanstående utdata:

• Det visar tydligt att genom att anropa web-metoden, strängen "Detta är en Guru99 Webbtjänst” returneras.
• Visual Studio låter dig också se SOAP-meddelandebegäran och svaret som genereras när ovanstående webbtjänst anropas.

SOAP-förfrågan som genereras när webbtjänsten anropas visas nedan.

Code Förklaring:

1. Den första delen av SOAP-meddelandet är envelope-elementet, vilket diskuterades i föregående kapitel. Detta är det inkapslande elementet som finns i varje SOAP-meddelande.
2. SOAP Body är nästa element och innehåller de faktiska detaljerna för SOAP-meddelandet.
3. Den tredje delen är elementet som anger att vi vill anropa tjänsten som kallas 'Guru99Webtjänst'.

<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 Förklaring:

1. Den första delen av SOAP-meddelandet är envelope-elementet, vilket diskuterades i föregående kapitel. Detta är det inkapslande elementet som finns i varje SOAP-meddelande.
2. SOAP Body är nästa element och innehåller de faktiska detaljerna för SOAP-meddelandet.
3. Den intressanta delen du kommer att se nu är attributet 'string'. Detta talar om för klientapplikationen att webbtjänsten som anropas returnerar ett objekt av typen sträng. Detta är mycket användbart eftersom klientapplikationen annars inte skulle veta vad webbtjänsten returnerar.

Vanliga frågor