SOAP Web Services Tutorial: Hvad er SOAP-protokol? EKSEMPEL

Indholdsfortegnelse:

Anonim

Hvad er SOAP?

SOAP er en XML-baseret protokol til adgang til webtjenester via HTTP. Det har en specifikation, som 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 webservices taler med hinanden eller taler med klientapplikationer, der påberåber dem.

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

I denne vejledning til SOAP-webtjenester lærer du-

  • SOAP Introduktion
  • Fordele ved SOAP
  • SOAP Byggesten
  • SOAP-meddelelsesstruktur
  • SOAP-kuvertelement
  • SOAP-kommunikationsmodel
  • Praktisk SOAP-eksempel

SOAP Introduktion

I dagens verden er der et stort 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 nutidens netværk verden. Men dataudveksling mellem disse heterogene applikationer ville være kompleks. Så vil det være kompleksiteten i koden til at udføre denne dataudveksling.

En af metoderne til bekæmpelse af denne kompleksitet er at bruge XML (Extensible Markup Language) som det mellemliggende sprog til udveksling af data mellem applikationer.

Hvert programmeringssprog kan forstå XML-markupsproget. Derfor blev XML brugt som det underliggende medium til dataudveksling.

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

SOAP blev designet til at arbejde med XML over HTTP og have en slags specifikation, som kunne bruges på tværs af alle applikationer. Vi vil se nærmere på 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 du udvikler SOAP-baserede webtjenester, skal du have noget af sproget, som kan bruges til webtjenester til at tale med klientapplikationer. SOAP er det perfekte medium, der blev udviklet for at nå 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 ' lys '. Da SOAP-programmering er baseret på XML-sproget, som i sig selv er et letvægtsdataudvekslingssprog, derfor SOAP som en protokol, der også falder 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 på ethvert programmeringssprogbaserede applikationer på både Windows- og Linux-platformen.
  • 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 de webtjenester, der er bygget på SOAP-protokollen for at arbejde på World Wide Web.

SOAP-byggesten

SOAP-specifikationen definerer noget kendt som en " SOAP-besked ", som sendes til webservicen og klientapplikationen.

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

SOAP besked byggesten

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

  • Et kuvertelement, 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.
  • Et headerelement, der indeholder headerinformation - headerelementet kan indeholde oplysninger såsom godkendelseslegitimationsoplysninger, der kan bruges af den opkaldende 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 enkle typer såsom strenge og tal, men kan også 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 "Vejledningsnavn" og en "Vejledningsbeskrivelse", så ville vi definere den komplekse type som vist nedenfor.

Den komplekse type er defineret af elementtagget . Alle de krævede elementer i strukturen sammen med deres respektive datatyper defineres derefter i den komplekse typesamling.

  • Et Body-element, der indeholder opkalds- og svaroplysninger - Dette element indeholder de faktiske data, der skal sendes mellem webservicen og den opkaldende applikation. Nedenfor er et SOAP-webtjenesteeksempel på SOAP-kroppen, der faktisk fungerer på den komplekse type, der er defineret i overskriftssektionen. Her er svaret på vejledningsnavnet og vejledningsbeskrivelsen, der sendes til den kaldende applikation, der kalder denne webservice.
Web ServicesAll about web services

SOAP-meddelelsesstruktur

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

Hver gang en klientapplikation kalder en metode i webservicen, genererer webservicen automatisk en SOAP-meddelelse, som vil have de nødvendige detaljer om de data, der sendes fra webservicen til klientapplikationen.

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

  • Konvolut-elementet
  • Overskriftelementet og
  • Kropselementet
  • Fejlelementet (valgfrit)

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

SOAP-meddelelsesstruktur
  1. Som det ses fra ovenstående SOAP-meddelelse, er den første del af SOAP-meddelelsen det konvolutelement, der bruges til at indkapsle hele SOAP-meddelelsen.
  2. Det næste element er SOAP-kroppen, der indeholder detaljerne i den aktuelle meddelelse.
  3. Vores meddelelse indeholder en webservice, der har navnet "Guru99WebService".
  4. "Guru99Webservice" accepterer en parameter af typen 'int' og har navnet TutorialID.

