programmera.net -> webservice -> normal     för utskrift      info@programmera.net

SOAP 1.1

1. Vad är SOAP?
2. SOAP-specifikationens huvudområden
3. Exempel på RPC i SOAP 1.1
4. SOAP Header
5. Mellanhänder i SOAP
6. Hur ett SOAP-meddelande behandlas
7.

1. Vad är SOAP?

SOAP står för "Simple Object Access Protocol" och är ett protokoll för utbyte av strukturerad information i form av XML. En mer precis definition ges nedan:

  • Def: SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between peers in a decentralized, distributed environment using XML. SOAP does not itself define any application semantics such as a programming model or implementation specific semantics; rather it defines a simple mechanism for expressing application semantics by providing a modular packaging model and encoding mechanisms for encoding data within modules. This allows SOAP to be used in a large variety of systems ranging from messaging systems to RPC.
Definitionen ovan är tagen från SOAP 1.1 specen. På denna sida kommer vi främst att diskutera SOAP 1.1, men skillnader mot SOAP 1.2 noteras i vissa fall i texten. SOAP har följande mekanismer:
  • Mekanism för att stödja RPC.
  • Mekanism för att överföra dokument.
  • Mekanism för att definiera meddelandeutbytet.
  • Mekanism för att representera data i meddelandet.
  • Mekanism för felhatering.
  • Mekanism för utökning av protokollet ("extension").
  • Mekanism för att utnyttja protokollet tillsammans med HTTP.

2. SOAP-specifikationens huvudområden

SOAP-specifikationen har följande huvudområden:

  1. SOAP envelope: Definierar hur formatet på ett SOAP-meddelande ska vara. Alltså; SOAP Body, SOAP Header, SOAP Fault o.s.v.
  2. SOAP data model: En abstrakt representation av typiska datastrukturer som är vanliga i programmeringsspråk.
  3. SOAP encoding: En mängd regler för hur datamodellen ("SOAP data model") ska beskrivas i XML.
  4. Using SOAP for RPC: Beskriver hur ett metodanrop och ett returvärde ska beskrivas i XML.
  5. SOAP protocol binding (Using SOAP in HTTP): Definierar än mängd regler som beskriver en metod för att överföra ett SOAP-meddelade från en nod till en annan.
Vi kommer att gå in på vissa av dessa områden senare på sidan. Som du ser handlar mycket av specifikationen om hur man ska underlätta RPC:
  • Fokus på RPC: "SOAP data model" och "SOAP encoding" syftar till att underlätta RPC genom att beskriva hur datatyper överförs till XML. Avsnittet "Using SOAP for RPC" beskriver hur själva metodanropet beskrivs i XML. Dessa avsnitt bildar en komplett beskrivning på hur RPC uttrycks i XML.

3. Exempel på RPC i SOAP 1.1

Nedan ser vi hur metoden "add" anropas med två parametrar: 

<?xml version = '1.0' encoding = 'UTF-8'?>
<env:Envelope 
   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"  
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:ns0="http://www.your_domain.com/ns/Calculator.xsd" 
   xmlns:ns1="http://www.your_domain.com/axis/services/Calculator">
   <env:Body>
      <ns0:add env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
         <addend1 xsi:type="xsd:int">123</addend1>
         <addend2 xsi:type="xsd:int">23</addend2>
      </ns0:add>
   </env:Body>
</env:Envelope>
Och svaret är: 

<?xml version = '1.0' encoding = 'UTF-8'?>
<soapenv:Envelope 
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Body>
      <ns1:addResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
         xmlns:ns1="http://www.your_domain.com/ns/Calculator.xsd">
           <addReturn xsi:type="xsd:int">146</addReturn>
      </ns1:addResponse>
    </soapenv:Body>
</soapenv:Envelope>
Ingen av dessa meddelandena har någon SOAP Header, men det är något vi ska titta mer på nu..

4. SOAP Header

