SOAP Web Services Tutorial: Vad är SOAP-protokoll? EXEMPEL

Vad är SOAP?

SOAP är ett XML-baserat protokoll för åtkomst till webbtjänster via HTTP. Den har viss specifikation 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 pratar med varandra eller pratar med klientapplikationer som åberopar dem.

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

I denna handledning för SOAP-webbtjänster lär du dig-

SOAP Introduktion
Fördelar med tvål
SOAP Byggstenar
SOAP-meddelandestruktur
SOAP kuvertelement
SOAP-kommunikationsmodell
Praktiskt tvålsexempel

SOAP Introduktion

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

Att utbyta data mellan applikationer är avgörande i dagens nätverksvärld. Men datautbyte mellan dessa heterogena applikationer skulle vara komplicerat. Så kommer koden att vara komplex för att utföra 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 att utbyta data mellan applikationer.

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

Men det finns inga standardspecifikationer för användning av XML över alla programmeringsspråk för datautbyte. Det är där SOAP-programvaran kommer in.

SOAP har utformats för att fungera med XML via HTTP och ha någon typ av 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 tvål

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

När du utvecklar SOAP-baserade webbtjänster måste du ha lite språk som kan användas för webbtjänster för att prata 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. Lägg märke till nyckelordet " ljus ". Eftersom SOAP-programmering baseras på XML-språket, vilket i sig är ett lättviktsspråk för datautbyte, därmed SOAP som ett protokoll som också faller i samma kategori.
SOAP är utformat för att vara plattformsoberoende och är också utformat för att vara operativsystemoberoende. Så SOAP-protokollet kan fungera på alla programmeringsspråkbaserade applikationer på både Windows- och Linux-plattformen.
Det fungerar på HTTP-protokollet -SOAP fungerar på HTTP-protokollet, vilket är standardprotokollet som används av alla webbapplikationer. Därför finns det ingen form av anpassning som krävs för att köra de webbtjänster som bygger på SOAP-protokollet för att fungera på Internet.

SOAP-byggstenar

SOAP-specifikationen definierar något som kallas ett " SOAP-meddelande " som skickas till webbtjänsten och klientapplikationen.

Nedanstående diagram över SOAP-arkitektur visar de olika byggstenarna i ett SOAP-meddelande.

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

Ett kuvertelement 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.
Ett rubrikelement som innehåller rubrikinformation - Rubrikelementet kan innehålla information som autentiseringsuppgifter som kan användas av den anropande applikationen. Den 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 som strängar och siffror, men kan också vara en komplex objekttyp.

Ett enkelt exempel på SOAP-tjänster av en komplex typ visas nedan.

Antag att vi ville skicka en strukturerad datatyp som hade en kombination av ett "Tutorial Name" och en "Tutorial Description", då skulle vi definiera den komplexa typen som visas nedan.

Komplextypen definieras av elementtaggen . Alla nödvändiga element i strukturen tillsammans med deras respektive datatyper definieras sedan i den komplexa typsamlingen.

Ett kroppselement som innehåller samtals- och svarsinformation - Detta element är det som innehåller den faktiska informationen som måste skickas mellan webbtjänsten och den anropande applikationen. Nedan följer ett exempel på SOAP-webbtjänster av SOAP-kroppen som faktiskt fungerar på den komplexa typ som definieras i rubriksektionen. Här är svaret på instruktionsnamnet och instruktionsbeskrivningen som skickas till den samtalsapplikation som kallar denna webbtjänst.

Web ServicesAll about web services

SOAP-meddelandestruktur

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

När en klientapplikation anropar en metod i webbtjänsten genererar webbtjänsten automatiskt ett SOAP-meddelande som kommer att ha nödvändig information om de data som kommer att skickas från webbtjänsten till klientapplikationen.

Som diskuterades i föregående ämne i denna SOAP-handledning har ett enkelt SOAP-meddelande följande element -

Kuvertelementet
Rubrikelementet och
Kroppselementet
Felelementet (valfritt)

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

Som framgår av ovanstående SOAP-meddelande är den första delen av SOAP-meddelandet kuvertelementet som används för att inkapsla hela SOAP-meddelandet.
Nästa element är SOAP-kroppen som innehåller detaljerna i det faktiska meddelandet.
Vårt meddelande innehåller en webbtjänst som har namnet "Guru99WebService".
"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 berättar för klientapplikationen vad som heter webbtjänsten och vilka parametrar den förväntar sig och vilken typ av varje parameter som tas av webbtjänsten.

SOAP kuvertelement

Den första delen av byggstenen är SOAP-kuvertet.