Nu sendes ovenstående SOAP-meddelelse mellem webservicen og klientapplikationen.

Du kan se, hvor nyttige ovenstående oplysninger er for klientapplikationen. SOAP-meddelelsen fortæller klientapplikationen, hvad navnet på webservicen er, og også hvilke parametre den forventer, og også hvad der er typen af ​​hver parameter, der tages af webservicen.

SOAP-kuvertelement

Den første bit af byggesten er SOAP Envelope.

SOAP-konvolutten bruges til at indkapsle alle de nødvendige detaljer i SOAP-meddelelserne, der 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 ringer til webservicen, at vide, hvornår SOAP-meddelelsen slutter.

Følgende punkter kan bemærkes på SOAP-kuvertelementet.

  • Hver SOAP-besked skal have et rodkonvolutelement. Det er absolut obligatorisk for SOAP-beskeder at have et kuvertelement.
  • Hvert kuvertelement skal have mindst et sæbeelement.
  • Hvis et konvolutelement indeholder et headerelement, må det ikke indeholde mere end et, og det skal vises som det første barn i konvolutten før body-elementet.
  • Konvolutten ændres, når SOAP-versioner ændres.
  • En v1.1-kompatibel SOAP-processor genererer en fejl ved modtagelse af en meddelelse, der indeholder v1.2-konvoluttens navneområde.
  • En v1.2-kompatibel SOAP-processor genererer en Version Mismatch-fejl, hvis den modtager en meddelelse, der ikke inkluderer v1.2-konvoluttens navneområde.

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

int

Fejlmeddelelsen

Når der fremsættes en anmodning til en SOAP-webtjeneste, kan det returnerede svar være af enten 2 formularer, der er et vellykket svar eller et fejlsvar. Når der genereres en succes, vil svaret fra serveren altid være en SOAP-besked. Men hvis der genereres SOAP-fejl, returneres de som "HTTP 500" -fejl.

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

  1. - Dette er den kode, der angiver fejlkoden. Fejlkoden kan være en af ​​nedenstående værdier
    1. SOAP-ENV: VersionMismatch - Dette er, når der opstår et ugyldigt navneområde for SOAP Envelope-elementet.
    2. SOAP-ENV: MustUnderstand - Et øjeblikkeligt underordnet element i Header-elementet med attributten mustUnderstand indstillet til "1" blev ikke forstået.
    3. SOAP-ENV: Klient - Meddelelsen var forkert dannet eller indeholdt forkerte oplysninger.
    4. SOAP-ENV: Server - Der var et problem med serveren, så meddelelsen kunne ikke fortsætte.
  2. - Dette er tekstbeskeden, der giver en detaljeret beskrivelse af fejlen.
  3. (valgfrit) - Dette er en tekststreng, der angiver, hvem der forårsagede fejlen.
  4. (valgfrit) - Dette er elementet til applikationsspecifikke fejlmeddelelser. Så applikationen kunne have en specifik fejlmeddelelse til forskellige forretningslogiske scenarier.

Eksempel på fejlmeddelelse

Nedenfor gives et eksempel på en fejlmeddelelse. Fejlen genereres, hvis scenariet hvor klienten forsøger at bruge en metode kaldet TutorialID i klassen GetTutorial.

Fejlmeddelelsen nedenfor genereres, hvis metoden ikke findes i den definerede klasse.

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

Produktion:

Når du udfører ovenstående kode, viser den fejlen som "Kunne ikke finde metode (GetTutorialID) i klasse (GetTutorial)"

SOAP-kommunikationsmodel

Al kommunikation via SOAP sker via HTTP-protokollen. Forud for SOAP brugte mange webtjenester standard RPC-stil (Remote Procedure Call) til kommunikation. Dette var den enkleste form for kommunikation, men den havde mange begrænsninger.

