produktivzone
17 Normseiten, geschätzte Lesezeit 15 Min.

SOAP (auf deutsch Seife)

Was ist SOAP?

SOAP (Simple Object Access Protocol) dient der einheitlichen Beschreibung von plattformunabhängigen Systemen und Anwendungen. Es wird vorzugsweise für Webservices eingesetzt.

SOAP nutzt HTTP zur Übertragung und strukturiert die zu übermitteltenden Inhalte mit Hilfe von XML. Es beinhaltet keine neue Technologie, sondern nur Standarts.

Entstehung/Versionierung

SOAP Version 1.1 wurde entwickelt von DevelopMentor, IBM, Lotus Development Corp., Microsoft, UserLand Software. Der Hauptautor ist Don Box von DevelopMentor, einer der Autoren des XML-Manifests.

XML

Für SOAP sind zwei XML-Namensräume vorgesehen:

Der Envelope hat den namespace-identifier
"http://schemas.xmlsoap.org/soap/envelope/"

Die Serialization hat den namespace-identifier
"http://schemas.xmlsoap.org/soap/encoding/"

Eine SOAP-Nachricht darf weder eine Document Type Definition (DTD) noch Processing Instructions enthalten.

Client-Server Kommunikation

Eine SOAP-Implementation kann auf die Charakteristiken des zur Verfügung stehenden Netzwerkes abgestimmt werden, um diese optimal auszunutzen. Für die Entwicklung von Internet-Applikationen ist interessant, dass sich SOAP direkt in HTTP einbetten lässt. So kann beispielsweise in Verbindung mit dem HTTP-Protokoll eine Antwort auf eine SOAP-Nachricht auch als HTTP-Response gesendet werden.

Ganz gleich, an welches Protokoll zur Nachrichtenübermittlung SOAP gebunden ist, über einen sogenannten "Message Path" kann jede Nachricht an den auf dem Weg liegenden Knotenpunkten verarbeitet werden, bevor sie beim eigentlichen Ziel ankommt.

Eine Anwendung, die auf SOAP aufbaut, muß beim Empfangen einer SOAP-Nachricht die folgenden Aktionen ausführen:

Identifizieren aller Teile der SOAP-Nachricht, die für diese Anwendung bestimmt sind.

Sicherstellen, dass alle Teile der Nachricht, die laut Punkt 1 für diese Anwendung bestimmt sind, auch tatsächlich von der Anwendung unterstützt werden. Ist dies nicht der Fall, wird die gesamte Nachricht verworfen. Ansonsten kann die Nachricht nach den Regeln verarbeitet werden, wobei Teile, die als optional identifiziert wurden, ignoriert werden dürfen, ohne dabei das Ergebnis der Berechnungen zu verfälschen.

Falls diese Anwendung nicht der endgültige Empfänger der Nachricht ist: Entfernen aller durch Punkt 1 identifizierten Teile der Nachricht, bevor die Nachricht weitergeleitet wird.

Beispiel SOAP-Request via HTTP

Ein SOAP-Request via HTTP sieht z.B. so aus:

POST /Aktien HTTP/1.1
Host: www.aktien.de
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "MeineURI"

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Body>
    <M:HoleLetztenKurs xmlns:M="MeineURI">
      <Aktie>SUN</Aktie>
    </M:HoleLetztenKurs>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Beispiel SOAP-Response via HTTP

Und hier die darauf erfolgte Antwort:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Body>
    <M:LetzterKurs xmlns:M="MeineURI">
      <Kurs>107.0</Kurs>
    </M:LetzterKurs>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Grundstruktur

SOAP besteht im Wesentlichen aus drei Teilen: dem SOAP-Envelope, dem SOAP-Header und dem SOAP-Body, die nachfolgend beschrieben werden.

der SOAP-Envelope

Funktionalität

Das SOAP-Envelope ist das oberste Element des XML-Dokuments und umschließt die gesamte Nachricht wie ein Umschlag. Darin beschrieben ist, was in einer Nachricht enthalten ist, von wem die Nachricht wie verarbeitet werden soll, und ob einzelne Daten optional sind, oder nicht.

Syntax

Der Name des Elements lautet Envelope

Das Element muß in jeder SOAP-Nachricht enthalten sein.

Das Element darf Deklarationen von Namensräumen enthalten.

Das Element darf zusätzliche Attribute enthalten, die jedoch durch einen Namensraum qualifiziert werden müssen.

