SOAP Web Services-vejledning: Hvad er SOAP-protokollen?

Hvad er SOAP?

SOAP er en XML-baseret protokol til adgang til webtjenester via HTTP. Den har nogle specifikationer, der kan bruges på tværs af alle applikationer.

SOAP er kendt som Simple Object Access Protocol, men blev senere forkortet til SOAP v1.2. SOAP er en protokol eller, med andre ord, en definition af, hvordan webtjenester kommunikerer med hinanden eller kommunikerer med klientapplikationer, der aktiverer dem.

SOAP blev udviklet som et mellemsprog, så applikationer bygget på forskellige programmeringssprog nemt kunne tale med hinanden og undgå den ekstreme udviklingsindsats.

SÆBE introduktion

I dagens verden findes der et enormt antal applikationer, der er bygget på forskellige programmeringssprog. For eksempel kunne der være en webapplikation designet i Java, en anden i .Net, og en anden i PHP.

Udveksling af data mellem applikationer er afgørende i dagens netværksverden. Men dataudveksling mellem disse heterogene applikationer ville være kompleks. Det vil også være kompleksiteten af ​​koden for at opnå denne dataudveksling.

En af de metoder, der bruges til at bekæmpe denne kompleksitet, er at bruge XML (Extensible Markup Language) som mellemsprog til udveksling af data mellem applikationer.

Ethvert programmeringssprog kan forstå XML markup sproget. Derfor blev XML brugt som det underliggende medium til dataudveksling.

Men der er ingen standardspecifikationer for brugen af ​​XML på tværs af alle programmeringssprog til dataudveksling. Det er her, SOAP-software kommer ind i billedet.

SOAP er designet til at arbejde med XML over HTTP og har en slags specifikation, som kan bruges på tværs af alle applikationer. Vi vil se nærmere på detaljerne om SOAP-protokollen i de efterfølgende kapitler.

Fordele ved SOAP

SOAP er den protokol, der bruges til dataudveksling mellem applikationer. Nedenfor er nogle af grundene til, hvorfor SOAP bruges.

• Når udvikletping SOAP-baserede webtjenester, du skal bruge et sprog, som webtjenester kan bruge til at kommunikere med klientapplikationer. SOAP er det perfekte medie, der blev udviklet til at opnå dette formål. Denne protokol anbefales også af W3C-konsortiet, som er det styrende organ for alle webstandarder.
• SOAP er en letvægtsprotokol, der bruges til dataudveksling mellem applikationer. Bemærk nøgleordet 'lysDa SOAP-programmering er baseret på XML-sproget, som i sig selv er et letvægtssprog til dataudveksling, falder SOAP som protokol også i samme kategori.
• SOAP er designet til at være platformuafhængig og er også designet til at være operativsystemuafhængig. Så SOAP-protokollen kan fungere med alle programmeringssprogsbaserede applikationer på begge Windows og Linux platforme.
• Det fungerer på HTTP-protokollen – SOAP fungerer på HTTP-protokollen, som er standardprotokollen, der bruges af alle webapplikationer. Derfor er der ingen form for tilpasning, der kræves for at køre webtjenesterne, der er bygget på SOAP-protokollen, så de fungerer på World Wide Web.

SÆBE byggeklodser

SOAP-specifikationen definerer noget kendt som en "SOAP besked", som er det, der sendes til webtjenesten og klientapplikationen.

Nedenstående diagram over SOAP-arkitektur viser de forskellige byggesten i en SOAP-meddelelse.

SOAP-meddelelsen er intet andet end blot et XML-dokument, som har nedenstående komponenter.

• An Kuvert element, der identificerer XML-dokumentet som en SOAP-meddelelse – Dette er den indeholdende del af SOAP-meddelelsen og bruges til at indkapsle alle detaljerne i SOAP-meddelelsen. Dette er rodelementet i SOAP-meddelelsen.
• A Header element, der indeholder headeroplysninger – Headerelementet kan indeholde oplysninger såsom godkendelsesoplysninger, som kan bruges af den kaldende applikation. Det kan også indeholde definitionen af ​​komplekse typer, der kan bruges i SOAP-meddelelsen. Som standard kan SOAP-meddelelsen indeholde parametre, der kan være af simple typer såsom strenge og tal, men som også kan være en kompleks objekttype.

Et simpelt SOAP-serviceeksempel af en kompleks type er vist nedenfor. Antag, at vi ønskede at sende en struktureret datatype, der havde en kombination af et "Tutorial Name" og et "Tutorial". Description”, så ville vi definere den komplekse type som vist nedenfor. Den komplekse type er defineret af elementtagget Alle de nødvendige elementer i strukturen sammen med deres respektive datatyper defineres derefter i den komplekse typesamling.

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

