SOAP Web Services Tutorial: Hva er SOAP Protocol? EKSEMPEL

Hva er SOAP?

SOAP er en XML-basert protokoll for tilgang til webtjenester over HTTP. Den har noen spesifikasjoner som kan brukes på tvers av alle applikasjoner.

SOAP er kjent som Simple Object Access Protocol, men ble i senere tider bare forkortet til SOAP v1.2. SOAP er en protokoll eller med andre ord er en definisjon av hvordan webtjenester snakker med hverandre eller snakker med klientapplikasjoner som påkaller dem.

SOAP ble utviklet som et mellomspråk slik at applikasjoner bygget på ulike programmeringsspråk enkelt kunne snakke med hverandre og unngå den ekstreme utviklingsinnsatsen.

SOAP Introduksjon

I dagens verden er det et stort antall applikasjoner som er bygget på forskjellige programmeringsspråk. For eksempel kan det være en nettapplikasjon designet i Java, en annen i .Net og en annen i PHP.

Utveksling av data mellom applikasjoner er avgjørende i dagens nettverksverden. Men datautveksling mellom disse heterogene applikasjonene ville være komplisert. Det vil også være kompleksiteten til koden for å oppnå denne datautvekslingen.

En av metodene som brukes for å bekjempe denne kompleksiteten er å bruke XML (Extensible Markup Language) som mellomspråk for utveksling av data mellom applikasjoner.

Hvert programmeringsspråk kan forstå XML-markeringsspråket. Derfor ble XML brukt som det underliggende mediet for datautveksling.

Men det er ingen standardspesifikasjoner for bruk av XML på tvers av alle programmeringsspråk for datautveksling. Det er her SOAP-programvaren kommer inn.

SOAP ble designet for å fungere med XML over HTTP og har en slags spesifikasjon som kan brukes på tvers av alle applikasjoner. Vi vil se nærmere på detaljer om SOAP-protokollen i de påfølgende kapitlene.

Fordeler med SOAP

SOAP er protokollen som brukes for datautveksling mellom applikasjoner. Nedenfor er noen av grunnene til hvorfor SOAP brukes.

Når du utvikler SOAP-baserte webtjenester, må du ha noe språk som kan brukes for webtjenester for å snakke med klientapplikasjoner. SOAP er det perfekte mediet som ble utviklet for å oppnå dette formålet. Denne protokollen anbefales også av W3C-konsortiet som er det styrende organet for alle nettstandarder.
SOAP er en lettvektsprotokoll som brukes for datautveksling mellom applikasjoner. Legg merke til nøkkelordet 'lett.' Siden SOAP-programmering er basert på XML-språket, som i seg selv er et lett datautvekslingsspråk, derav SOAP som en protokoll som også faller i samme kategori.
SOAP er designet for å være plattformuavhengig og er også designet for å være operativsystemuavhengig. Så SOAP-protokollen kan fungere på alle programmeringsspråkbaserte applikasjoner på begge Windows og Linux plattform.
Den fungerer på HTTP-protokollen – SOAP fungerer på HTTP-protokollen, som er standardprotokollen som brukes av alle nettapplikasjoner. Derfor er det ingen form for tilpasning som kreves for å kjøre nettjenestene bygget på SOAP-protokollen for å fungere på World Wide Web.

SÅPE byggeklosser

SOAP-spesifikasjonen definerer noe kjent som en "SOAP melding” som er det som sendes til webtjenesten og klientapplikasjonen.

Diagrammet nedenfor over SOAP-arkitektur viser de ulike byggesteinene til en SOAP-melding.

SÅPE byggeklosser — SOAP Message Building Blocks

SOAP-meldingen er ikke annet enn et XML-dokument som har komponentene nedenfor.