Das Element darf weitere Unterelemente enthalten, die ebenfalls durch einen Namensraum deklariert werden müssen. Sofern es sich bei ihnen nicht um Header-Elemente handelt, dürfen sie im XML-Dokument auch erst nach dem SOAP Body-Element stehen

Attribute

encodingStyle="http://www.aktien.de/encoding/ http://schemas.xmlsoap.org/soap/encoding"

enthält eine Liste von URIs mit Verweis auf Ordnungsregeln, die sog. Serialization. Das Attribut besitzt selbst keinen Default-Wert und kann mit jedem Element benutzt werden. Die Gültigkeit des Attributes bezieht sich auf alle untergeordneten Elemente, die selbst kein encodingStyle-Attribut besitzen. Die Auflistung der URIs sollte dabei vom speziellsten zum allgemeinsten Regelsatz sortiert sein.

der SOAP-Header

Funktionalität

Der SOAP-Header ist optional. Darin beschrieben sind allfällige Zusatz-Funktionen einer Anwendung, die vorher von den Anwendungen nicht abgestimmt worden sind. Die Beschreibung erfolgt über Attribute, die z.B. anwendungsspezifische Datentypen angeben/wer diese Aufgabe umsetzen soll und was davon optional ist, oder nicht. Bemerkenswert ist dabei, dass diese Erweiterungen dezentralisiert und modular und ohne vorherige Kenntnisnahme durch den Kommunikationspartner geschehen kann. Typische Anwendungsbeispiele sind unter anderem Authentifizierung und Transaktionsmanagement.

Syntax

Das Header-Element ist das erste direkte Child-Element des SOAP-Envelope-Elements.

Jeder Header-Entry wird durch sein Namen identifiziert, der aus dem Namespace-URI und dem lokalen Namen besteht.

Das encodingStyle-Attribut darf benutzt werden, um die Ordnungsregeln der Header-Entries festzulegen.

Die Attribute mustUnderstand und actor können benutzt werden, um zu beschreiben, wie ein Header-Entry verarbeitet werden soll und von wem

Attribute

actor

Eine SOAP-Nachricht kann eventuell auf dem Weg vom Sender zu dem endgültigen Empfänger noch mehrere Zwischenstationen passieren. Eine Zwischenstation ist hier eine SOAP-Anwendung, die sowohl Nachrichten empfangen und verarbeiten als auch weiterleiten kann. Beide, die Zwischenstation und der endgültige Empfänger, werden durch URIs eindeutig identifiziert.

Es kann vorkommen, das nicht alle Teile der SOAP-Nachricht für den endgültigen Empfänger bestimmt sind, sondern nur für einen oder mehrere Zwischenstationen auf dem Weg, den die Nachricht zurücklegt. Daher muss eine Zwischenstation die Teile der Nachricht, die nur für sie bestimmt sind, aus der Nachricht entfernen, bevor sie sie weiterleitet.

Um den Empfänger eines Teils der Nachricht zu identifizieren, wird das globale SOAP-actor-Attribut eingesetzt. Der aktuelle Wert des actor-Attributs ist dabei ein URI, die den Empfänger identifiziert. 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. Wird zu einem Element des SOAP-Headers kein actor-Attribut angegeben, impliziert dies, das nur der endgültige Empfänger dieser Nachricht das Element verarbeiten soll.

mustUnderstand

Mit dem mustUnderstand-Attribut wird festgelegt, ob der jeweilige Empfänger, der durch das actor-Attribut festgelegt wird, diesen Header-Entry verarbeiten muss oder die Verarbeitung optional ist. Der aktuelle Wert des mustUnderstand-Attributs kann dabei 1 oder 0 sein, wobei 0 der Default-Wert ist, der auch bei Abwesenheit des mustUnderstand- Attributs angenommen wird.

Ein mustUnderstand-Attribut mit dem aktuellen Wert 1 bedeutet für den Empfänger des so ausgezeichneten Elements, dass er entweder den Semantiken des Elements Folge zu leisten hat und das Element damit korrekt verarbeiten muss, oder andernfalls im Verarbeiten der Nachricht versagt und einen Fehler zurückgeben muss.>

Der Zweck dieses Attribut ist ein vorhersagefähiges Verhalten beim Verarbeiten von Elementen durch eine SOAP-Anwendung zu erzwingen. Es soll sichergestellt werden, dass eine Anwendung nur Elemente verarbeitet, die sie kennt, und andererseits essentiell wichtige Elemente, die für sie bestimmt, aber ihr unbekannt sind, nicht einfach ignoriert. Ein wichtiges Einsatzgebiet für das mustUnderstand-Attribut öffnet sich dort, wo mehrere Header-Entries in Beziehung miteinander stehen, und nicht ein Element ohne das andere ausgewertet werden darf.