A Fylde element, der indeholder oplysninger om opkald og svar – Dette element indeholder de faktiske data, der skal sendes mellem webtjenesten og den kaldende applikation. Nedenfor er et SOAP-webtjenesteeksempel på SOAP-kroppen, der rent faktisk fungerer på den komplekse type, der er defineret i header-sektionen. Her er svaret fra Tutorial Name og Tutorial. Description, der sendes til den opkaldende applikation, som kalder denne webtjeneste.

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

SOAP-meddelelsesstruktur

En ting at bemærke er, at SOAP-beskeder normalt automatisk genereres af webtjenesten, når den kaldes.

Når en klientapplikation kalder en metode i webtjenesten, vil webtjenesten automatisk generere en SOAP-meddelelse, som vil have de nødvendige detaljer om de data, som vil blive sendt fra webtjenesten til klientapplikationen.

Som diskuteret i det forrige emne i denne SOAP-vejledning, har en simpel SOAP-meddelelse følgende elementer:

• Konvolutelementet
• Header-elementet, og
• Kropselementet
• Fejlelementet (valgfrit)

Lad os se på et eksempel nedenfor på en simpel SOAP-besked og se, hvad hvert element rent faktisk gør.

1. Som det ses af ovenstående SOAP-meddelelse, er den første del af SOAP-meddelelsen kuvertelementet, som bruges til at indkapsle hele SOAP-meddelelsen.
2. Det næste element er SOAP-legemet, som indeholder detaljerne i den faktiske besked.
3. Vores besked indeholder en webtjeneste med navnet "Guru99WebService”.
4. Den "Guru99Webservice” accepterer en parameter af typen 'int' og har navnet TutorialID.

Nu vil ovenstående SOAP-meddelelse blive sendt mellem webtjenesten og klientapplikationen.

Du kan se, hvor nyttige ovenstående oplysninger er for klientapplikationen. SOAP-meddelelsen fortæller klientapplikationen, hvad webtjenestens navn er, hvilke parametre den forventer, og hvilken type hver parameter er, som webtjenesten bruger.

Sæbekuvertelement

Den første del af byggestenen er SOAP Envelope.

SOAP-konvolutten bruges til at indkapsle alle de nødvendige detaljer om SOAP-meddelelserne, som udveksles mellem webservicen og klientapplikationen.

SOAP-kuvertelementet bruges til at angive begyndelsen og slutningen af ​​en SOAP-meddelelse. Dette gør det muligt for klientapplikationen, der kalder webtjenesten, at vide, hvornår SOAP-meddelelsen slutter.

Følgende punkter kan noteres på SOAP-kuvertelementet.

• Hver SOAP-meddelelse skal have et rod-Envelope-element. Det er absolut obligatorisk for en SOAP-meddelelse at have et envelope-element.
• Hvert Envelope-element skal have mindst ét ​​sæbeelement.
• Hvis et kuvertelement indeholder et overskriftselement, må det ikke indeholde mere end ét, og det skal vises som det første underordnede af konvolutten før brødelementet.
• Konvolutten ændres, når SOAP-versionerne ændres.
• En v1.1-kompatibel SOAP-processor genererer en fejl ved modtagelse af en meddelelse, der indeholder v1.2-envelope-navneområdet.
• En v1.2-kompatibel SOAP-processor genererer en Version Mismatch-fejl, hvis den modtager en meddelelse, der ikke inkluderer v1.2-envelope-navneområdet.

Nedenfor er et SOAP API-eksempel på version 1.2 af SOAP-envelope-elementet.

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

Fejlmeddelelsen

Når en anmodning sendes til en SOAP-webtjeneste, kan det returnerede svar have to former: et vellykket svar eller et fejlsvar. Når der genereres et vellykket svar, vil svaret fra serveren altid være en SOAP-meddelelse. Men hvis der genereres SOAP-fejl, returneres de som "HTTP 500"-fejl.

SOAP-fejlmeddelelsen består af følgende elementer.

1. <faultCode> – Dette er koden, der angiver fejlkoden. Fejlkoden kan være en af ​​følgende værdier:
   1. SOAP-ENV:VersionMismatch – Dette er, når et ugyldigt navneområde for SOAP Envelope-elementet stødes på.
   2. SOAP-ENV:MustUnderstand – Et umiddelbart underordnet element af Header-elementet, med mustUnderstand-attributten sat til "1", blev ikke forstået.
   3. SOAP-ENV:Client – ​​Meddelelsen var forkert udformet eller indeholdt forkerte oplysninger.
   4. SOAP-ENV:Server – Der var et problem med serveren, så beskeden kunne ikke fortsætte.