Et konvoluttelement som identifiserer XML-dokumentet som en SOAP-melding – Dette er den delen av SOAP-meldingen og brukes til å kapsle inn alle detaljene i SOAP-meldingen. Dette er rotelementet i SOAP-meldingen.
Et overskriftselement som inneholder overskriftsinformasjon – Overskriftselementet kan inneholde informasjon som autentiseringslegitimasjon som kan brukes av den anropende applikasjonen. Den kan også inneholde definisjonen av komplekse typer som kan brukes i SOAP-meldingen. Som standard kan SOAP-meldingen inneholde parametere som kan være av enkle typer som strenger og tall, men kan også være en kompleks objekttype.

Et enkelt SOAP-tjenesteeksempel av en kompleks type er vist nedenfor.

Anta at vi ønsket å sende en strukturert datatype som hadde en kombinasjon av et "Tutorial Name" og en "Tutorial" Description," så ville vi definere den komplekse typen som vist nedenfor.

Den komplekse typen er definert av element-taggen . Alle de nødvendige elementene i strukturen sammen med deres respektive datatyper blir deretter definert i den komplekse typesamlingen.

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

Et Body-element som inneholder anrops- og svarinformasjon – Dette elementet er det som inneholder de faktiske dataene som må sendes mellom nettjenesten og anropsapplikasjonen. Nedenfor er et SOAP-webtjenesteeksempel på SOAP-kroppen som faktisk fungerer på den komplekse typen som er definert i overskriftsdelen. Her er svaret til opplæringens navn og veiledning Description som sendes til anropsapplikasjonen som kaller denne nettjenesten.

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

SOAP meldingsstruktur

En ting å merke seg er at SOAP-meldinger normalt genereres automatisk av nettjenesten når den kalles opp.

Hver gang en klientapplikasjon kaller en metode i webtjenesten, vil webtjenesten automatisk generere en SOAP-melding som vil ha de nødvendige detaljene for dataene som sendes fra webtjenesten til klientapplikasjonen.

Som diskutert i forrige emne i denne SOAP-opplæringen, har en enkel SOAP-melding følgende elementer -

Konvoluttelementet
Overskriftselementet og
Kroppselementet
Feilelementet (valgfritt)

La oss se på et eksempel nedenfor på en enkel SOAP-melding og se hva elementet faktisk gjør.

Som det fremgår av SOAP-meldingen ovenfor, er den første delen av SOAP-meldingen konvoluttelementet som brukes til å innkapsle hele SOAP-meldingen.
Det neste elementet er SOAP-kroppen som inneholder detaljene i selve meldingen.
Vår melding inneholder en webtjeneste som har navnet "Guru99WebService".
"Guru99Webservice" godtar en parameter av typen 'int' og har navnet TutorialID.

Nå vil SOAP-meldingen ovenfor sendes mellom webtjenesten og klientapplikasjonen.

Du kan se hvor nyttig informasjonen ovenfor er for klientapplikasjonen. SOAP-meldingen forteller klientapplikasjonen hva som er navnet på webtjenesten, og også hvilke parametere den forventer og også hva som er typen av hver parameter som tas av webtjenesten.

SÅPE konvoluttelement

Den første delen av byggesteinen er SOAP-konvolutten.

SOAP-konvolutten brukes til å kapsle inn alle nødvendige detaljer i SOAP-meldingene, som utveksles mellom webtjenesten og klientapplikasjonen.

SOAP-konvoluttelementet brukes til å indikere begynnelsen og slutten av en SOAP-melding. Dette gjør at klientapplikasjonen som ringer nettjenesten kan vite når SOAP-meldingen slutter.

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

Hver SOAP-melding må ha et rotkonvoluttelement. Det er absolutt obligatorisk for SOAP-melding å ha et konvoluttelement.
Hvert konvoluttelement må ha minst ett såpeelement.
Hvis et konvoluttelement inneholder et overskriftselement, må det ikke inneholde mer enn ett, og det må vises som det første underordnede elementet til konvolutten, før hovedelementet.
Konvolutten endres når SOAP-versjoner endres.
En v1.1-kompatibel SOAP-prosessor genererer en feil ved mottak av en melding som inneholder v1.2-konvoluttnavneområdet.
En v1.2-kompatibel SOAP-prosessor genererer en versjonsfeil hvis den mottar en melding som ikke inkluderer v1.2-konvoluttnavneområdet.

