SOAP stellt einen einfachen Mechanismus zum Austausch von strukturierter und typisierter Information zwischen kommunizierenden Rechnern in einer dezentralisierten, verteilten Umgebung zur Verfügung. Dabei soll durch SOAP kein Programmiermodell oder eine implementationsspezifische Semantik, sondern ein einfacher Mechanismus zum Beschreiben der spezifischen Semantik einer Anwendung definiert werden. Dazu werden ein modulares Paketmodell sowie Mechanismen zum Verschlüsseln und Serialisieren von Daten innerhalb von Moduln zur Verfügung gestellt. Dadurch kann SOAP in einem weiten Einsatzfeld eingesetzt werden: Von einfachen Nachrichtensystemen bis hin zu RPCs (Remote Procedure Calls). SOAP ist ein XML-basiertes Protokoll, das aus vier Teilen besteht:[Dustdar et al. 2003]
SOAP–Envelope:
Der SOAP-Envelope ist definiert um zu beschreiben, was in einer SOAP-Nachricht enthalten ist, wer sie verarbeiten soll und ob einzelne Bestandteil der SOAP-Nachrichten optional sind oder zwingend enthalten sein müssen.
SOAP–Encoding:
Das SOAP-Encoding ist eine Definition von Codier- und Serialisierungsregeln , welche Instanzen von - in der Anwendung definierten - Datentypen, beschreiben.
Das SOAP-binding-framework:
Mit dem binding-framework wird der Austausch von SOAP-Envelopes über ein zugrunde liegendes Transportprotokoll spezifiziert.
SOAP-RPC:
Definiert eine Konvention um RPCs und Response zu repräsentieren.
SOAP ist (nur) ein Netzwerkprotokoll und keine komplette verteilte Objektarchitektur.
Die SOAP-Nachricht
Eine SOAP-Nachricht besteht aus einem SOAP-Envelope, einem SOAP-Header,
und einem SOAP-Body (siehe Abb. 1). Dabei müssen die beiden Teile
SOAP-Envelope und SOAP-Body in jeder SOAP-Nachricht enthalten sein, während
der Header optional ist.
Eine SOAP-Nachricht ist wie folgt aufgebaut:
Der
SOAP-Envelope Ein Beispiel für das Envelope-Element: |
 Abbildung 1: Die Grundstruktur einer SOAP–Nachricht |
Der SOAP-Header
Der SOAP-Header stellt einen flexiblen Mechanismus zur Verfügung,
um die Funktionalitäten von SOAP zu erweitern. Der Header kann bestimmen,
wer die Nachrichten verarbeiten soll und ob der Header optional ist oder
zwingend enthalten sein muss, in dem im Header entsprechende Attribute
definiert werden.
Nicht alle Teile der SOAP-Nachricht sind für den endgültigen
Empfänger bestimmt. Manche Teile sind nur für einen oder mehrere
Zwischenstationen bestimmt. Eine Zwischenstation wird hier als eine SOAP-Anwendung
angesehen, die sowohl Nachrichten empfangen und verarbeiten als auch weiterleiten
kann. Daher muss eine Zwischenstation die Teile der Nachricht, die nur
für sie bestimmt sind, aus der Nachricht entfernen, bevor sie sie
weiterleitet. Der spezielle URI "http://schemas.xmlsoap.org/soap/actor/next"
weist darauf hin, das dieser Teil der Nachricht für die nächste
Anwendung bestimmt ist, die die Nachricht verarbeiten wird. Ohne SOAP-actor
Attribut wird nur auf den endgültigen Empfänger implizit hingewiesen,
d.h. es ist nur möglich, diese Nachricht vom endgültigen Empfänger
zu verarbeiten.
Ein Beispiel für ein Header-Element:
1. <?xml version="1.0"?>
2. <soap:Envelope
3. xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
4. soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
5. <soap:Header>
6. <m:Trans
7. xmlns:m="http://www.w3schools.com/transaction/"
8. soap:mustUnderstand="1">234</m:Trans>
9. </soap:Header>
10. ...
11. ...
12. </soap:Envelope>
SOAP-Codebeispiel 2: Header-Element
Der SOAP-Body
Das Body-Element einer SOAP-Nachricht stellt einen einfachen Mechanismus
für Austausch der Informationen, die für endgültige Empfänger
der Nachricht bestimmt sind, zur Verfügung. Typischerweise schließt
das Body-Element RPCs und eine Fehlermeldung ein. Alle direkten Subelemente
des Body-Elements werden als Body-Entries angesehen, und jeder Body-Entry
wird unabhängig voneinander innerhalb des Body-Element abgefasst.
Das Body-Elemet ist durch den Tag SOAP-ENV:Body identifiziert.
Ein Beispiel für ein Body-Element:
1. <?xml version="1.0"?>
2. <soap:Envelope
3. xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
4. soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
5. <soap:Body>
6. <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
7. <m:Item>Apples</m:Item>
8. </m:GetPrice>
9. </soap:Body>
10. </soap:Envelope>
SOAP-Codebeispiel 3: Beispiel für eine SOAP-Nachricht
SOAP und Remote Procedure Calls
SOAP stellt nicht nur einen standardisierten Weg zur Serialisierung von
Daten zur Verfügung, sondern auch einen einfachen Mechanismus, um
RPCs (Remote Procedure Calls) zu realisieren.
Eine Prozedur oder Methode wird aufgerufen, bekommt die Parameter und
liefert das Ergebnis wieder zurück. Der spezifische Unterschied zu
beispielsweise CORBA oder DCOM besteht darin, dass die Funktionsaufrufe
über reines HTTP abwickelt werden, und dass die Informationen, welche
Prozeduren auf dem entfernten Rechnern aufrufen, als SOAP-Nachrichten
verpackt werden. Bei der Verwendung des HTTP als Übertragungsprotokoll
fügt sich ein RPC in das HTTP-Request/Response-Schema ein. Dabei
wird der RPC als HTTP-Request, das Ergebnis als HTTP-Response übermittelt.
Um eine entfernte Methode oder Prozedur (RPC) aufzurufen, werden die folgenden
Informationen benötigt:
• der URI des Zielobjektes
• der Methodenname
• die Parameter der Methode
Der Name der Methodeaufrufe und die Antwort umfassen immer auch den Namensraum,
in dem sie deklariert wurden. Die Antwort bekommt im Namen noch eine zusätzliche
„Response“ angehängt.