SOAP-kuvertet används för att inkapsla alla nödvändiga detaljer i SOAP-meddelanden som utbyts mellan webbtjänsten och klientapplikationen.

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

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

Varje SOAP-meddelande måste ha ett root-kuvertelement. Det är absolut obligatoriskt för SOAP-meddelanden att ha ett kuvertelement.
Varje kuvertelement måste ha minst ett tvålkroppselement.
Om ett kuvertelement innehåller ett rubrikelement får det inte innehålla mer än ett och det måste visas som kuvertets första barn före kroppselementet.
Kuvertet ändras när SOAP-versioner ändras.
En v1.1-kompatibel SOAP-processor genererar ett fel vid mottagande av ett meddelande som innehåller v1.2-kuvertnamnsområdet.
En v1.2-kompatibel SOAP-processor genererar ett fel i versionen felaktig matchning om den får ett meddelande som inte inkluderar v1.2-kuvertnamnsområdet.

Nedan följer ett SOAP API-exempel på version 1.2 av SOAP-kuvertelementet.

int

Felmeddelandet

När en begäran görs till en SOAP-webbtjänst kan svaret returneras av antingen två former som är ett framgångsrikt svar eller ett felsvar. När en framgång genereras är svaret från servern alltid ett SOAP-meddelande. Men om SOAP-fel genereras returneras de som "HTTP 500" -fel.

SOAP-felmeddelandet består av följande element.

- Det här är koden som anger felkoden. Felkoden kan ha något av nedanstående värden
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 i Header-elementet, med attributet MustUnderstand satt till "1", förstods inte.
3. SOAP-ENV: Klient - Meddelandet var felaktigt utformat eller innehöll felaktig information.
4. SOAP-ENV: Server - Det uppstod ett problem med servern, så meddelandet kunde inte fortsätta.
- Detta är textmeddelandet som ger en detaljerad beskrivning av felet.
(valfritt) - Detta är en textsträng som anger vem som orsakade felet.
(Valfritt) - 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 om scenariot där klienten försöker använda en metod som heter TutorialID i klassen GetTutorial.

Felmeddelandet nedan genereras i händelse av att metoden inte finns i den definierade klassen.

SOAP-ENV:ClientFailed to locate method (GetTutorialID) in class (GetTutorial)

Produktion:

När du kör ovanstående kod kommer det att visa felet som "Det gick inte att hitta metoden (GetTutorialID) i klassen (GetTutorial)"

SOAP-kommunikationsmodell

All kommunikation med SOAP sker via HTTP-protokollet. Före SOAP använde många webbtjänster den vanliga RPC-stilen (Remote Procedure Call) för kommunikation. Detta var den enklaste typen av kommunikation, men den hade många begränsningar.

Nu i denna SOAP API-handledning, låt oss överväga nedanstående diagram för att se hur denna kommunikation fungerar. I det här exemplet antar vi att servern är värd för en webbtjänst som tillhandahöll två metoder som

GetEmployee - Detta skulle få all information om anställda
SetEmployee - Detta skulle ställa in värdet på detaljerna som anställdas avdelning, lön etc. därefter.

I den vanliga RPC-stilkommunikationen skulle klienten bara anropa metoderna i sin begäran och skicka de nödvändiga parametrarna till servern, och servern skulle sedan skicka önskat svar.

Ovanstående kommunikationsmodell har nedanstående allvarliga begränsningar

Inte språkoberoende - Servern som är värd för metoderna skulle vara på ett visst programmeringsspråk och normalt skulle samtalen till servern endast vara på det programmeringsspråket.
Inte standardprotokollet - När ett samtal görs till fjärrproceduren genomförs inte samtalet via standardprotokollet. Detta var ett problem eftersom mest all kommunikation över webben var tvungen att ske via HTTP-protokollet.
Brandväggar - Eftersom RPC-samtal 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 skulle alla brandväggar blockera den här typen av trafik, och mycket konfiguration krävdes vanligtvis för att säkerställa att denna typ av kommunikation mellan klienten och servern skulle fungera.

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

Klienten skulle formatera informationen om proceduranropet och eventuella argument i ett SOAP-meddelande och skickar det till servern som en del av en HTTP-begäran. Denna process att inkapsla in data i ett SOAP-meddelande kallades Marshalling.
Servern skulle sedan packa upp meddelandet som skickats av klienten, se vad klienten begärde för och sedan skicka lämpligt svar tillbaka till klienten som ett SOAP-meddelande. Förfarandet med att packa upp en begäran som skickats av klienten kallas Demarshalling.

Praktiskt tvålsexempel

