SOAP Web Services Tutorial: Hva er SOAP Protocol? EKSEMPEL

Innholdsfortegnelse:

Anonim

Hva er SOAP?

SOAP er en XML-basert protokoll for tilgang til webtjenester via HTTP. Den har en spesifikasjon som kan brukes i alle applikasjoner.

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

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

I denne opplæringen for SOAP-webtjenester vil du lære-

  • SOAP Introduksjon
  • Fordeler med SOAP
  • SOAP Byggesteiner
  • SOAP Meldingsstruktur
  • SOAP konvoluttelement
  • SOAP-kommunikasjonsmodell
  • Praktisk SOAP Eksempel

SOAP Introduksjon

I dagens verden er det enormt mange applikasjoner som er bygget på forskjellige programmeringsspråk. For eksempel kan det være et webapplikasjon designet i Java, et annet i .Net og et annet i PHP.

Å utveksle data mellom applikasjoner er avgjørende i dagens nettverksverden. Men datautveksling mellom disse heterogene applikasjonene vil være komplisert. Det vil også være kompleksiteten i 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 underliggende medium for datautveksling.

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

SOAP ble designet for å fungere med XML over HTTP og har en slags spesifikasjon som kan brukes i alle applikasjoner. Vi vil se på ytterligere 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 årsakene til hvorfor SOAP brukes.

  • Når du utvikler SOAP-baserte webtjenester, må du ha noe av språket som kan brukes til 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 styrende organ for alle nettstandarder.
  • SOAP er en lettvektsprotokoll som brukes til datautveksling mellom applikasjoner. Legg merke til nøkkelordet " lys ". Siden SOAP-programmering er basert på XML-språket, som i seg selv er et lettvektsspråk for datautveksling, 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 alle programmeringsspråkbaserte applikasjoner på både Windows og Linux-plattformen.
  • Det fungerer på HTTP-protokollen -SOAP fungerer på HTTP-protokollen, som er standardprotokollen som brukes av alle webapplikasjoner. Derfor er det ingen form for tilpasning som kreves for å kjøre webtjenestene bygget på SOAP-protokollen for å fungere på nettet.

SOAP-byggesteiner

SOAP-spesifikasjonen definerer noe som kalles en " SOAP-melding ", som sendes til webtjenesten og klientapplikasjonen.

Diagrammet nedenfor med SOAP-arkitektur viser de forskjellige byggesteinene til en SOAP-melding.

SOAP Message Building Blocks

SOAP-meldingen er bare et XML-dokument som har komponentene nedenfor.

  • Et konvoluttelement som identifiserer XML-dokumentet som en SOAP-melding - Dette er den inneholder delen av SOAP-meldingen og brukes til å kapsle alle detaljene i SOAP-meldingen. Dette er rotelementet i SOAP-meldingen.
  • Et topptekstelement som inneholder topptekstinformasjon - Topptekstelementet kan inneholde informasjon som autentiseringslegitimasjon som kan brukes av anropsprogrammet. 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 "Opplæringsnavn" og en "Opplæringsbeskrivelse", så ville vi definere den komplekse typen som vist nedenfor.

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

  • Et kroppselement som inneholder samtale- og svarsinformasjon - Dette elementet er det som inneholder de faktiske dataene som må sendes mellom webtjenesten og anropsprogrammet. Nedenfor er et SOAP-webtjenesteeksempel på SOAP-organet som faktisk fungerer på den komplekse typen som er definert i toppteksten. Her er svaret på opplæringsnavnet og opplæringsbeskrivelsen som sendes til anropsprogrammet som kaller denne nettjenesten.
Web ServicesAll about web services

SOAP Meldingsstruktur

En ting å merke seg er at SOAP-meldinger vanligvis genereres automatisk av webtjenesten når den kalles.

Når en klientapplikasjon kaller en metode i webtjenesten, vil webtjenesten automatisk generere en SOAP-melding som vil ha de nødvendige detaljene i dataene som vil bli sendt fra webtjenesten til klientapplikasjonen.

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

  • Konvolutt-elementet
  • Topptekstelementet og
  • Kroppselementet
  • Feilelementet (valgfritt)

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

SOAP Meldingsstruktur
  1. Som sett fra ovennevnte SOAP-melding, er den første delen av SOAP-meldingen konvoluttelementet som brukes til å kapsle hele SOAP-meldingen.
  2. Det neste elementet er SOAP-kroppen som inneholder detaljene i den faktiske meldingen.
  3. Meldingen vår inneholder en nettjeneste som har navnet "Guru99WebService".
  4. "Guru99Webservice" godtar en parameter av typen 'int' og har navnet TutorialID.