2. – Dette er tekstmeddelelsen, der giver en detaljeret beskrivelse af fejlen.
3. (Valgfri) – Dette er en tekststreng, der angiver, hvem der har forårsaget fejlen.
4. (Valgfri) – Dette er elementet for applikationsspecifikke fejlmeddelelser. Så applikationen kunne have en specifik fejlmeddelelse for forskellige forretningslogiske scenarier.

Eksempel på fejlmeddelelse

Et eksempel på en fejlmeddelelse er givet nedenfor. Fejlen genereres i det scenarie, hvor klienten forsøger at bruge en metode kaldet TutorialID i klassen GetTutorial. Nedenstående fejlmeddelelse genereres, hvis metoden ikke findes i den definerede 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:

Når du udfører ovenstående kode, vil den vise fejlen "Kunne ikke finde metoden (GetTutorialID) i klassen (GetTutorial)".

SOAP kommunikationsmodel

Al kommunikation via SOAP foregår via HTTP-protokollen. Forud for SOAP, en masse webservices brugt standard RPC (Remote Procedure Call) stil til kommunikation. Dette var den enkleste form for kommunikation, men den havde mange begrænsninger.

I denne SOAP API-tutorial vil vi se på nedenstående diagram for at se, hvordan denne kommunikation fungerer. I dette eksempel antager vi, at serveren er vært for en webtjeneste, der tilbyder to metoder som:

• Få medarbejder – Dette ville indhente alle medarbejderoplysninger.
• Sæt medarbejder – Dette ville indstille værdien af ​​detaljer som en medarbejders afdeling, løn osv. i overensstemmelse hermed.

I den normale RPC-stil kommunikation ville klienten blot kalde metoderne i sin anmodning og sende de nødvendige parametre til serveren, og serveren ville derefter sende det ønskede svar.

Ovenstående kommunikationsmodel har følgende alvorlige begrænsninger:

1. Ikke sproguafhængig – Serveren, der er vært for metoderne, ville være i et bestemt programmeringssprog, og normalt ville kaldene til serveren kun være i det programmeringssprog.
2. Ikke standardprotokollen – Når der foretages et opkald til fjernproceduren, udføres opkaldet ikke via standardprotokollen. Dette var et problem, da stort set al kommunikation over nettet skulle ske via HTTP-protokollen.
3. Firewalls – Da RPC-opkald ikke går via den normale protokol, skal separate porte være åbne på serveren for at tillade klienten at kommunikere med serveren. Normalt ville alle firewalls blokere denne form for trafik, og en masse konfiguration var generelt påkrævet for at sikre, at denne form for kommunikation mellem klienten og serveren ville fungere.

For at overvinde alle de ovennævnte begrænsninger, ville SOAP derefter bruge nedenstående kommunikationsmodel.

1. Klienten ville formatere informationen vedrørende procedurekaldet og eventuelle argumenter i en SOAP-meddelelse og sende den til serveren som en del af en HTTP-anmodning. Denne proces med at indkapsle dataene i en SOAP-meddelelse var kendt som Marshalling.
2. Serveren ville derefter udpakke den besked, som klienten sendte, se, hvad klienten anmodede om, og derefter sende det relevante svar tilbage til klienten som en SOAP-besked. Praksis med udpakningping en anmodning sendt af klienten kaldes Demarshalling.

Eksempel på praktisk SOAP

Nu i dette SoapUI I denne vejledning kan vi se et praktisk SOAP-eksempel. En af de bedste måder at se, hvordan SOAP-meddelelser genereres, er nok at se en webtjeneste i aktion.

Dette emne vil se på brugen af Microsoft.Net framework til at bygge en ASMX webservice. Denne type webservice understøtter både SOAP version 1.1 og version 1.2.

ASMX webtjenester genererer automatisk Web Service Definition Language (WSDL) dokument. Dette WSDL-dokument kræves af den kaldende klientapplikation, så applikationen ved, hvad webtjenesten er i stand til at gøre.

I vores eksempel skal vi oprette en simpel webtjeneste, som skal bruges til at returnere en streng til den applikation, der kalder webtjenesten. Denne webtjeneste vil blive hostet i en Asp.Net webapplikation. Vi vil derefter påberåbe os webservicen og se resultatet, der returneres af webservicen.

Visual Studio viser os også, hvad SOAP-beskeden er, der sendes mellem webtjenesten og den kaldende applikation. Den første forudsætning for at konfigurere vores webtjenesteapplikation kan gøres ved at følge nedenstående trin. Sørg for, at du har Visual Studio 2013 installeret på dit system i dette eksempel.