der SOAP-Body

Funktionalität

Der SOAP-Body enthält die Informationen für den eigentlichen Empfänger der Nachricht. Darin beschrieben sind die für den Ablauf eine Anwendung notwendigen Informationen. Das Body-Element entspricht einem Header-Element mit einem mustUnderstand-Wert von 1 und dem endgültigen Empfänger der Nachricht als actor. Typische Einsatzbereiche sind z.B. Remote Procedure Calls und Fehlerdiagnose.

Syntax

Das Body-Element ist ein direktes Kindelement des SOAP-Envelope-Elements, und steht damit entweder direkt nach dem Header-Element (wenn eins vorhanden ist), oder ist das erste Kindelement des Envelope-Elements.

Ein Body-Entry wird durch seinen Elementnamen, der aus dem Namespace und dem lokalen Namen besteht, eindeutig identifiziert.

Das encodingStyle-Attribut darf benutzt werden, um die Serialization-Regeln, nach denen dieses Element kodiert wurde, festzulegen.

Im SOAP ist ein Body-Element vordefiniert, das Fault-Element, welches zur Fehlerdiagnose dienen kann

das Fault-Element

Das Fault-Element wird benutzt, um Informationen über eventuell aufgetretene Fehler in einer SOAP-Nachricht zu übermitteln. Falls es in einer Nachricht vorhanden ist, muss das Fault-Element ein Body-Entry sein und darf nur höchstens einmal in der gesamten Nachricht vorkommen. Für das Fault-Element existieren folgende Kindelemente:

faultcode: Vorgesehen, um einen eindeutigen Identifier für den aufgetretenen Fehler aufzunehmen. Das faultcode-Element muss in jedem Fault-Element vorhanden sein. SOAP bietet einige vordefinierte Werte, die das faultcode-Element annehmen kann.

faultstring: Vorgesehen, um eine durch Menschen lesbare Fehlermeldung zu liefern. Auch dieses Element muss in jedem Fault-Element vorkommen, und sollte zumindest etwas Informationen zum Verstehen des Fehlers enthalten.

faultactor: Vorgesehen, um die Fehlerquelle auf dem Weg der Nachricht zurückverfolgen zu können. Dabei wird ähnlich dem actor-Attribut im Header vorgegangen, aber anstatt den Empfänger der Nachricht identifizieren, wird die Quelle des Fehlers durch einen URI lokalisiert. SOAP-Anwendungen, die nicht der eigentliche Empfänger der Nachricht sind, müssen beim Produzieren eines Fehlers das faultactor- Element in die Fehlermeldung einfügen.

detail: Vorgesehen, um Detailinformationen über den Fehler zu übermitteln für den Fall (und nur diesen!), dass das Body-Element der SOAP-Nachricht nicht ordnungsgemäß verarbeitet werden konnte. Das detail-Element darf nicht benutzt werden, wenn beim Verarbeiten eines Header-Entries ein Fehler aufgetreten ist. Daher kann sein Vorhandensein allein schon als sicheres Zeichen genommen werden, dass der endgültige Empfänger der Nachricht das Body-Element nicht ordnungsgemäß verarbeiten konnte. Das detail-Element darf mehrere Kindelemente enthalten, die Detail-Entries genannt werden. Jeder Detail-Entry ist ein unabhängiges Element innerhalb des detail-Elements.

Vordefinierte SOAP-Fehlercodes

VersionMismatch: Der die Nachricht verarbeitende Prozeß ist auf einen ungültigen Namensraum gestoßen.

MustUnderstand: Ein Header-Entry konnte durch den Prozeß, der ihn verarbeiten sollte, nicht identifiziert werden, obwohl er einen mustUnderstand-Attributwert von 1 besaß.

Client: Das Benutzen der Client-Fehlerklasse weist darauf hin, dass die Nachricht den Empfänger in einem ungültigen Format erreicht hat oder nicht die zum Verarbeiten notwendigen Informationen enthielt.

Server: Das Benutzen der Server-Fehlerklasse weist darauf hin, dass die Nachricht aus Gründen, die nichts mit dem eigentlichen Inhalt der Nachricht selbst zu tun haben, nicht verarbeitet werden konnte

die Serialsierung

Mit De-/Serialisierung ist das Lesen und Schreiben einer SOAP-Nachricht gemeint.