Nå overføres SOAP-meldingen mellom webtjenesten og klientapplikasjonen.

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

SOAP konvoluttelement

Den første biten av byggesteinen er SOAP Envelope.

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

SOAP-konvoluttelementet brukes til å indikere begynnelsen og slutten av en SOAP-melding. Dette gjør det mulig for klientapplikasjonen som ringer nettjenesten å vite når SOAP-meldingen avsluttes.

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

  • Hver SOAP-melding må ha et rotkonvoluttelement. Det er absolutt obligatorisk for SOAP-meldinger å ha et konvoluttelement.
  • Hvert konvoluttelement må ha minst ett såpelement.
  • Hvis et konvoluttelement inneholder et topptekstelement, må det ikke inneholde mer enn ett, og det må vises som det første barnet til konvolutten, før kroppselementet.
  • 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-konvoluttnavnområdet.
  • En v1.2-kompatibel SOAP-prosessor genererer en versjonsfeilfeil hvis den mottar en melding som ikke inkluderer v1.2-konvoluttnavnområdet.

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

int

Feilmeldingen

Når det sendes en forespørsel til en SOAP-nettjeneste, kan svaret som returneres være av enten to 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-feilmeldingen består av følgende elementer.

  1. - Dette er koden som angir koden for feilen. Feilkoden kan være noen av verdiene nedenfor
    1. SOAP-ENV: VersionMismatch - Dette er når det oppstår et ugyldig navneområde for SOAP Envelope-elementet.
    2. SOAP-ENV: MustUnderstand - Et umiddelbar underordnet element i 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. (valgfritt) - Dette er en tekststreng som indikerer hvem som forårsaket feilen.
  4. (Valgfritt) - 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 som heter TutorialID i klassen GetTutorial.

Feilmeldingen nedenfor blir generert i tilfelle metoden ikke eksisterer i den definerte klassen.

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

Produksjon:

Når du kjører ovennevnte kode, vil den vise feilen som "Kunne ikke finne metode (GetTutorialID) i klassen (GetTutorial)"

SOAP-kommunikasjonsmodell

All kommunikasjon med SOAP skjer via HTTP-protokollen. Før SOAP brukte mange webtjenester standard RPC (Remote Procedure Call) -stil 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 to metoder som

  • GetEmployee - Dette vil få alle ansatte detaljer
  • SetEmployee - Dette vil angi verdien av detaljene som ansattes avd., Lønn osv. Tilsvarende .

I den vanlige RPC-stilkommunikasjonen vil klienten bare ringe metodene i sin forespørsel og sende de nødvendige parametrene til serveren, og serveren vil da sende ønsket svar.

Ovennevnte kommunikasjonsmodell har nedenstående alvorlige begrensninger

  1. Ikke språkuavhengig - Serveren som er vert for metodene vil være på et bestemt programmeringsspråk, og normalt vil samtalene til serveren kun være på det programmeringsspråket.
  2. Ikke standardprotokollen - Når du ringer til den eksterne prosedyren, utføres ikke samtalen 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 normal protokoll, må separate porter være åpne på serveren for å tillate klienten å kommunisere med serveren. Normalt vil alle brannmurer blokkere denne typen trafikk, og det var generelt nødvendig med mye konfigurasjon for å sikre at denne typen kommunikasjon mellom klienten og serveren ville fungere.

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

  1. Klienten ville formatere informasjonen om prosedyreanropet og eventuelle argumenter i 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.
  2. Serveren vil da pakke ut meldingen som ble sendt av klienten, se hva klienten ba om og deretter sende riktig svar tilbake til klienten som en SOAP-melding. Praksisen med å pakke ut en forespørsel sendt av klienten kalles Demarshalling.

Praktisk SOAP Eksempel

Nå i denne SoapUI-opplæringen, la oss se et praktisk SOAP-eksempel,

Sannsynligvis en av de beste måtene å se hvordan SOAP-meldinger blir generert, er å faktisk se en webtjeneste i aksjon.

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

ASMX-nettjenester genererer automatisk WSDL-dokumentet (Web Service Definition Language). Dette WSDL-dokumentet kreves av det anropende klientprogrammet, slik at applikasjonen vet hva nettjenesten er i stand til å gjøre.