Lad os nu overveje nedenstående diagram i denne SOAP API-tutorial for at se, hvordan denne kommunikation fungerer. Lad os i dette eksempel antage, at serveren er vært for en webservice, der leverede 2 metoder som

  • GetEmployee - Dette vil få alle medarbejderoplysninger
  • SetEmployee - Dette indstiller værdien af ​​detaljerne som medarbejderafdækning, løn osv. Tilsvarende .

I den normale RPC-stilkommunikation kalder klienten bare metoderne i sin anmodning og sender de nødvendige parametre til serveren, og serveren sender derefter det ønskede svar.

Ovenstående kommunikationsmodel har nedenstående alvorlige begrænsninger

  1. Ikke sproguafhængigt - Serveren, der er vært for metoderne, vil være på et bestemt programmeringssprog, og normalt vil opkaldene til serveren kun være på det programmeringssprog.
  2. Ikke standardprotokollen - Når der foretages et opkald til fjernproceduren, udføres opkaldet ikke via standardprotokollen. Dette var et problem, da for det meste al kommunikation over internettet skulle ske via HTTP-protokollen.
  3. Firewalls - Da RPC-opkald ikke foregår via den normale protokol, skal separate porte være åbne på serveren for at give klienten mulighed for at kommunikere med serveren. Normalt vil alle firewalls blokere for denne type trafik, og der kræves generelt en masse konfiguration for at sikre, at denne form for kommunikation mellem klienten og serveren fungerer.

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

  1. Klienten ville formatere oplysningerne om procedurekaldet og eventuelle argumenter i en SOAP-besked og sende dem til serveren som en del af en HTTP-anmodning. Denne proces med indkapsling af data i en SOAP-meddelelse blev kendt som Marshalling.
  2. Serveren udpakker derefter beskeden sendt af klienten, ser hvad klienten anmodede om og sender derefter det relevante svar tilbage til klienten som en SOAP-besked. Praksisen med at udpakke en anmodning sendt af klienten kaldes Demarshalling.

Praktisk SOAP-eksempel

Lad os nu se et praktisk SOAP-eksempel i denne SoapUI-selvstudie,

Sandsynligvis en af ​​de bedste måder at se, hvordan SOAP-meddelelser genereres, er at faktisk se en webservice i aktion.

Dette emne vil se på brug af Microsoft.Net-rammen til at opbygge en ASMX-webservice. Denne type webservice understøtter både SOAP version 1.1 og version 1.2.

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

I vores eksempel skal vi oprette en simpel webtjeneste, som bruges til at returnere en streng til applikationen, der kalder webservicen.

Denne webservice hostes i en Asp.Net-webapplikation. Vi påkalder derefter webservicen og ser resultatet, der returneres af webservicen.

Visual Studio viser os også, hvad SOAP-meddelelsen sendes mellem webservicen og den opkaldende applikation.

Den første forudsætning for at konfigurere vores webserviceapplikation, som kan gøres ved at følge nedenstående trin.

Sørg for, at du har Visual Studio 2013 installeret på dit system til 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 derefter en anden dialogboks til valg af projekttype og til at give de nødvendige detaljer om projektet. Dette forklares i det næste trin.

Trin 2) I dette trin,

  1. Sørg for først at vælge C #-webskabelonen til ASP.NET-webapplikationen. Projektet skal være af denne type for at oprette SOAP-serviceprojekt. Ved at vælge denne mulighed udfører Visual Studio derefter de nødvendige trin for at tilføje krævede filer, som kræves af ethvert webbaseret program.
  2. Giv et projektnavn, som i vores tilfælde er blevet givet som webservice.asmx. Sørg derefter for at give et sted, hvor projektfilerne gemmes.

Når du er færdig, vil du se projektfilen oprettet i din løsningsudforsker i Visual Studio 2013.

Trin 3) I dette trin,

