SOAP (opprinnelig forkortelse for Simple Object Access Protocol ) er en standardprotokoll som definerer hvordan to objekter i forskjellige prosesser kan kommunisere ved å utveksle XML -data . Denne protokollen stammer fra en protokoll opprettet av Dave Winer i 1998, kalt XML-RPC . SOAP ble laget av Microsoft , IBM og andre. Det er for tiden i regi av W3C . Det er en av protokollene som brukes i webtjenester .
SOAP er et enveis statsløst meldingsparadigme , som kan brukes til å danne mer komplette og komplekse protokoller avhengig av behovene til applikasjonene som implementerer det. Den kan danne og bygge grunnlaget til en " webtjenesteprotokollstabel", og gir et grunnleggende meldingsrammeverk som webtjenester kan bygges på. Denne protokollen er basert på XML og består av tre deler:
SOAP-protokollen har tre hovedegenskaper:
Som et eksempel på hvordan SOAP-modellen kan brukes, vil vi vurdere en SOAP-melding som kan sendes til en webtjeneste for å søke etter en pris i en database, som indikerer parameterne som trengs i spørringen. Tjenesten kan returnere et dokument i XML-format med resultatet, et eksempel, priser, plassering eller egenskaper. Ved å ha svardataene i et standardisert parserbart format, kan de integreres direkte i en nettside eller ekstern applikasjon.
SOAP-arkitekturen består av flere spesifikasjonslag: MEP ( Message Exchange Patterns ) for meldingsformatet, underliggende transportprotokollbindinger, meldingsbehandlingsmodellen og protokollutvidbarhetslaget. SOAP er etterfølgeren til XML-RPC , selv om den låner transport- og interaksjonsnøytralitet, samt konvolutt / header / body , fra andre modeller (sannsynligvis fra WDDX ).
Bekymringen for distribuerte systemer og hvordan ulike maskiner kunne kommunisere med hverandre dukket opp på 1990-tallet. Inntil da var det nok at applikasjoner på samme datamaskin kunne kommunisere.
I 1990 dukket COM- og CORBA - modellene opp . Den første, Component Object Model, ble laget av Microsoft, og den andre, CORBA, av Object Management Group. Imidlertid ga disse to modellene en svært viktig vanskelighet: de var ikke lett kompatible siden de to maskinene som utførte kommunikasjonen måtte støtte COM eller CORBA, derfor kunne den bare brukes med to COM-maskiner eller to CORBA-maskiner. Senere opprettet Microsoft DCOM og Sun, RMI (Remote Method Invocation). Selv om disse metodene tillot å etablere en forbindelse mellom datamaskiner gjennom nettverket, var de heller ikke interoperable siden RMI kun er tilgjengelig for Java, og derfor er den avhengig av programmeringsspråket. Av alle disse grunnene ble Microsoft interessert i XML -basert distribuert databehandling i 1997. Målet var å få slutt på interoperabilitetsproblemene til tidligere løsninger og tillate applikasjoner å koble til via RPCer (Remote Procedure Calls), ved å bruke HTTPogXML- .
SOAP ble designet som en objekttilgangsprotokoll i 1998 av Dave Winer, Don Box, Bob Atkinson og Mohsen Al-Ghosein hos Microsoft, der Atkinson og Al-Ghosein jobbet på den tiden. SOAP-spesifikasjonen vedlikeholdes for tiden av XML Protocol Working Group til World Wide Web Consortium .
SOAP versjon 1.1 ble introdusert i år 2000 og IBM deltok i opprettelsen. Denne deltakelsen var veldig positiv siden det ble produsert betydelige og avgjørende endringer for den senere bruken: den ble designet på en mer modulær og skalerbar måte, og eliminerte problemene som stammer fra proprietær teknologi, i dette tilfellet fra Microsoft. I tillegg implementerte IBM en implementering av SOAP i Java, og SOAP ble integrert i Web Services J2EE.
SOAP sto opprinnelig for "Simple Object Access Protocol", men dette akronymet ble droppet med versjon 1.2 av standarden. Versjon 1.2 ble en W3C -anbefaling 24. juni 2003. Akronymet forveksles noen ganger med SOA , som står for tjenesteorientert arkitektur, men akronymene er ikke relatert.
Etter at SOAP først ble introdusert, ble det det underliggende laget i et mer komplekst sett med webtjenester, basert på WSDL (Web Services Description Language) og UDDI (Universal Description Discovery and Integration). Disse tjenestene, spesielt UDDI, har vist seg å være av mye mindre interesse, men en verdsettelse av dem gir en mer fullstendig forståelse av SOAPs forventede rolle sammenlignet med hvordan webtjenester i dag utvikles.
En SOAP-melding er et vanlig XML-dokument med en struktur definert i protokollspesifikasjonen. Denne strukturen består av følgende deler:
I de følgende delene av dette dokumentet kan denne strukturen sees med spesifikke eksempler.
SOAP-prosesseringsmodellen er definert som et distribuert system, der forskjellige noder griper inn. I et grunnleggende scenario kommuniserer SOAP-noder med den ene som antar rollen som SOAP-avsender og den andre rollen som SOAP- mottaker . Likevel definerer spesifikasjonen forskjellige typer noder avhengig av rollen de påtar seg i å sende meldingen:
En SOAP-node kan fungere med én eller flere roller, som hver er definert av en URI kjent som rollenavnet. Rollene påtatt av en node er invariante under sendingen av en melding, tatt i betraktning spesifikasjonen for individuell meldingsbehandling. Som nevnt kan en applikasjon lage mer komplekse kommunikasjonsprotokoller som øvre lag på toppen av SOAP, og være i stand til å definere sine egne roller for å møte sine behov.
SOAP-spesifikasjonen definerer regler for hvordan de må behandles, og definerer en rekke trinn som protokollimplementeringer må overholde. Disse trinnene finner du i avsnitt 2.6 i W3C-spesifikasjonen .
Applikasjonsutviklere i dag kan bruke Internetts e-postinfrastruktur til å overføre SOAP-meldinger enten som tekstmeldinger eller som vedlegg. Eksemplene nedenfor viser én måte å overføre SOAP-meldinger på, og bør tas som standardmåten å gjøre det på. SOAP versjon 1.2 spesifikasjoner spesifiserer ikke en slik kobling. Det er imidlertid et ikke-normativt W3C-merknad [SOAP Email Binding] som beskriver en SOAP-binding til e-post. Hovedformålet er å begynne å demonstrere anvendelsen av det generelle bindingsrammeverket med SOAP-protokollen.
Eksemplet viser meldingen om reisereservasjonsforespørsel fra eksempel 1 transportert som en e-postmelding mellom en avsendende brukeragent og en mottakende brukeragent. Det antydes at mottaksnoden har evnen til å forstå SOAP, så e-postmeldingen sendes til behandling. (Det antas at avsendernoden også kan håndtere SOAP-feil som den kan motta i svaret eller korrelere eventuelle SOAP-meldinger mottatt som svar på det).
Eksempeloverskriften er i standardformen [ RFC 2822 ] for e-postmeldinger .
Selv om e-post er en enveis utveksling av meldinger, og ingen garanti for levering er gitt, gir infrastrukturer som Simple Mail Transport Protocol ( SMTP ) spesifikasjonen en leveringsvarslingsmekanisme som, i tilfelle SMTP, kalles leveringsstatusvarsling ( DSN) og Message Disposition Notification (MDN). Disse varslene har form av e-postmeldinger sendt til e-postadressen som er angitt i overskriften på e-postmeldingen. Applikasjoner, så vel som e-postsluttbrukere, kan bruke disse mekanismene til å gi status for en e-postoverføring, men disse, hvis noen, vil være varsler på SMTP-nivå. Applikasjonsutvikleren må fullt ut forstå mulighetene og begrensningene til disse leveringsvarslene eller risikere å anta at det har vært en vellykket levering av meldingen når det kanskje ikke har vært det.
SMTP-leveringsstatusmeldinger er atskilt fra meldingsbehandling på SOAP-laget. De resulterende SOAP-svarene på SOAP-dataene vil bli returnert via en ny e-postmelding som kanskje har en kobling til den opprinnelige forespørselsmeldingen på SMTP-nivå. Bruken av overskriften In-reply-to: [In-reply-to] i henhold til [ RFC 2822 ] kan oppnå kartlegging på SMTP-nivå, men innebærer ikke nødvendigvis kartlegging på SOAP-nivå.
Som et eksempel, vises måten en klient vil be om informasjon om et produkt fra en nettjenesteleverandør på:
<soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/" > <soap:Body> <getProductDetails xmlns= "http://warehouse.example.com/ws" > <productId > 827635 </productId> </getProductDetails> </soap:Body> </soap:Envelope>Og dette vil være leverandørens svar:
<soap:Envelope xmlns:soap= "http://schemas.xmlsoap.org/soap/envelope/" > <soap:Body> <getProductDetailsResponse xmlns= "http://warehouse.example.com/ws" > <getProductDetailsResult > <productName> Toptimate 3-delt sett </productName> <productId> 827635 </productId> <description> 3-delt bagasjesett. Svart polyester. </description> <price> 96,50 </price> <inStock> true </ inStock> </getProductDetailsResult> </getProductDetailsResponse> </soap:Body> </soap:Envelope>Til tross for at det ikke var det eneste mulige alternativet, ble HTTP valgt som transportprotokoll på grunn av dens fordeler, for eksempel for å håndtere brannmurer. Andre protokoller som GIOP/IIOP eller DCOM (brukt i CORBA, RMI og DCOM) blir vanligvis frastøtt av disse brannmurene.
Den vanligste måten å bruke SOAP-protokollen på er gjennom forespørsel-svar- mønsteret med SOAP-avsender og endelig SOAP-mottaker, som brukes når SOAP-meldinger er forhåndsdefinert og du kun ønsker å sende en forespørsel og sjekke returverdien.
Imidlertid er dette mønsteret mange ganger ikke nok, og det er nødvendig å etablere en multippel utveksling av meldinger mellom nodene. W3C definerer to typer SOAP-meldingsutvekslinger for å danne en samtale:
Noen ganger er det nødvendig å bruke mellomledd i SOAP-kommunikasjon, SOAP 1.2-spesifikasjonen definerer to typer:
Alle språk som er mye brukt i utviklingen av websystemer implementerer eller inkluderer noen form for støtte for implementering av både SOAP webtjenester og klientene som bruker dem. I tillegg til biblioteker som implementerer protokollen på et grunnleggende nivå, finner vi andre som implementerer ulike bruksscenarier og etablerer enklere grensesnitt, som forenkler programmering.
Disse bibliotekene, brukt i forbindelse med utviklingsrammeverk for nettsystemer, effektiviserer utviklingsprosessen til både webtjenesten og dens klienter, spesielt hvis det genereres en WSDL-fil som kommuniserer egenskapene til tjenesten til kundene.