SOAP definierar inte bara ett Body-element utan också ett Header-element. I Headern kan man lägga vilke typ av data som helst, men innehållet i Header-elementet används främst av infrastrukturen och innehållet i Body-elementet främst av applikationen. Man kan säga att dessa två användningar av Headern är vanligast:

  • Utökning av meddelandeinfrastrukturen: Headers läses och skrivs främst av infrastruktursmjukvara. Denna mjukvara kan implementera säkerhet, transaktioner, routing och liknande.
  • Ortogonala data: Med detta menar man data som är till för att läsas och skrivas av applikationen men är "ortogonal" mot bodyns data. "Ortogonal" innebär i detta fall att datat har en annan betydelse än datat i bodyn.
Ofta struntar applikationerna i vad som står i headern, men eftersom man ibland vill att applikationerna ska läsa och använda datat i headern finns det ett attribut som man kan lägga till i element som befinner sig i Headern, nämligen soapenv:mustUnderstand:
  • soapenv:mustUnderstand: Detta attribut kan anta värdet 1/0 (sant/falskt) och säger till mottagaren av meddelandet att detta element måste begripas av mottagaren, annars ska inte meddelandet tas emot.
Ett element med mustUnderstand kan se ut på följande sätt: 

<soapenv:Header>
  <xxx:my_element xmlns:xxx="http://www.xxx.com"
           soapenv:mustUnderstand="1">
     16446
  </xxx:my_element>
</soapenv:Header>

5. Mellanhänder i SOAP

Vi börjar med att definiera följande termer:

  • Mellanhänder i SOAP ("intermediaries") är applikationer som kan behandla delar av SOAP-meddelandet på vägen mot sitt slutliga mål. Mellanhänder kan både acceptera och skicka vidare SOAP-meddelanden, oftast baserat på innehållet i meddelandet.
  • Nod En server, mellanhand eller slutdestination, som kan hantera SOAP-meddelanden.
  • SOAP meddelandeväg: Vägen meddelandet tar från start till slutpunkt, inklusive eventuella mellanhänder, kallas för SOAP meddelandeväg.
Vi har tre vanliga fall då ett meddelande går via mellanhänder:
  1. mellanhand för säkerhet: För att komma till rätt slutdestination tvingas meddelandet ofta att gå via en mellanhand som har som uppgift att spärra otillåten trafik, typiskt en brandvägg.
  2. mellanhand för skalbarhet: För att implementera skalbara distribuerade system behövs ofta mellanhänder som kan buffra meddelandet på vägen mot slutdestinatonen. Här pratar vi om lastdelare och routrar.
  3. mellanhand som tillför värde: Den tredje typen av mellanhand är en mellanhand som lägger till funktionalitet till överföringen. Denna typ av mellanhänder kan ha många olika funktioner. Ett exempel är en mellanhand som krypterar meddelandet och signerar det. Ett annat exempel är en mellanhand som kopierar meddelandet till ett presistent media och adderar en nyckel till meddelandet för att sedan skicka det vidare.
Hur fungerar detta då i detalj? Jo, med SOAP 1.1 kan man lägga till attributet soapenv:actor till alla element i SOAP-Headern. Värdet på attributet soapenv:actor är en URI som definierar vem som ska hantera headern. Om en mellanhand som scannar meddelandet hittar sin egen roll kommer den att behandla meddelandet utifrån elementets innehåll. En mellanhand kan ha flera roller, alltså leta efter flera värden på actor.
  • SOAP 1.2: I SOAP 1.2 har man bytt namn på detta attribut till soapenv:role.

6. Hur ett SOAP-meddelande behandlas

När en nod får ett meddelande agerar den på detta sätt:

  1. Läser SOAP-headerns element och letar efter alla element som har (1) mustUnderstand-attributet satt och (2) actor-attributet satt till ett värde som noden identifierar sig med.
  2. Om noden inte förstår alla de utvalda headerelementen: Avbryt behandlingen av meddelandet och generera ett "env:mustUnderstood"-fel.
  3. Annars: Agerar på de utvalda headerelementen.
  4. Om noden är en mellanhand: Ta bort de utvalda headerelementen och skicka vidare meddelandet.
  5. Om noden är slutmottagare: Behandla SOAP Body-delen.

7.