SOAP Web Services-veiledning: Hva er SOAP-protokollen?

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 senere forkortet til SOAP v1.2. SOAP er en protokoll, eller med andre ord en definisjon av hvordan webtjenester kommuniserer med hverandre eller 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 finnes det et stort antall applikasjoner som er bygget på forskjellige programmeringsspråk. For eksempel kan det være en webapplikasjon 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 finnes ingen standardspesifikasjoner for bruk av XML på tvers av alle programmeringsspråk for datautveksling. Det er her SOAP-programvare kommer inn i bildet.

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 utviklingenping For SOAP-baserte webtjenester trenger du et språk som kan brukes av webtjenester til å kommunisere 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 webstandarder.
• SOAP er en lettvektsprotokoll som brukes for datautveksling mellom applikasjoner. Legg merke til nøkkelordet 'lettSiden SOAP-programmering er basert på XML-språket, som i seg selv er et lettvektsspråk for datautveksling, faller SOAP som protokoll også i samme kategori.
• SOAP er designet for å være plattformuavhengig og operativsystemuavhengig. Så SOAP-protokollen kan fungere med alle programmeringsspråkbaserte applikasjoner på begge Windows og Linux plattformer.
• Den fungerer på HTTP-protokollen – SOAP fungerer på HTTP-protokollen, som er standardprotokollen som brukes av alle webapplikasjoner. Derfor kreves det ingen form for tilpasning for å kjøre webtjenestene som er bygget på SOAP-protokollen, slik at de fungerer 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.

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

• An Konvolutt element som identifiserer XML-dokumentet som en SOAP-melding – Dette er den inneholdende delen av SOAP-meldingen og brukes til å innkapsle alle detaljene i SOAP-meldingen. Dette er rotelementet i SOAP-meldingen.
• A Header element som inneholder headerinformasjon – Header-elementet kan inneholde informasjon som autentiseringslegitimasjon som kan brukes av den kallende applikasjonen. Det 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 vises nedenfor. Anta at vi ønsket å sende en strukturert datatype som hadde en kombinasjon av et «Opplæringsnavn» og et «Opplæringsnavn». Description», ville vi definere den komplekse typen som vist nedenfor. Den komplekse typen er definert av elementkoden Alle de nødvendige elementene i strukturen sammen med deres respektive datatyper defineres deretter 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>

A Body element som inneholder informasjon om anrop og svar – Dette elementet inneholder de faktiske dataene som må sendes mellom webtjenesten og den anropende applikasjonen. Nedenfor er et eksempel på en SOAP-webtjeneste som faktisk fungerer på den komplekse typen som er definert i overskriftsdelen. Her er svaret til opplæringsnavnet og opplæringen. 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 omtalt i det forrige emnet i denne SOAP-opplæringen, har en enkel SOAP-melding følgende elementer:

• Konvoluttelementet
• Header-elementet, og
• Kroppselementet
• Feilelementet (valgfritt)

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

1. Som det fremgår av SOAP-meldingen ovenfor, er den første delen av SOAP-meldingen konvoluttelementet som brukes til å innkapsle hele SOAP-meldingen.
2. Det neste elementet er SOAP-kroppen som inneholder detaljene i selve meldingen.
3. Meldingen vår inneholder en nettjeneste som har navnet «Guru99WebService”.
4. Den "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 navnet på webtjenesten er, hvilke parametere den forventer, og hvilken type 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 rot-Envelope-element. Det er absolutt obligatorisk at en SOAP-melding har et envelope-element.
• 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 ha to former: et vellykket svar eller et feilsvar. Når en vellykket forespørsel 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.