Nedenfor er et SOAP API-eksempel på versjon 1.2 av SOAP-konvoluttelementet.

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

Feilmeldingen

Når en forespørsel sendes til en SOAP-webtjeneste, kan svaret som returneres enten ha 2 skjemaer som er et vellykket svar eller et feilsvar. Når en suksess genereres, vil svaret fra serveren alltid være en SOAP-melding. Men hvis SOAP-feil genereres, returneres de som "HTTP 500"-feil.

SOAP Fault-meldingen består av følgende elementer.

– Dette er koden som angir feilkoden. Feilkoden kan være en av verdiene nedenfor
1. SOAP-ENV:VersionMismatch – Dette er når et ugyldig navneområde for SOAP Envelope-elementet oppdages.
2. SOAP-ENV:MustUnderstand – Et umiddelbart underordnet element av Header-elementet, med mustUnderstand-attributtet satt til "1", ble ikke forstått.
3. SOAP-ENV:Client – Meldingen var feil utformet eller inneholdt feil informasjon.
4. SOAP-ENV:Server – Det var et problem med serveren, så meldingen kunne ikke fortsette.
– Dette er tekstmeldingen som gir en detaljert beskrivelse av feilen.
(Valgfri)– Dette er en tekststreng som indikerer hvem som forårsaket feilen.
(Valgfri) – Dette er elementet for applikasjonsspesifikke feilmeldinger. Så applikasjonen kan ha en spesifikk feilmelding for forskjellige forretningslogiske scenarier.

Eksempel på feilmelding

Et eksempel på en feilmelding er gitt nedenfor. Feilen genereres hvis scenariet der klienten prøver å bruke en metode kalt TutorialID i klassen GetTutorial.

Feilmeldingen nedenfor genereres i tilfelle metoden ikke eksisterer i den definerte 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>

Utgang:

Når du kjører koden ovenfor, vil den vise feilen som "Kunnet ikke finne metoden (GetTutorialID) i klassen (GetTutorial)"

SOAP kommunikasjonsmodell

All kommunikasjon med SOAP skjer via HTTP-protokollen. Før SOAP, mye av webtjenester brukte standard RPC-stil (Remote Procedure Call) for kommunikasjon. Dette var den enkleste typen kommunikasjon, men den hadde mange begrensninger.

Nå i denne SOAP API-opplæringen, la oss vurdere diagrammet nedenfor for å se hvordan denne kommunikasjonen fungerer. I dette eksemplet, la oss anta at serveren er vert for en webtjeneste som ga 2 metoder som

Få ansatt – Dette vil få alle ansattes detaljer
Sett medarbeider – Dette vil sette verdien av detaljene som ansatteavdeling, lønn osv. tilsvarende.

I normal RPC-stil kommunikasjon, ville klienten bare kalle metodene i sin forespørsel og sende de nødvendige parameterne til serveren, og serveren ville deretter sende ønsket svar.

Ovennevnte kommunikasjonsmodell har alvorlige begrensninger nedenfor

Ikke språkuavhengig – Serveren som er vert for metodene vil være på et bestemt programmeringsspråk, og normalt vil kallene til serveren bare være på det programmeringsspråket.
Ikke standardprotokollen – Når det foretas et anrop til fjernprosedyren, utføres ikke anropet via standardprotokollen. Dette var et problem siden stort sett all kommunikasjon over nettet måtte gjøres via HTTP-protokollen.
Brannmurer – Siden RPC-anrop ikke går via den vanlige protokollen, må separate porter være åpne på serveren for at klienten skal kunne kommunisere med serveren. Normalt vil alle brannmurer blokkere denne typen trafikk, og mye konfigurasjon var generelt nødvendig for å sikre at denne typen kommunikasjon mellom klienten og serveren ville fungere.