Nu i denna 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.

Detta ämne kommer att titta på hur man använder Microsoft.Net-ramverket 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 WSDL-dokumentet (Web Service Definition Language). 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 vara värd i en Asp.Net-webbapplikation. Vi anropar sedan webbtjänsten och ser resultatet som returneras av webbtjänsten.

Visual Studio kommer också att visa oss vad SOAP-meddelandet skickas mellan webbtjänsten och den anropande applikationen.

Den första förutsättningen för att konfigurera vår webbtjänstapplikation som kan göras genom att följa nedanstående steg.

Se till att du har Visual Studio 2013 installerat på ditt system för detta exempel.

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

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

Steg 2) I detta steg,

Se till att du först väljer C # -mallen för ASP.NET-webbapplikationen. Projektet måste vara av denna typ för att kunna skapa SOAP-tjänster. Genom att välja detta alternativ kommer Visual Studio sedan att utföra nödvändiga steg för att lägga till nödvändiga filer som krävs av alla webbaserade applikationer.
Ge ett namn på ditt projekt som i vårt fall har fått som webservice.asmx. Se till att ge en plats där projektfilerna kommer att lagras.

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

Steg 3) I detta steg,

Vi ska lägga till en webbtjänstfil i vårt projekt

Högerklicka först på projektfilen enligt nedan

När du högerklickar på projektfilen har du chansen att välja alternativet "Lägg till-> Webbtjänst (ASMX) för att lägga till en webbtjänstfil. Ange bara namnet Tutorial Service för webbtjänstens namnfil.

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

Kodförklaring:

Den här kodraden ger ett namn på din webbtjänstfil. Detta är ett viktigt steg eftersom det ger plats för klientapplikationen att ringa webbtjänsten via namnet på webbtjänsten.
Normalt används en klassfil för att inkapsla funktionaliteten hos en webbtjänst. Så klassfilen har definitionen av alla webbmetoder som ger klientapplikationen viss funktionalitet.
Här är [WebMethod] känd som ett attribut som beskriver en funktion. Det efterföljande steget skapar en funktion som heter "Guru99WebService", men med införandet av detta steg att lägga till ett [WebMethod] -attribut ser till att denna metod kan åberopas av en klientapplikation. Om detta attribut inte är på plats kan metoden aldrig anropas av ett klientprogram.
Här definierar vi en funktion som heter 'Guru99WebService' som kommer att användas för att returnera en sträng till det anropande klientprogrammet. Denna funktion är en webbtjänst som kan anropas av alla klientapplikationer.
Vi använder returuttalandet för att returnera strängen "Detta är en Guru99-webbtjänst" till klientprogrammet.

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

Produktion:

Resultatet visar tydligt att namnet på vår webbtjänst är "Guru99 Web Service" vilket är resultatet av att vi ger ett namn på vår webbtjänst.
Vi kan också se att vi kan för att åberopa webbtjänsten. Om vi klickar på knappen Anropa får vi svaret nedan i webbläsaren.

Ovanstående produktion,

Det visar tydligt att strängen "Detta är en Guru99-webbtjänst" returneras genom att anropa webbmetoden.
Visual Studio låter dig också visa SOAP-meddelandeförfrågan och svar som genereras när ovanstående webbtjänst anropas.

SOAP-begäran som genereras när webbtjänsten anropas visas nedan.

Kodförklaring:

Den första delen av SOAP-meddelandet är kuvertelementet, vilket är vad som diskuterades i föregående kapitel. Detta är det inkapslande elementet som finns i varje SOAP-meddelande.
SOAP Body är nästa element och innehåller de faktiska detaljerna i SOAP-meddelandet.
Den tredje delen är det element som anger att vi vill kalla tjänsten som heter 'Guru99WebService.'

string

Kodförklaring:

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

Sammanfattning

SOAP är ett protokoll som används för att utbyta data mellan applikationer som bygger på olika programmeringsspråk.
SOAP bygger på XML-specifikationen och fungerar med HTTP-protokollet. Detta gör det perfekt för användning inom webbapplikationer.
SOAP-byggstenarna består av ett SOAP-meddelande. Varje SOAP-meddelande består av ett kuvertelement, en rubrik och ett kroppselement.
Kuvertelementet är det obligatoriska elementet i SOAP-meddelandet och används för att inkapsla alla data i SOAP-meddelandet.
Rubrikelementet kan användas för att innehålla information såsom autentiseringsinformation eller definition av komplexa datatyper.
Kroppselementet är huvudelementet som innehåller definitionen av webbmetoderna tillsammans med eventuell parameterinformation.