Trin 1) Det første trin er at oprette en tom ASP.Net webapplikation. Fra Visual Studio 2013 skal du klikke på menupunktet Filer->Nyt projekt.

Når du klikker på indstillingen Nyt projekt, giver Visual Studio dig en anden dialogboks til at vælge projekttype og give de nødvendige detaljer om projektet. Dette forklares i næste trin.

Trin 2) I dette trin,

1. Sørg for først at vælge C# Webskabelon til ASP.NET-webapplikation. Projektet skal være af denne type for at kunne oprette et SOAP-serviceprojekt. Ved at vælge denne indstilling vil Visual Studio derefter udføre de nødvendige trin for at tilføje nødvendige filer, som enhver webbaseret applikation har brug for.
2. Giv dit projekt et navn, som i vores tilfælde er webservice.asmx. Sørg derefter for at angive en placering, hvor projektfilerne skal gemmes.

Når det er gjort, vil du se den projektfil, der er oprettet i din løsningsbrowser i Visual Studio 2013.

Trin 3) I dette trin vil vi tilføje en webservicefil til vores projekt.

1. Højreklik først på projektfilen som vist nedenfor.

2. Når du højreklikker på projektfilen, har du mulighed for at vælge indstillingen "Tilføj->Webtjeneste (ASMX)" for at tilføje en webtjenestefil. Angiv blot navnet på Tutorial Service til webtjenestenavnfilen.

Trin 4) Tilføj følgende kode til din Tutorial Service asmx-fil.

Code Forklaring:

1. Denne kodelinje giver et navn til din webservicefil. Dette er et vigtigt skridt, fordi det giver mulighed for, at klientapplikationen ringer til webtjenesten via navnet på webtjenesten.
2. Normalt bruges en klassefil til at indkapsle funktionaliteten af ​​en webtjeneste. Så klassefilen vil have definitionen af ​​alle webmetoder, som vil give en vis funktionalitet til klientapplikationen.
3. Her er [WebMethod] kendt som en attribut, der beskriver en funktion. Det efterfølgende trin opretter en funktion kaldet "Guru99WebService”, men med inkluderingen af ​​dette trin med at tilføje en [WebMethod]-attribut, sikrer det, at denne metode kan kaldes af en klientapplikation. Hvis denne attribut ikke er på plads, kan metoden aldrig kaldes af en klientapplikation.
4. Her definerer vi en funktion kaldet 'Guru99WebService', som vil blive brugt til at returnere en streng til den kaldende klientapplikation. Denne funktion er en webtjeneste, der kan kaldes af enhver klientapplikation.
5. Vi bruger return-sætningen til at returnere strengen "Dette er en Guru99 Webtjeneste” til klientapplikationen.

Hvis koden eksekveres med succes, vil følgende output blive vist, når du kører din kode i browseren.

Output:

• Outputtet viser tydeligt, at navnet på vores webtjeneste er "Guru99 Web Service”, som er resultatet af at give vores webtjeneste et navn.
• Vi kan også se, at vi kan kalde webtjenesten. Hvis vi klikker på knappen "Invoke", får vi nedenstående svar i webbrowseren.

Ovenstående output:

• Det viser tydeligt, at ved at kalde web-metoden, bliver strengen "Dette er en Guru"99 Webtjeneste" returneres.
• Visual Studio giver dig også mulighed for at se SOAP-meddelelsesanmodningen og -svaret, som genereres, når ovenstående webservice kaldes.

SOAP-anmodningen, som genereres, når webtjenesten kaldes, er vist nedenfor.

Code Forklaring:

1. Den første del af SOAP-meddelelsen er envelope-elementet, som blev diskuteret i de foregående kapitler. Dette er det indkapslende element, der findes i alle SOAP-meddelelser.
2. SOAP Body er det næste element og indeholder de faktiske detaljer om SOAP-meddelelsen.
3. Den tredje del er det element, der specificerer, at vi vil kalde tjenesten, som kaldes '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 Forklaring:

1. Den første del af SOAP-meddelelsen er envelope-elementet, som blev diskuteret i de foregående kapitler. Dette er det indkapslende element, der findes i alle SOAP-meddelelser.
2. SOAP Body er det næste element og indeholder de faktiske detaljer om SOAP-meddelelsen.
3. Den interessante del, du vil se nu, er attributten 'string'. Denne fortæller klientapplikationen, at den webtjeneste, der kaldes, returnerer et objekt af typen string. Dette er meget nyttigt, fordi klientapplikationen ellers ikke ville vide, hvad webtjenesten returnerer.

Ofte Stillede Spørgsmål