For å overvinne alle begrensningene som er nevnt ovenfor, vil SOAP deretter bruke kommunikasjonsmodellen nedenfor

Klienten vil formatere informasjonen om prosedyrekallet og eventuelle argumenter til en SOAP-melding og sende den til serveren som en del av en HTTP-forespørsel. Denne prosessen med å kapsle inn dataene i en SOAP-melding ble kjent som Marshalling.
Serveren vil da pakke ut meldingen sendt av klienten, se hva klienten ba om og deretter sende det riktige svaret tilbake til klienten som en SOAP-melding. Praksisen med å pakke ut en forespørsel sendt av klienten er kjent som Demarshalling.

Praktisk SÅPE eksempel

La oss nå i denne SoapUI-opplæringen se et praktisk SOAP-eksempel,

Sannsynligvis en av de beste måtene å se hvordan SOAP-meldinger genereres, er å faktisk se en nettjeneste i aksjon.

Dette emnet vil se på bruk av Microsoft.Net rammeverk for å bygge en ASMX webtjeneste. Denne typen nettjeneste støtter både SOAP versjon 1.1 og versjon 1.2.

ASMX webtjenester genererer automatisk Web Service Definition Language (WSDL) dokument. Dette WSDL-dokumentet kreves av den anropende klientapplikasjonen slik at applikasjonen vet hva webtjenesten er i stand til å gjøre.

I vårt eksempel skal vi lage en enkel nettjeneste, som skal brukes til å returnere en streng til applikasjonen som kaller nettjenesten.

Denne webtjenesten vil være vert i en Asp.Net webapplikasjon. Vi vil da påkalle nettjenesten og se resultatet som returneres av nettjenesten.

Visual Studio vil også vise oss hva SOAP-meldingen sendes mellom nettjenesten og oppringingsapplikasjonen.

Den første forutsetningen for å sette opp vår webtjenesteapplikasjon, som kan gjøres ved å følge trinnene nedenfor.

Sørg for at du har Visual Studio 2013 installert på systemet ditt for dette eksempelet.

Trinn 1) Det første trinnet er å lage en tom ASP.Net-webapplikasjon. Fra Visual Studio 2013 klikker du på menyvalget Fil->Nytt prosjekt.

Når du klikker på alternativet Nytt prosjekt, vil Visual Studio gi deg en annen dialogboks for å velge type prosjekt og gi de nødvendige detaljene om prosjektet. Dette er forklart i neste trinn.

Trinn 2) I dette trinnet

Sørg for å velge først C# nettmal for ASP.NET webapplikasjon. Prosjektet må være av denne typen for å kunne lage SOAP-tjenesteprosjekt. Ved å velge dette alternativet, vil Visual Studio deretter utføre de nødvendige trinnene for å legge til nødvendige filer som kreves av en nettbasert applikasjon.
Gi et navn på prosjektet ditt som i vårt tilfelle har blitt gitt som webservice.asmx. Sørg deretter for å gi et sted hvor prosjektfilene skal lagres.

Når du er ferdig, vil du se prosjektfilen opprettet i løsningsutforskeren i Visual Studio 2013.

Trinn 3) I dette trinnet

Vi skal legge til en webtjenestefil i prosjektet vårt

Først Høyreklikk på prosjektfilen som vist nedenfor

Når du høyreklikker på prosjektfilen, har du muligheten til å velge alternativet "Legg til->Webtjeneste(ASMX) for å legge til en nettjenestefil. Bare oppgi navnet på Tutorial Service for navnefilen for nettjenesten.

Trinn 4) Legg til følgende kode i Tutorial Service asmx-filen.

Kodeforklaring:

Denne kodelinjen gir et navn for webtjenestefilen. Dette er et viktig skritt fordi det gir plass for klientapplikasjonen å ringe webtjenesten via navnet på webtjenesten.
Normalt brukes en klassefil for å kapsle inn funksjonaliteten til en webtjeneste. Så klassefilen vil ha definisjonen av alle webmetodene som vil gi noe funksjonalitet til klientapplikasjonen.
Her er [WebMethod] kjent som et attributt som beskriver en funksjon. Det påfølgende trinnet oppretter en funksjon kalt "Guru99WebService", men med inkludering av dette trinnet med å legge til et [WebMethod]-attributt sørger du for at denne metoden kan påkalles av en klientapplikasjon. Hvis dette attributtet ikke er på plass, kan metoden aldri kalles opp av en klientapplikasjon.
Her definerer vi en funksjon kalt 'Guru99WebService' som vil bli brukt til å returnere en streng til den anropende klientapplikasjonen. Denne funksjonen er en webtjeneste som kan kalles opp av enhver klientapplikasjon.
Vi bruker returerklæringen for å returnere strengen "This is a Guru99 Web service" til klientapplikasjonen.

Hvis koden utføres vellykket, vil følgende utdata vises når du kjører koden i nettleseren.

Utgang:

Utdataene viser tydelig at navnet på webtjenesten vår er "Guru99 Web Service", som er resultatet av å gi et navn til vår webtjeneste.
Vi kan også se at vi kan påkalle nettjenesten. Hvis vi klikker på Invoke-knappen, får vi svaret nedenfor i nettleseren.

Ovennevnte utgang,

Det viser tydelig at ved å påkalle nettmetoden, returneres strengen "This is a Guru99 Web Service".
Visual Studio lar deg også se SOAP-meldingsforespørselen og svaret som genereres når webtjenesten ovenfor kalles.

SOAP-forespørselen som genereres når nettjenesten kalles opp, vises nedenfor.

Kodeforklaring:

Den første delen av SOAP-meldingen er konvoluttelementet som er det som ble diskutert i de foregående kapitlene. Dette er det innkapslende elementet som er til stede i hver SOAP-melding.
SOAP Body er det neste elementet og inneholder de faktiske detaljene i SOAP-meldingen.
Den tredje delen er elementet som spesifiserer at vi ønsker å kalle tjenesten som heter '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>

Kodeforklaring:

Den første delen av SOAP-meldingen er konvoluttelementet som er det som ble diskutert i de foregående kapitlene. Dette er det innkapslende elementet som er til stede i hver SOAP-melding.
SOAP Body er det neste elementet og inneholder de faktiske detaljene i SOAP-meldingen.
Den interessante delen du vil se nå er 'string'-attributtet. Dette forteller klientapplikasjonen at webtjenesten som kalles returnerer et objekt av typen streng. Dette er veldig nyttig fordi hvis klientapplikasjonen som ellers ikke ville vite hva webtjenesten returnerer.

Sammendrag

SOAP er en protokoll som brukes til å utveksle data mellom applikasjoner som er bygget på forskjellige programmerings språk.
SOAP er bygget på XML-spesifikasjonen og fungerer med HTTP-protokollen. Dette gjør den perfekt for bruk i webapplikasjoner.
SOAP-byggesteinene består av en SOAP-melding. Hver SOAP-melding består av et konvoluttelement, en topptekst og et hovedelement.
Konvoluttelementet er det obligatoriske elementet i SOAP-meldingen og brukes til å kapsle inn alle dataene i SOAP-meldingen.
Header-elementet kan brukes til å inneholde informasjon som autentiseringsinformasjon eller definisjonen av komplekse datatyper.
Body-elementet er hovedelementet som inneholder definisjonen av webmetodene sammen med eventuell parameterinformasjon om nødvendig.

Hva er SOAP?

SOAP Introduksjon

Fordeler med SOAP

RELATERTE ARTIKLER

SÅPE byggeklosser

SOAP meldingsstruktur

SÅPE konvoluttelement

SOAP kommunikasjonsmodell

Praktisk SÅPE eksempel

Sammendrag

Registrer deg for nyhetsbrevet