Die Serialisierung von Daten erfolgt im SOAP in zwei Schritten. Zunächst muss aus dem der Anwendung zugrundeliegenden Datenmodell ein XML-Schema konstruiert werden. Danach wird aus diesem Schema und dem aktuellen Datenbestand die eigentliche XML-Datei erzeugt.

Bei der Deserialisierung wird aus der XML-Instanz unter Kenntnis des zugrundeliegenden Schemas eine Kopie des Datenbestands erstellt.

Alle Werte werden durch den Inhalt von Elementen repräsentiert. Dabei muß für jedes nicht-leere Element der Datentyp des enthaltenen Werts auf eine der folgenden Arten angegeben werden: 1) Das Element besitzt das xsi:type-Attribut, durch welches der Typ definiert wird. 2) Das Element selbst befindet sich in einem Array, dessen Typ durch das SOAP- ENC:arrayType-Attribut definiert wurde. 3) Der Name des Elements enthält einen Hinweis auf den Datentyp, der dann aus der zugrundliegenden Schemadatei entnommen werden kann.

Wird ein Element einfach ausgelassen, so impliziert dies entweder einen Default-Wert, oder, dass kein Wert bekannt ist. Normalerweise wird in diesem Fall der Null-Wert angenommen, wobei die exakte Null-Repräsentation sich nach dem Datentyp des Wertes richtet. Im Fall eines Boolschen Wertes impliziert die Abwesenheit False, im Fall eines Integers 0.

Mit Hilfe des root-Attributs können Elemente gekennzeichnet werden, welche nicht die echte Wurzel eines Objektbaumes sind. Diese Information ist nur die Deserialisierung von Belang. Das Attribut kann dabei einen der beiden Werte 0 oder 1 annehmen, wobei die echte Wurzel eines Objektbaumes einen impliziten Wert von 1 besitzt.

einfache Datentypen

In SOAP wird ein einfaches allgemeingültiges Typen-System verwendet. Werden komplexere Datentypen benötigt, müssen diese aus mehreren einfachen Datentypen konstruiert werden.

Für einfache Datentypen übernimmt SOAP alle Typen, die in der Sektion "Built-in datatypes" der XML-Schema-Spezifikation enthalten sind. Dabei handelt es sich um die folgende Typen:

string (ACHTUNG: Der Datentyp String, wie er in der XML-Schema-Spezifikation definiert wurde, ist nicht identisch mit dem aus vielen Datenbanken oder Programmiersprachen bekannten Datentyp String, da er einige Zeichen verbietet, die diese Sprachen erlauben. Solche Zeichen müssen dann alternativ repräsentiert werden, etwa durch Entities.)

boolean

float

double

decimal

timeDuration

recurringDuration

binary

uriReference

ID

IDREF

ENTITY

QName

Diese Datentypen, und von ihnen abgeleitete Typen, dürfen dann wie im folgenden Beispiel direkt in den Elementen verwendet werden:

<element name="nachname" type="string"/>
<element name="alter" type="int"/>
<element name="groesse" type="float"/>
<element name="lieblingsfarbe">
<simpleType base="xsd:string">
  <enumeration value="Rot"/>
  <enumeration value="Blau"/>
  <enumeration value="Gelb"/>
</simpleType>


Dieses Beispiel liefert folgendes Ergebnis zurück:


<nachname>Stitz</nachname>
<alter>23</alter>
<groesse>1.87</groesse>
<lieblingsfarbe>Blau</lieblingsfarbe>

Byte-Arrays

Byte-Arrays (auch Byte-String genannt) werden ähnlich einem normalen String codiert, wobei der Base64 Algorithmus aus dem RFC 2045 verwendet werden sollte. Dabei müssen jedoch die Beschränkungen, die in MIME hinsichtlich der Zeilenlänge gelten, in SOAP nicht beachtet werden. SOAP definiert einen Datentyp vor, der Base64-codierte Byte-Arrays aufnimmt: SOAP-Enc:base64. Hier ein Beispiel:

<bild xsi:type="SOAP-ENC:base64">
    aG93IG5vDyBicm73biBjb3cNCg==
</bild>

Variants

Viele Programmiersprachen unterstützen Variablen, deren Daten während der Laufzeit auf unterschiedliche Art und Weise interpretiert werden können, die Variants. Eine solche Variableninstanz muss in SOAP das xsi:type-Attribut besitzen, welches den Typ des aktuellen Werts beschreibt. Die variante Variable "preis", die einen Wert des Typs "xsd:float" enthält, würde wie folgt beschrieben werden:

<preis xsi:type="xsd:float">19.99</preis>

... wohingegen die gleiche Variable eines invarianten Typs so codiert werden kann:

<preis>19.99</preis>

Aufzählungstypen

In der XML-Schema-Deklaration wird ein Mechanismus der Aufzählung definiert, welcher vom SOAP direkt übernommen wird. Ein Element eines Aufzählungstypen, also einer Liste von möglichen Werten, wird dabei durch den Namen des Werts identifiziert. Dieses Vorgehen impliziert einen Satz einzigartiger Namen auf der einen Seite, und eine Menge von Werten, die vom gleichen Basistyp sind, auf der anderen Seite. Eine Menge von Namen, eventuell die von den gebräuchlichsten Farben, könnte beispielsweise als eine auf dem eingebauten string-Typ basierende Aufzählung definiert werden, die Werte ("1", "3", "5") sind eine mögliche Aufzählung, die auf dem integer-Typ basiert.

zusammengesetzte Datentypen

In SOAP werden zwei Arten von zusammengesetzten Datentypen definiert, Structs und Arrays. In Structs ist der Elementname die einzige Möglichkeit zur Unterscheidung von Subelementen, wobei die Elementnamen einzigartig sein müssen. In Arrays werden die einzelnen Werte durch ihre ordinale Position identifiziert.

Structs

Ein Struct, der ein Buch beschreibt, könnte etwa so aussehen:

<e:Buch>
  <autor>David Flanagan</autor>
  <titel>Java In A Nutshell</titel>
  <verlag>O Reilly</verlag>
  <preis>69.00</preis>
</e:Buch>

Dieser Datenstruktur könnte das folgende XML-Schema-Fragment zugrunde liegen:

<element name="Buch">
<complexType>
    <element name="autor" type="xsd:string"/>
    <element name="titel" type="xsd:string"/>
    <element name="verlag" type="xsd:string"/>
    <element name="preis" type="xsd:float"/>
</complexType>

Natürlich können Structs ihrerseits auch wieder Structs enthalten.

Arrays

In SOAP werden Arrays durch die Werte ihrer Element repräsentiert, wobei der Elementname bei der Identifikation keine Rolle spielt. Da Arrays eine geordnete Sequenz von Elementen beinhalten, werden einzelne Elemente durch ihre Position im Array identifiziert. Ein Array kann alle möglichen Datentypen enthalten, auch weitere Arrays:

<primzahlen SOAP-ENC:arrayType="xsd:int[2]">
  <zahl>3</zahl>
  <zahl>5</zahl>
</primzahlen>

Zu diesem Array würde das folgende Schema-Fragment passen:

<element name="primzahlen" type="SOAP-ENC:Array"/>

Eine alternative Form, dieses Array abzubilden, wäre, zu jedem Element den im SOAP-ENC-Schema vordefinierten Datentyp zu benutzen. Dabei korrespondiert dann der Elementname mit dem Datentyp:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:int[2]">
  <SOAP-ENC:int>3</SOAP-ENC:int>
  <SOAP-ENC:int>5</SOAP-ENC:int>
</SOAP-ENC:Array>

Mehrdimensionale Arrays werden wie in einigen Programmiersprachen als Strom von Elementen übermittelt:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[2,3]">
  <item>Z1S1</item>
  <item>Z1S2</item>
  <item>Z1S3</item>
  <item>Z2S1</item>
  <item>Z2S2</item>
  <item>Z2S3</item>
</SOAP-ENC:Array>

SOAP ermöglicht auch das teilweise Übertragen von Arrays. Dabei werden ab einem Offset, der durch das SOAP-ENC:offset-Attribut angegeben wird, beliebig viele Elemente übertragen. Der Offset wird notwendig, weil sonst davon ausgegangen wird, dass fehlende Elemente am Ende des Arrays liegen. Das folgende Beispiel enthält ein Array mit fünf Elementen, von denen aber nur die Elemente an den Positionen 3 und 4 übertragen werden:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[5]" SOAP-ENC:offset="[2]">
 <item>Drei</item>
 <item>Vier</item>
</SOAP-ENC:Array>

SOAP unterstützt auch das auszugsweise übertragen von dünn besetzten Arrays. Dabei wird für jedes zu übertragende Element die Position, an welcher es sich im Array befindet, durch das SOAP-ENC:position-Attribut angegeben. Im folgenden Beispiel handelt es sich um einen zweidimensionalen String-Array, in dem von hundert möglichen Feldern zwei besetzt wurden:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[10][10]">
  <item SOAP-ENC:position="[2,2]">3. Zeile, 3. Spalte</item>
  <item SOAP-ENC:position="[7,2]">8. Zeile, 3. Spalte</item>