I vårt eksempel skal vi lage en enkel webtjeneste, som vil bli brukt til å returnere en streng til applikasjonen som kaller webtjenesten.

Denne webtjenesten vil være vert i en Asp.Net-webapplikasjon. Vi påkaller deretter nettjenesten og ser resultatet som returneres av nettjenesten.

Visual Studio vil også vise oss hva SOAP-meldingen blir sendt mellom nettjenesten og anropsprogrammet.

Den første forutsetningen for å konfigurere webtjenesteapplikasjonen, som kan gjøres ved å følge trinnene nedenfor.

Forsikre deg om at du har Visual Studio 2013 installert på systemet ditt for dette eksemplet.

Trinn 1) Det første trinnet er å opprette en tom ASP.Net-webapplikasjon. Fra Visual Studio 2013 klikker du på menyvalget File-> New project.

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

Trinn 2) I dette trinnet,

  1. Forsikre deg om å først velge C # -malen til ASP.NET-webapplikasjonen. Prosjektet må være av denne typen for å kunne opprette 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 ethvert nettbasert program.
  2. Gi et navn på prosjektet ditt, som i vårt tilfelle er gitt som webservice.asmx. Sørg deretter for å gi et sted der prosjektfilene skal lagres.

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

Trinn 3) I dette trinnet,

Vi skal legge til en webtjenestefil i prosjektet vårt

  1. Høyreklikk først på prosjektfilen som vist nedenfor

  1. Når du høyreklikker på prosjektfilen, har du sjansen til å velge alternativet "Legg til-> Web Service (ASMX) for å legge til en webtjenestefil. Bare oppgi et navn på Tutorial Service for webtjenestens navnefil.

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

Kode Forklaring:

  1. Denne kodelinjen gir et navn på webtjenestefilen din. Dette er et viktig trinn fordi det gir plass for klientapplikasjonen å ringe webtjenesten via navnet på webtjenesten.
  2. Normalt brukes en klassefil til å kapsle inn funksjonaliteten til en nettjeneste. Så klassefilen vil ha definisjonen av alle nettmetodene som gir litt 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 for å legge til et [WebMethod] -attributt, sørger du for at denne metoden kan påkalles av et klientprogram. Hvis dette attributtet ikke er på plass, kan metoden aldri kalles av et klientprogram.
  4. Her definerer vi en funksjon kalt 'Guru99WebService' som skal brukes til å returnere en streng til den anropende klientprogrammet. Denne funksjonen er en webtjeneste som kan ringes av ethvert klientprogram.
  5. Vi bruker returoppgaven for å returnere strengen "Dette er en Guru99-nettjeneste" til klientapplikasjonen.

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

Produksjon:

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

Ovennevnte produksjon,

  • Det viser tydelig at strengen "This is a Guru99 Web service" returneres ved å påkalle nettmetoden.
  • Visual Studio lar deg også se SOAP-meldingsforespørselen og svaret som genereres når ovennevnte tjeneste blir ringt.

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

Kode Forklaring:

  1. 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 tilstede i hver SOAP-melding.
  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 vil kalle tjenesten som kalles 'Guru99WebService.'

string

Kode Forklaring:

  1. 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 tilstede i hver SOAP-melding.
  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 'streng'. Dette forteller klientapplikasjonen at webtjenesten som kalles returnerer et objekt av typestrengen. Dette er veldig nyttig fordi hvis klientprogrammet som ellers ikke ville vite hva nettjenesten returnerer.

Sammendrag

  • SOAP er en protokoll som brukes til å utveksle data mellom applikasjoner som er bygget på forskjellige programmeringsspråk.
  • SOAP er bygget på XML-spesifikasjonen og fungerer med HTTP-protokollen. Dette gjør det perfekt for bruk innen webapplikasjoner.
  • SOAP-byggesteinene består av en SOAP-melding. Hver SOAP-melding består av et konvoluttelement, en overskrift og et kroppselement.
  • Konvoluttelementet er det obligatoriske elementet i SOAP-meldingen og brukes til å kapsle inn alle dataene i SOAP-meldingen.
  • Overskriftselementet kan brukes til å inneholde informasjon som autentiseringsinformasjon eller definisjon av komplekse datatyper.
  • Kroppselementet er hovedelementet som inneholder definisjonen av nettmetodene sammen med eventuell parameterinformasjon.