Vi vil tilføje en webservicefil til vores projekt

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

  1. Når du højreklikker på projektfilen, har du chancen for at vælge indstillingen "Tilføj-> Webtjeneste (ASMX) for at tilføje en webservicefil. Angiv blot et selvstudietjeneste til webtjenestens navnefil.

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

Kode Forklaring:

  1. Denne kodelinje giver et navn til din webservicefil. Dette er et vigtigt skridt, fordi det giver plads for klientapplikationen til at ringe til webtjenesten via navnet på webservicen.
  2. Normalt bruges en klassefil til at indkapsle en webservices funktionalitet. Så klassefilen vil have definitionen af ​​alle de webmetoder, der giver klientapplikationen en vis funktionalitet.
  3. Her er [WebMethod] kendt som en attribut, der beskriver en funktion. Det efterfølgende trin opretter en funktion kaldet "Guru99WebService", men med medtagelsen af ​​dette trin at tilføje en [WebMethod] -attribut sørger for, at denne metode kan påberåbes af en klientapplikation. Hvis denne attribut ikke er på plads, kan metoden aldrig kaldes op af et klientprogram.
  4. Her definerer vi en funktion kaldet 'Guru99WebService', som bruges til at returnere en streng til den kaldende klientapplikation. Denne funktion er en webservice, der kan kaldes af ethvert klientprogram.
  5. Vi bruger retursætningen til at returnere strengen "Dette er en Guru99-webtjeneste" til klientapplikationen.

Hvis koden udføres med succes, vises følgende output, når du kører din kode i browseren.

Produktion:

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

Ovenstående output,

  • Det viser tydeligt, at ved at påkalde webmetoden returneres strengen "Dette er en Guru99-webtjeneste".
  • Visual Studio giver dig også mulighed for at se SOAP-meddelelsesanmodningen og -svaret, der genereres, når ovenstående webservice kaldes.

SOAP-anmodningen, der genereres, når webservicen kaldes, vises nedenfor.

Kode Forklaring:

  1. Den første del af SOAP-meddelelsen er konvolutelementet, hvilket er det, der blev diskuteret i de foregående kapitler. Dette er det indkapslende element, der findes i enhver SOAP-besked.
  2. SOAP Body er det næste element og indeholder de faktiske detaljer i SOAP-meddelelsen.
  3. Den tredje del er det element, der specificerer, at vi vil kalde den service, der hedder 'Guru99WebService.'

string

Kode Forklaring:

  1. Den første del af SOAP-meddelelsen er konvolutelementet, hvilket er det, der blev diskuteret i de foregående kapitler. Dette er det indkapslende element, der findes i enhver SOAP-besked.
  2. SOAP Body er det næste element og indeholder de faktiske detaljer i SOAP-meddelelsen.
  3. Den interessante del, du vil se nu, er attributten 'streng'. Dette fortæller klientapplikationen, at den webtjeneste, der kaldes, returnerer et objekt af typestrengen. Dette er meget nyttigt, for hvis klientapplikationen, som ellers ikke ville vide, hvad webtjenesten returnerer.

Resumé

  • SOAP er en protokol, der bruges til at udveksle data mellem applikationer, der er bygget på forskellige programmeringssprog.
  • SOAP er bygget på XML-specifikationen og fungerer med HTTP-protokollen. Dette gør det perfekt til brug inden for webapplikationer.
  • SOAP-byggestenene består af en SOAP-meddelelse. Hver SOAP-besked består af et kuvertelement, en overskrift og et kropselement.
  • Konvolutelementet er det obligatoriske element i SOAP-meddelelsen og bruges til at indkapsle alle data i SOAP-meddelelsen.
  • Overskriftelementet kan bruges til at indeholde oplysninger såsom godkendelsesoplysninger eller definitionen af ​​komplekse datatyper.
  • Kroppselementet er hovedelementet, der indeholder definitionen af ​​webmetoderne sammen med eventuelle parameteroplysninger, hvis det kræves.