</SOAP-ENC:Array>



Referenzen, Werte und Redundanzen

Anstatt einen Wert direkt in ein Element einzufügen kann auch auf ein anderes Element verwiesen werden, in welchem dieser Wert zu finden ist. Dabei wird ein Wert durch die ihm zugewiesene ID vom Typ "ID" (nach der XML-Spezifikation) identifiziert. Jedes Element, dass auf ein anderes verweist, ist selbst leer und besitzt ein href-Attribut vom Typ "uri-reference" (nach der XML-Schema-Spezifikation). Solche Referenzen sind auch über mehrere Ebenen möglich:


<e:Buch>
  <autor href="#pDF"/>
  <titel>Java In A Nutshell</titel>
</e:Buch>
<e:Buch>
  <autor href="#pDF"/>
  <titel>JavaScript - Das umfassende Referenzwerk</titel>
</e:Buch>
<e:Person id="pDF">
  <name>David Flanagan</name>
  <adresse href="#adrDF"/>
</e:Person>
<e:adresse id="adrDF">
  <email>mailto:DavidF@hotmail.com</email>
  <www>http://www.davidf.com</www>
</e:adresse>

Diese Methode der Referenzierung verhindert das Bilden von redundanten Daten.

SOAP und HTTP

SOAP folgt von sich aus dem HTTP Request/Response-Nachrichtenmodell, wobei SOAP- Request-Parameter in Form eines HTTP-Requests und SOAP-Response-Parameter in Form eines HTTP-Responses übermittelt werden. Natürlich sind die Zwischenstationen einer HTTP-Nachricht nicht automatisch auch die Zwischenstationen einer SOAP-Nachricht.

Als Content-Type muss laut RFC 2376 der Typ "text/xml" angegeben werden, wenn SOAP-Nachrichten per HTTP transportiert werden.

Wenn in der SOAP-Anwendung beim Verarbeiten der Nachricht ein Fehler auftritt, muss von der Anwendung mit einem HTTP 500 "Internal Server Error" geantwortet werden. Weiterhin muss die Antwort eine SOAP-Nachricht, welche das SOAP Fault-Element enthält, sein.

Das SOAPAction-Feld im HTTP-Header identifiziert den Zweck dess SOAP-HTTP-Requests. Der Wert dieses Feldes ist ein URI, der jedoch nicht auflösbar oder spezifisch formatiert sein muß. Ein HTTP-Client, der einen SOAP-Request senden will, muss dieses Header-Feld benutzen. Beispiele sind:

SOAPAction: "http://www.aktien.de/transaktion#buy"
SOAPAction: "doit.exe"
SOAPAction: ""
SOAPAction:

Das Vorhandensein und der Inhalt des SOAPAction-Feldes im HTTP-Header kann von Servern wie Firewalls benutzt werden, um SOAP-Requests zu filtern. Der Feldwert eines leeren Strings bedeutet dabei, das der Zweck des Requests aus dem HTTP-Request-URI hervorgeht (Beispiel 3). Kein Wert (Beispiel 4) bedeutet hingegen, dass es keinen Hinweis auf den Zweck der Nachricht gibt.

Sicherheit

In SOAP werden sämtliche Daten im Klartext übermittelt. Es gibt keine Regelung der Verschlüsselung oder Authentifizierung, die sicherstellen könnten, dass SOAP-Nachrichten von keinem Unbefugten gelesen werden könnten oder verhindern, das Mitgeschnittene SOAP-Requests erneut abgespielt werden. Diese Funktionen müssen entweder die zugrundeliegenden Übertragungsprotokolle vie HTTPS abdecken oder die kommunizierenden Programme.

In zukünftige Versionsen wird Sicherheit ein Thema sein.

Wo kann SOAP eingesetzt werden?

in nicht homogenen Umgebungen.

in Umgebungen, die keine hohe Performance erfordern.

in Szenarios, die keinen allzu hohen Sicherheitsbedarf mit sich bringen.

in Umgebungen, die von mehr als einer Person administriert werden.

und vor allem dort, wo unterschiedliche Systeme aus unterschiedlichen Umgebungen über das Internet kommunizieren müssen

weiterführende Links

W3C

Fachhochschule Wedel