1. <faultCode> – 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.
2. – Dette er tekstmeldingen som gir en detaljert beskrivelse av feilen.
3. (Valgfri) – Dette er en tekststreng som indikerer hvem som forårsaket feilen.
4. (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 i et scenario der klienten prøver å bruke en metode kalt TutorialID i klassen GetTutorial. Feilmeldingen nedenfor genereres dersom metoden ikke finnes 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 feilmeldingen «Klarte 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.

I denne SOAP API-veiledningen skal vi nå se på diagrammet nedenfor for å se hvordan denne kommunikasjonen fungerer. I dette eksemplet antar vi at serveren er vert for en webtjeneste som tilbyr to metoder som:

• Få ansatt – Dette ville hente alle ansattdetaljer.
• Sett medarbeider – Dette ville sette verdien av detaljer som en ansatts avdeling, lønn osv. deretter.

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.

Kommunikasjonsmodellen ovenfor har følgende alvorlige begrensninger:

1. Ikke språkuavhengig – Serveren som er vert for metodene, ville være på et bestemt programmeringsspråk, og normalt ville kallene til serveren bare være på det programmeringsspråket.
2. 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.
3. 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, ville SOAP deretter bruke kommunikasjonsmodellen nedenfor.

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

Praktisk SÅPE eksempel

Nå i dette SoapUI I denne veiledningen skal vi se på et praktisk SOAP-eksempel. Sannsynligvis er en av de beste måtene å se hvordan SOAP-meldinger genereres å faktisk se en webtjeneste 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 opprette en enkel webtjeneste som skal brukes til å returnere en streng til applikasjonen som kaller webtjenesten. Denne webtjenesten vil være driftet 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 som sendes mellom webtjenesten og den kallende applikasjonen er. Den første forutsetningen for å konfigurere webtjenesteapplikasjonen vår kan gjøres ved å følge trinnene nedenfor. Sørg for at du har Visual Studio 2013 installert på systemet ditt for dette eksemplet.

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

1. Sørg for å velge først C# Nettmal for ASP.NET-nettapplikasjon. Prosjektet må være av denne typen for å kunne opprette et SOAP-tjenesteprosjekt. Ved å velge dette alternativet vil Visual Studio deretter utføre de nødvendige trinnene for å legge til nødvendige filer som trengs av et hvilket som helst nettbasert program.
2. Gi prosjektet et navn, som i vårt tilfelle er webservice.asmx. Sørg deretter for å oppgi en plassering der prosjektfilene skal lagres.

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

Trinn 3) I dette trinnet skal vi legge til en webtjenestefil i prosjektet vårt.

1. Først høyreklikker du på prosjektfilen som vist nedenfor.

2. Når du høyreklikker på prosjektfilen, har du muligheten til å velge alternativet «Legg til->Webtjeneste (ASMX)» for å legge til en webtjenestefil. Bare oppgi navnet på veiledningstjenesten for webtjenestenavnfilen.

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

Code Forklaring:

1. Denne kodelinjen gir et navn for webtjenestefilen. Dette er et viktig skritt fordi det gir plass for klientapplikasjonen å ringe webtjenesten via navnet på webtjenesten.
2. 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.
3. Her er [WebMethod] kjent som et attributt som beskriver en funksjon. Det påfølgende trinnet oppretter en funksjon kalt «Guru99WebService», men med inkluderingen av dette trinnet med å legge til et [WebMethod]-attributt, sørger det for at denne metoden kan kalles av et klientprogram. Hvis dette attributtet ikke er på plass, kan metoden aldri kalles av et klientprogram.
4. Her definerer vi en funksjon som heter 'Guru99WebService' som vil bli brukt til å returnere en streng til den kallende klientapplikasjonen. Denne funksjonen er en webtjeneste som kan kalles av en hvilken som helst klientapplikasjon.
5. Vi bruker return-setningen for å returnere strengen «Dette er en Guru99 Webtjeneste» til klientapplikasjonen.

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

Utgang:

• Resultatet viser tydelig at navnet på webtjenesten vår er «Guru99 Web Service», som er resultatet av å gi et navn til webtjenesten vår.
• Vi kan også se at vi kan kalle webtjenesten. Hvis vi klikker på Kall-knappen, får vi svaret nedenfor i nettleseren.

Ovennevnte utgang:

• Det viser tydelig at ved å kalle web-metoden, blir strengen «Dette er en Guru«99 Webtjeneste» returneres.
• 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.

Code Forklaring:

1. Den første delen av SOAP-meldingen er konvoluttelementet, som ble diskutert i de foregående kapitlene. Dette er innkapslingselementet som finnes i alle SOAP-meldinger.
2. SOAP Body er det neste elementet og inneholder de faktiske detaljene i SOAP-meldingen.
3. Den tredje delen er elementet som spesifiserer at vi ønsker å kalle tjenesten som kalles '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 delen av SOAP-meldingen er konvoluttelementet, som ble diskutert i de foregående kapitlene. Dette er innkapslingselementet som finnes i alle SOAP-meldinger.
2. SOAP Body er det neste elementet og inneholder de faktiske detaljene i SOAP-meldingen.
3. Den interessante delen du vil se nå er attributtet «string». Dette forteller klientapplikasjonen at webtjenesten som kalles returnerer et objekt av typen streng. Dette er veldig nyttig fordi klientapplikasjonen ellers ikke ville vite hva webtjenesten returnerer.

Spørsmål og svar