edition W3C.de

SOAP-Version 1.2 Teil 0: Einführung

Deutsche Übersetzung

Diese Version:
http://poseidon.home.tlink.de/w3c/REC-soap12-part0-20030624-de_DE

Übersetzer:
Alo Clemens

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei dem Übersetzer. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Korrekturen oder Anregungen zur vorliegenden Übersetzung sind stets willkommen. Bitte mit dem Betreff "SOAP" an "w3c_trans at warpmail.net".


W3C

SOAP-Version 1.2 Teil 0: Einführung

W3C-Empfehlung 24. Juni 2003

Diese Version:
http://www.w3.org/TR/2003/REC-soap12-Teil0-20030624/
Letzte Version:
http://www.w3.org/TR/soap12-Teil0/
Vorherige Version:
http://www.w3.org/TR/2003/PR-soap12-Teil0-20030507/
Herausgeber:
Nilo Mitra (Ericsson)

Das Fehlerverzeichnis zu diesem Dokument weist auf einige normative Korrekturen hin.

Allein die englische Version dieser Übersetzung gilt als einzig normative Version. Es können weitere nicht-normative Übersetzungen vorliegen.

Copyright © 2000 W3C® (MIT, INRIA, Keio), Alle Rechte vorbehalten. Es gelten die Regeln des W3C zu HaftungWarenzeichenDokumentverwendung und Softwarelizenzierung.


Zusammenfassung

“SOAP-Version 1.2 Teil 0: Einführung” ist ein nicht-normatives Dokument, das eine einfache und verständliche Anleitung zu den Eigenschaften der Spezifikationen der SOAP-Version 1.2 bieten soll. Es beschreibt diese Eigenschaften anhand praxisorientierter Szenarien und beabsichtigt dadurch den normativen Text, siehe Teil 1 und Teil 2 der SOAP 1.2 Spezifikation, zu ergänzen.

Status dieses Dokuments

Dieser Abschnitt beschreibt den Status dieses Dokumentes zum Zeitpunkt seiner Veröffentlichung. Andere Dokumente können dieses ersetzen. Der letzte Status dieser Dokumente wird von dem W3C gepflegt.

Dieses Dokument ist eine Empfehlung des W3C. Es wurde erstellt von der XML Protocol Working Group, welche Teil der Web Services Activity ist. Dieses Dokument wurde von Mitgliedern des W3C und anderen Interessierten geprüft und vom Direktor als W3C-Empfehlung gebilligt. Es ist ein stabiles Dokument und darf als Referenzmaterial verwendet werden oder als normative Referenz von einem anderen Dokument zitiert werden. Die Absicht des W3C bei der Erstellung dieser Empfehlung ist es, auf die Spezifikation aufmerksam zu machen und ihre Verbreitung zu fördern. Dies erhöht die Funktionsfähigkeit und Interoperabilität des Webs.

Kommentare zu diesem Dokument sind erwünscht. Senden sie diese zu der öffentlichen Mailingliste xmlp-comments@w3.org (Archiv). Es ist nicht angebracht, Diskussionsbeiträge per Email an diese Adresse zu richten.

Informationen über Implementationen, die für diese Spezifikation relevant sind, können in dem Implementationsbericht http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html gefunden werden.

Patentoffenlegungen, die diese Spezifikation betreffen, können, in Konformität zu den W3C Richtlinien, auf der Seite der Arbeitsgruppe patent disclosure page gefunden werden.

Eine Liste der laufenden W3C Empfehlungen und anderen technischen Berichte können unter http://www.w3.org/TR eingesehen werden.

Inhaltsverzeichnis

1. Einführung
1.1 Übersicht
1.2 Regelungen zur Notation
2. Einfache Anwendungsfälle
2.1 SOAP-Nachrichten
2.2 SOAP-Nachrichtenaustausch
2.2.1 Dialogorientierter Nachrichtenaustausch
2.2.2 Entfernte Prozeduraufrufe (RPC)
2.3 Fehlerszenarien
3. Verarbeitungsmodell von SOAP
3.1 Das Attribut "role"
3.2 Das Attribut "mustUnderstand"
3.3 Das Attribut "relay"
4. Anwendung verschiedener Protokoll-Bindungen
4.1 SOAP-Bindung an HTTP
4.1.1 SOAP-Anwendung mittels HTTP GET
4.1.2 SOAP-Anwendung mittels HTTP POST
4.1.3 SOAP-Verwendung gemäß der Web-Struktur
4.2 SOAP mittels Email
5. Weiterführende Anwendungsfälle
5.1 Einsatz von SOAP-Zwischenstationen
5.2 Einsatz anderer Kodierungsschemen
6. Änderungen zwischen SOAP 1.1 und SOAP 1.2
7. Quellenangabe
A. Danksagungen

1. Einführung

Die “SOAP-Version 1.2 Teil 0: Einführung” ist ein nicht-normatives Dokument, das eine einfache und verständliche Anleitung zu den Eigenschaften der Spezifikation zur SOAP-Version 1.2 bietet soll. Das Ziel ist, einer technisch versierten Person verständlich darzulegen, wie SOAP angewendet werden kann. Dies erfolgt über die Beschreibung repräsentativer SOAP-Nachrichtenstrukturen und Formen des Nachrichtenaustauschs.

Insbesondere beschreibt es die Eigenschaften anhand praktischer Szenarien, mit der Absicht, den normativen Text (siehe SOAP-Version 1.2 Teil 1: Messaging Framework (nachfolgend [SOAP-Teil 1] genannt) und SOAP-Version 1.2 Teil 2: Adjuncts (nachfolgend [SOAP-Teil 2] genannt) der SOAP 1.2-Spezifikation) zu ergänzen.

Es wird vorausgesetzt, dass der Leser Kenntnisse über die wesentliche XML-Syntax besitzt, einschließlich XML Namensräumen, Information Sets und den einschlägigen Web-Konzepten wie URIs und HTTP. In erster Linie dient dieses Dokument eher SOAP-Anwendern, wie den Programmentwicklern, als denjenigen, welche die SOAP-Spezifikation implementieren, obwohl letztere durchaus einigen Nutzen daraus ziehen können. Die Einführung möchte nur essentielle Aspekte der SOAP-Version 1.2 hervorheben und nicht jedes Detail erläutern. Für ein umfassendes Verständnis von SOAP gibt es zur eigentlichen Spezifikation also keinen vergleichbaren Ersatz. Deswegen verweist diese Einführung bei neu auftretenden und angewandten Konzepten innerhalb dieser Dokumentation, auf die entsprechenden Spezifikationen.

[SOAP-Teil 1] definiert den SOAP-Envelope, der als Konstrukt ein übergeordnetes Rahmenwerk zur Darstellung des Inhalts einer SOAP-Nachricht widerspiegelt. Außerdem dient er zur Festlegung, wer sich welchen Teilen einer Nachricht widmen soll und ob eine obligatorische oder optionale Behandlung dieser Teile erfolgen muss/kann. Auch wird ein Rahmenwerk zur Protokoll-Bindung aufgestellt, das beschreibt, wie die Spezifikation einer Bindung von SOAP auf ein zugrunde liegendes Protokoll gestaltet werden muss.

[SOAP-Teil 2] definiert ein Datenmodell für SOAP, ein genaues Kodierungsschema für Datentypen, das in Verbindung mit der Übertragung von entfernten Prozeduraufrufen (RPC) genutzt werden sollte, so wie eine konkrete Ausführung des zugrunde gelegten Rahmenwerks zur Protokoll-Bindung (definiert in [SOAP-Teil 1]). Die Bindung erlaubt den Austausch von SOAP-Nachrichten als Inhalt einer HTTP POST-Anfrage und -Antwort, wie auch eine SOAP-Nachricht als Antwort einer HTTP GET-Anfrage.

Die vorliegende Einführung ist nicht normativ, was bedeutet, dass es nicht die endgültige Spezifikation der SOAP-Version 1.2 darstellt. Die Beispiele, die hier aufgeführt werden, sind als Ergänzung zur formalen Spezifikation vorgesehen, so dass bei Interpretationsfragen die formale Spezifikation maßgeblich ist. Die hier demonstrierten Beispiele spiegeln nur eine Teilmenge der möglichen Anwendungen von SOAP wider. In der Praxis wird SOAP eher Teil einer Komplettlösung sein und es ist zweifelsohne so, dass es applikationsspezifische Anforderungen gibt, die durch keines der hier vorgestellten Beispiele dargestellt werden.

1.1 Übersicht

SOAP-Version 1.2 enthält Definitionen zu XML-basierten Informationen, welche dem Austausch strukturierter und typisierter Informationen zwischen Knoten in einer dezentralisierten, verteilten Umgebung dienen können. [SOAP-Teil 1] erklärt, dass eine SOAP-Nachricht als XML Information Set [XML InfoSet] spezifiziert ist, welcher eine abstrakte Zusammenstellung seines Inhalts bereitstellt. Information Sets können verschiedene "on-the-wire"-Darstellungen haben, wie es zum Beispiel ein XML 1.0 [XML 1.0]-Dokument wäre.

Im Grunde ist SOAP ein Paradigma zum zustandslosen und "one-way" Nachrichtenaustausch. Doch können Applikationen komplexe Interaktionsformen durch die Kombination solch einseitiger Austausche schaffen, indem die Eigenschaften der darunter liegenden Protokollschicht und/oder applikationsspezifischen Informationen verwendet werden (wie zum Beispiel Anfrage/Antwort, Anfrage/multiple Antwort, usw.). SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die versendet werden, wie das Routing von SOAP-Nachrichten, der zuverlässiger Datentransfer, die Firewall-Traversierung, usw. Dennoch stellt SOAP ein Rahmenwerk zur Verfügung, welches erlaubt, dass beliebige applikationsspezifische Informationen übertragen werden können. Ebenso wartet SOAP mit einer umfangreichen Anleitung auf, wie ein SOAP-Knoten bei Ankunft einer SOAP-Nachricht zu handeln hat.

Kapitel 2 dieses Dokuments enthält eine Einführung zu den grundlegenden Eigenschaften von SOAP. Über einfache Anwendungsfälle, wie der "one-way"-SOAP-Nachricht, gefolgt von Formen diverser Anfrage-Antwort-Kommunikationen, einschließlich RPCs, soll SOAP praxisnah dargelegt werden. Ebenso wird auf Fehlersituationen eingegangen.

Kapitel 3 gibt einen Überblick über das Verarbeitungsmodell von SOAP (SOAP processing model). Es legt fest, wie die Abläufe bei der erstmaligen Erstellung einer Nachricht, bei deren Verarbeitung während der Ankunft an eine Zwischenstation oder endgültigen Empfänger und bei der Modifikation bestimmter Teilbereiche einer Nachricht, die durch Zwischenstationen erfolgen können.

Kapitel 4 beschreibt die Wege, die eine SOAP-Nachricht gehen kann, um verschiedene Anwendungsfälle realisieren zu können. Es wird die Bindung von SOAP an HTTP beschrieben, spezifiziert in [SOAP-Teil 2], und an einem Beispiel demonstriert, wie eine SOAP-Nachricht per Email versendet werden kann. Als Teil der HTTP-Bindung werden zwei Formen des Nachrichtenaustausches näher betrachtet. Eine macht von HTTP POST Gebrauch, während die andere HTTP GET nutzt. Weitere Beispiele sind ebenso auf RPCs bezogen. Also, wie RPCs, die vor allem auf “sicheren” Informationsabruf setzen, über SOAP-Nachrichten dargestellt werden und mit den strukturellen Prinzipien des World Wide Webs kompatibel sind.

Kapitel 5 dieses Dokuments behandelt verschiedene Aspekte von SOAP, die in einem komplexeren Zusammenhang genutzt werden können. Dies schließt den Erweiterungsmechanismus über die Header-Elemente ein, der bei bestimmten SOAP-Zwischenstationen zum Einsatz kommt, um einen Mehrwert für die kommunizierenden Systeme zu bieten. Außerdem widmet sich das Kapitel den verschiedenen Kodierungsschemen zur Serialisierung applikationsspezifischer Daten in SOAP-Nachrichten.

Kapitel 6 betrifft Änderungen zu [SOAP 1.1].

Kapitel 7 beinhaltet Verweise.

Aus Gründen der Bedienbarkeit sind Begriffe und Konzepte mit der Definition der jeweiligen Spezifikation verlinkt.

1.2 Regelungen zur Notation

Alle Beispiele zu SOAP-Envelopes und Nachrichten innerhalb dieser Einführung werden als [XML 1.0] Dokumente dargestellt. [SOAP-Teil 1] führt aus, dass eine SOAP-Nachricht formal als XML Information Set [XML InfoSet] spezifiziert ist, welches eine abstrakte Zusammenstellung seines Inhalts darstellt. Der Unterschied zwischen den SOAP XML Information Sets und den Dokumenten ist wahrscheinlich für diejenigen uninteressant, die vorliegendes Dokument als reine Einführung in SOAP verstehen; jene die es interessiert (normalerweise die, die SOAP über neuartige Protokoll-Bindungen nutzen möchten, um eine alternative Darstellung von Nachrichten zu schaffen), sollten die Beispiele unter Berücksichtigung des entsprechenden Information Sets nachvollziehen. Weitere Ausführungen zu diesem Punkt sind im Kapitel 4 des vorliegenden Dokuments zu finden.

Die Namensraum-Präfixe  "env", "enc" und "rpc" die in den Textabschnitten dieses Dokuments verwendet werden, sind mit den Bezeichnern der SOAP-Namensräume "http://www.w3.org/2002/12/soap-envelope" , "http://www.w3.org/2002/12/soap-encoding" und "http://www.w3.org/2002/12/soap-rpc" in Verbindung zu setzen.

Die Namensraum-Präfixe "xs" and "xsi" aus den Kapiteln dieses Dokuments, sind mit den Bezeichnern der SOAP-Namensräume "http://www.w3.org/2001/XMLSchema" und "http://www.w3.org/2001/XMLSchema-instance" in Beziehung zu setzen, wobei beide in den XML Schema-Spezifikation [XML Schema Teil 1], [XML Schema Teil 2] definiert sind.

Es bleibt anzumerken, dass die Wahl eines Namensraum-Präfix beliebig und auch semantisch nicht von Bedeutung ist.

Namensraum-URIs in der allgemeinen Form wie "http://example.org/..." und "http://example.com/..." stellen einen applikations- oder kontextabhängigen URI [RFC 2396] dar.

2. Einfache Anwendungsfälle

Eine SOAP-Nachricht ist im Grunde eine "one-way"-Übertragung zwischen SOAP-Knoten, von einem SOAP-Sender zu einem SOAP-Empfänger. Allerdings können Applikationen SOAP-Nachrichten so kombinieren, dass vielschichtigere Interaktionsformen, von einer einfachen Anfrage/Antwort-Kommunikation bis hin zum multiplen, wechselseitigen Nachrichtenaustausch, realisierbar sind.

Beginnen wir mit der Struktur einer SOAP-Nachricht und den Nachrichtenaustausch anhand einfacher Szenarien einer Applikation zur Reisereservierung. Innerhalb des vorliegenden Dokuments werden durchgängig Aspekte verwendet, die sich auf Szenarien einer Reisereservierung beziehen. Im folgenden Anwendungsfall handelt das Reservierungsprogramm für einen Firmenangestellten die geplante Dienstreise über ein Buchungssystem aus. Der Nachrichtenaustausch zwischen dem Reservierungsprogramm und dem Buchungssystem erfolgt in Form von SOAP-Nachrichten.

Den endgültige Empfänger einer SOAP-Nachricht, abgeschickt vom Reservierungsprogramm, stellt das Buchungssystem dar. Allerdings ist es möglich, dass die Nachricht über einen oder mehrere SOAP-Zwischenstationen (die in bestimmter Weise auf die Nachricht reagieren) geroutet worden ist. Einfache Beispiele für Aufgaben solcher SOAP-Zwischenstationen wären das Aufzeichnen, Mithören oder Modifizieren von Reiseanfragen. Beispiele und detaillierte Betrachtungen über die Absichten und Rollen einer SOAP-Zwischenstation sind in Kapitel 5.1 vorzufinden.

In Kapitel 2.1 wird eine Reservierungsanfrage als SOAP-Nachricht ausgedrückt. Es ermöglicht die verschiedenen "Teile" einer SOAP-Nachricht zu erläutern.

In Kapitel 2.2.1 setzt das Szenario fort, indem eine Antwort des Buchungssystems in Form einer anderen SOAP-Nachricht gezeigt wird, welche als Teil des dialogorientierten Nachrichtenaustauschs verschiedene Möglichkeiten, abgestimmt auf die Bedingungen aus der Reservierungsanfrage, aushandelt.

In Kapitel 2.2.2 setzen wir voraus, dass die verschiedenen Angaben zur Reisereservierung von dem Dienstreisenden akzeptiert worden sind und ein Austausch, modelliert als entfernter Prozeduraufruf (RPC), zwischen der Reservierungsprogramm und dem Buchungssystem die Zahlung der Reservierung bestätigt.

Kapitel 2.3 zeigt Beispiele zur Behandlung von Fehlern.

2.1 SOAP-Nachrichten

Beispiel 1 zeigt Einzelheiten zur Reservierung in Form einer SOAP-Nachricht.

Beispiel 1
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>
Dies ist ein Beispiel einer SOAP-Nachricht für eine Reisereservierung mit Header-Blöcken und einem Body

Die SOAP-Nachricht in Beispiel 1 beinhaltet zwei SOAP-spezifische Subelemente innerhalb des übergeordneten env:Envelope, den env:Header und den env:Body. Der Inhalt dieser Elemente wird durch die Anwendung bestimmt und ist nicht Teil der SOAP-Spezifikation, obwohl letztere die Behandlung dieser Elemente festlegen muss.

Ein SOAP-Header-Element (SOAP-Header) ist zwar optional, wurde aber zur Demonstration wichtiger Eigenschaften in SOAP mit aufgeführt. Der SOAP-Header ist ein Erweiterungsmechanismus, um Informationen innerhalb einer SOAP-Nachricht zu transportieren, die nichts mit der eigentlichen Nutzlast einer Anwendung zu tun haben. Diese “Kontroll”-Informationen könnten z. B. Anweisungen zur Weiterleitung oder kontextbezogene Informationen zur Bearbeitung der Nachricht sein. Das erlaubt eine Erweiterung einer SOAP-Nachricht im Sinne der Anwendung. Die direkten Subelemente vom Element env:Header, werden Header-Blöcke (header blocks) genannt und repräsentieren eine logische Gruppierung von Daten, die jeweils an bestimmte SOAP-Knoten auf dem Pfad vom Sender zum endgültigen Empfänger adressiert werden können.

SOAP-Header sind in Anlehnung verschiedenster Verwendungsformen für SOAP entwickelt worden. Viele davon nutzen Zwischenstationen, sog. SOAP intermediaries, entlang des Nachrichtenpfades vom ursprünglichen SOAP-Sender zum endgültigen SOAP-Empfänger. So fungieren SOAP-Zwischenstationen als Dienste, die einen Mehrwert schaffen. Header, wie wir später sehen werden, können von einem innerhalb des Nachrichtenpfades befindlichen SOAP-Knoten begutachtet, eingefügt, entfernt oder weitergeleitet werden. (Die SOAP-Spezifikation trifft keine Aussage zu den Inhalten der Header-Elemente, wie SOAP-Nachrichten zwischen den Knoten transportiert werden oder wie die Route generiert wird usw. Dies ist Teil der eigentlichen Anwendung und könnte auch Bestandteil anderer Spezifikationen sein.)

Der SOAP-Body (SOAP body) ist ein Pflichtelement im SOAP env:Envelope, was bedeutet, dass dort die eigentliche Information liegt, die vom ursprünglichen Sender stammt und für den endgültigen Empfänger gedacht ist.

Eine bildliche Darstellung der SOAP-Nachricht aus Beispiel 1.

Abbildung 1: Struktur einer SOAP-Nachricht

In Beispiel 1 beinhaltet der Header zwei Header-Blöcke, von denen jeder über seinen eigenen XML-Namensraum definiert wird und stellt einige Aspekte dar, die die gesamtheitliche Verarbeitung des Body der SOAP-Nachricht betrifft. Im Rahmen des Reservierungsprogramms werden diese „Metainformationen“ durch den reservation Header-Block, mit Referenz und Zeitstempel einer Reservierung und die Identität des Reisenden durch den passenger Header-Block, dargestellt.

Die Header-Blöcke reservation und passenger müssen von den nächsten innerhalb des Nachrichtenpfades auftretenden SOAP-Zwischenstationen verarbeitet werden oder, falls es keinen Vermittler gibt, von dem endgültigen Empfänger der Nachricht. Dass die Nachricht an den nächsten SOAP-Knoten der Route gerichtet ist, wird über das Attribut env:role durch den Wert "http://www.w3.org/2002/12/soap-envelope/role/next" (im Folgenden einfach nur noch "next") angegeben. Diese Rolle (role) müssen alle SOAP-Knoten verstehen. Das Auftauchen eines Attributs env:mustUnderstand mit dem Wert "true" weist darauf hin, dass die oder der Knoten die Header-Blöcke vollständig auf eine eigens für den Header-Block spezifizierten Weise verarbeitet muss. Ansonsten soll die Verarbeitung verworfen und ein Fehler (fault) generiert werden. Es gilt zu beachten, dass wann immer ein Header-Block zu verarbeiten ist, ob dieser nun über env:mustUnderstand="true" oder aus anderen Gründen gekennzeichnet ist, die Verarbeitung des Blocks stets in Anlehnung an die Spezifikation der Header-Blöcke erfolgen muss. Die Spezifikation zu jenen Header-Blöcken sind abhängig von der jeweiligen Anwendung und kein Bestandteil von SOAP. Kapitel 3 wird ausführlicher auf die SOAP-Nachrichtenverarbeitung auf Basis dieser Attribute eingehen.

Die Entscheidung, welche Daten in den Header-Block und welche in den SOAP-Body abgelegt werden sollen, ist Teil des Anwendungsdesign. Der eigentliche Punkt ist, dass Header-Blöcke an verschiedene Knoten entlang des Nachrichtenpfades vom Sender zum endgültigen Empfänger gerichtet sind. Diese vermittelnden SOAP-Knoten können einen Mehrwert auf Grundlage der Header schaffen. In Beispiel 1 sind die Daten des Reisenden in einem Header-Block platziert, um die Verwendung dieser Daten im Rahmen einer weiteren Verarbeitung bei SOAP-Zwischenstationen zu illustrieren. Wie später in Kapitel 5.1 gezeigt wird, erfolgt eine Änderung an einer ausgehenden Nachricht durch eine SOAP-Zwischenstation, damit die Reiseversicherung des Reisenden in Form weiterer Header-Blöcke hinzugefügt wird.

Das Element env:Body und die mit ihm in Verbindung stehenden Subelemente, itinerary und lodging, dienen dem Informationsaustausch zwischen dem ursprünglichen SOAP-Sender (initial SOAP sender) und dem SOAP Knoten, der die Rolle des endgültigen SOAP-Empfängers (ultimative SOAP receiver) im Nachrichtenpfad einnimmt, also das Buchungssystem. Deswegen ist env:Body und dessen Inhalt an den endgültigen Empfänger gerichtet und muss auch von jenem verstanden werden. Wie ein SOAP-Knoten eine Rolle annimmt, wird nicht über die SOAP-Spezifikation festgelegt, sondern ergibt sich aus der gesamten Semantik der Anwendung und dem ihr zugrunde liegenden Nachrichtenaustausch.

Eine SOAP-Zwischenstation könnte sich dazu entscheiden, während einer Nachrichtenübertragung die Rolle eines endgültigen SOAP-Empfänger einzunehmen und somit env:Body zu verarbeiten. Auch wenn so etwas nicht verhindert werden kann, sollte es nicht leichtfertig angewendet werden, da es die ursprüngliche Absicht des Senders verfälschen könnte und es somit zu unerwünschten Nebenwirkungen kommen kann (so werden Header-Blöcke, die für weitere Knoten entlang des Nachrichtenpfades gedacht sind, nicht verarbeitet).

Eine SOAP-Nachricht, wie jene aus Beispiel 1, könnte über verschiedenartigen Protokollen und über unterschiedliche Formen zum Nachrichtenaustausch (message exchange patterns) übertragen werden. Z. B. für einen webbasierten Zugriff auf ein Buchungssystem, könnte die SOAP-Nachricht Bestandteil des Body einer HTTP POST-Anfrage sein. Über ein anderes Protokoll könnte die Nachricht als eine Email verschickt werden (siehe Kapitel 4.2). Kapitel 4 beschreibt wie SOAP-Nachrichten über verschiedene zugrunde gelegte Protokolle versendet werden können. Vorerst wird angenommen, dass der Mechanismus zur Nachrichtenübertragung vorgegeben ist und so soll in diesem Kapitel auf die eigentliche SOAP-Nachricht und deren Verarbeitung eingegangen werden.

2.2 SOAP-Nachrichtenaustausch

SOAP-Version 1.2 ist ein einfaches Rahmenwerk für Nachrichten zur Übertragung von Informationen, spezifiziert in Form eines XML Information Sets, zwischen einem ursprünglichen SOAP-Sender und einem endgültigen SOAP-Empfänger. Das interessanteste Szenario stellt den vielfachen Austausch von Nachrichten zwischen diesen beiden Knoten dar. Der einfachste Austausch dieser Art erfolgt in Form einer Anfrage-Antwort (request-response). In den frühen Anfängen von [SOAP 1.1] wurde dafür vornehmlich die Nutzung von entfernten Prozeduraufrufen (remote procedure calls, RPC) vorgesehen. Allerdings ist darauf hinzuweisen, dass nicht alle SOAP-Anfrage-Antworten als RPCs modelliert werden können/müssen. Letzteres wird benutzt, wenn im Rahmen der Programmierung auszutauschender Nachrichten, die Struktur des entfernten Aufrufes und dessen Returnierung vordefiniert ist.

Die Anfrage-Antwort-Form ist auf bestimmte Anwendungsfälle beschränkt. Eine sehr viel größere Menge an Anwendungsfällen kann über einfache XML-basierte Dokumente zur wechselseitigen (back-and-forth) Konversation modelliert werden, wobei die Semantik auf Seiten der sendenden und empfangenden Applikation vorliegt. Kapitel 2.2.1 behandelt den dialogorientierten Austausch von XML-Dokumenten zwischen dem Reservierungsprogramm und dem Buchungssystem, während Kapitel 2.2.2 anhand eines Beispiels den Austausch mittels RPC erläutert.

2.2.1 Dialogorientierter Nachrichtenaustausch

Fortführend mit dem Anwendungsfall zur Reiseanfrage, zeigt Beispiel 2 eine SOAP-Nachricht, die von dem Buchungssystem als Antwort auf die Anfrage des Reservierungsprogramms aus Beispiel 1 generiert wird. Diese Antwort versucht die Informationen aus der Anfrage zu präzisieren, z. B. die Auswahl des Abflugortes.

Beispiel 2
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itineraryClarification
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>
<p:airportChoices>JFK LGA EWR</p:airportChoices>
</p:departing>
</p:departure>
<p:return>
<p:arriving>
<p:airportChoices>JFK LGA EWR</p:airportChoices>
</p:arriving>
</p:return>
</p:itineraryClarification>
</env:Body>
</env:Envelope>
SOAP-Nachricht als Antwort auf die Nachricht aus Beispiel 1

Wie vorhin beschrieben beinhaltet der env:Body vornehmlich den Inhalt der Nachricht, der, wie aus dem Beispiel ersichtlich, eine Auswahl an Flugplätzen bietet (in Anlehnung an das über den Namensraum http://travelcompany.example.org/reservation/travel festgelegte Schema). In diesem Beispiel werden die Header-Blöcke aus Beispiel 1 mit ihren Subelementen innerhalb der Antwort returniert. Dies erlaubt, dass Nachrichten auf SOAP-Ebene in Beziehung zueinander gesetzt werden können. Allerdings könnten diese Header auch einen anderen anwendungsspezifischen Nutzen haben.

Der Nachrichtenaustausch aus den Beispielen 1 und 2 stellt Fälle dar, wo XML-basierter Inhalt, der einem anwendungsspezifischen Schema entspricht, mittels SOAP-Nachrichten übertragen wird. Noch einmal sei auf die Erläuterung in Kapitel 4 verwiesen, wie solche Nachrichten übertragen werden sollten.

Es ist einfach zu demonstrieren, wie ein solcher Austausch zu einer multiplen back-and-forth "dialogorientierten" Form des Nachrichtenaustauschs ausgebaut werden kann. Beispiel 3 zeigt eine SOAP-Nachricht, die von dem Reisenden als Antwort auf das Beispiel 2 erfolgt, also die getroffene Auswahl verfügbarer Abflugorte. Der Header-Block reservation mit dem gleichen Wert des reference Subelements, begleitet jede Nachricht dieser Konversation und zeigt damit einen Weg auf, wie Nachrichten auf Anwendungsebene in Beziehung zueinander gesetzt werden können.

Beispiel 3
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:36:50.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>LGA</p:departing>
</p:departure>
<p:return>
<p:arriving>EWR</p:arriving>
</p:return>
</p:itinerary>
</env:Body>
</env:Envelope>
Diese Antwort auf das Beispiel 2 führt den Nachrichtenaustausch fort

2.2.2 Entfernte Prozeduraufrufe (RPC)

Ein Entwicklungsziel der SOAP-Version 1.2 ist die Einbeziehung entfernter Prozeduraufrufe, unter Anwendung der Erweiterbarkeit und Flexibilität von XML. SOAP-Teil 2 Kapitel 4 hat eine einheitliche Darstellung von RPC-Aufrufen und -Antworten definiert, die über SOAP-Nachrichten transportiert werden. In diesem Abschnitt wird zur Illustration von RPCs in SOAP-Nachrichten mit dem Anwendungsfall der Reservierung fortgefahren.

Das nächste Beispiel bezieht sich auf die Bezahlung der Reise mit der Kreditkarte. (Es wird angenommen, dass der auf den Reiseweg bezogene Nachrichtenaustausch aus Kapitel 2.2.1, positiv quittiert worden ist.) Es wird weiter angenommen, dass dies im Rahmen einer Gesamttransaktion geschieht, in der die Kreditkarte nur dann belastet wird, wenn die Reise und Unterkunft (was hier nicht demonstriert wurde, allerdings mit der vorher verdeutlichen Reservierung vergleichbar ist), bestätigt worden ist. Das Reservierungsprogramm verfügt über die Kreditkarteninformationen und ein erfolgreicher Abschluss aller Aktivitäten, führt zu einer Belastung der Karte und Returnierung eines Reservierungscodes. Die Reservierungs- und Abbuchungsinteraktion zwischen dem Reservierungsprogramm und dem Buchungssystem soll als SOAP RPC modelliert werden.

Um einen SOAP RPC aufzurufen, werden folgende Informationen benötigt:

  1. Die Adresse des SOAP-Empfängerknoten.
  2. Den Prozedur- oder Methodennamen.
  3. Die Identitäten und Werte eines jeden Arguments, dass der Methode oder Prozedur übermittelt werden muss, mit den entsprechenden Ausgabeparametern und ihren Rückgabetyp.
  4. Eine klare Abgrenzung aller Argumente, die zur Identifikation einer Webressource, die das Ziel eines RPCs darstellt, dienen. Wie jene, die Daten oder Kontrollinformationen darstellen und von der betroffenen Ressource dazu verwendet werden, um den Aufruf zu verarbeiten.
  5. Die Form des Nachrichtenaustauschs, die zur Übertragung des RPCs benutzt wird und die angewandte "Web Methode" (dazu später mehr).
  6. Optional, Daten die als Teil der SOAP-Header-Blöcke übertragen werden können.

Solche Informationen können über verschiedene Mittel ausgedrückt werden, einschließlich formeller Interface Definition Languages. SOAP stellt keine Interface Definition Language bereit, weder formell noch informell. Es muss auch berücksichtigt werden, dass die oben aufgeführten Informationen in einigen Gesichtspunkten bei Nicht-SOAP RPCs abweichen.

Unter Beachtung von Punkt 1, gibt es, aus Sicht von SOAP, einen SOAP-Knoten, der das Ziel des RPCs "umfasst" oder "unterstützt". Es ist ein SOAP-Knoten, der die Rolle eines endgültige SOAP-Empfängers einnimmt. Wie aus Punkt 1 hervorgeht, kann der endgültige Empfänger das Ziel der benannten Prozedur oder Methode über seinen URI identifizieren. Die Art und Weise, wie der betroffene URI bekannt gemacht wird, hängt von der zugrunde liegenden Protokoll-Bindung ab. Eine Möglichkeit den URI zu eruieren, ist die über den SOAP-Header. Einige Protokoll-Bindungen, wie die Bindung von SOAP an HTTP (definiert in [SOAP-Teil 2]), verfügen über einen Mechanismus, der es ermöglicht, den URI außerhalb der SOAP-Nachricht zu transportieren. Im Allgemeinen muss eines der Merkmale zur Spezifikation einer Protokoll-Bindung darlegen, wie der Ziel-URI als Teil der Bindung transportiert werden soll. In Kapitel 4.1 anhand von Beispielen erläutert, wie der URI im Rahmen der standardisierten SOAP-Protokoll-Bindung über HTTP transportiert wird.

Punkt 4 und Punkt 5 oben sind notwendig um sicherzustellen, dass RPC-Applikationen die SOAP unterstützen, dieses in Einklang mit den strukturellen Prinzipien des World Wide Webs tun. In Kapitel 4.1.3 wird erläutert, wie der Sachverhalt aus dem Punkten 4 und 5 angewandt wird.

Für den Rest dieses Kapitels wird angenommen, dass der mittels SOAP-Nachricht zu übertragene RPC aus Beispiel 4 an sein Ziel gelangt ist und verarbeitet wird. Dieser Abschnitt soll die syntaktischen Aspekte der RPC-Anfrage und -Antwort, die in einer SOAP-Nachricht transportiert werden, hervorheben.

Beispiel 4
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard
xmlns:o="http://mycompany.example.com/financial">
<n:name
xmlns:n="http://mycompany.example.com/employees">Åke Jógvan Øyvind</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation>
</env:Body>
</env:Envelope>
SOAP RPC-Anfrage mit einem obligatorischen Header und zwei Eingabe (oder “in”) Parameter.

Der RPC selbst wird über das Kindelement des env:Body Elements eingeschlossen und ist als ein struct modelliert, der den Namen der Prozedur oder Methode, in diesem Fall chargeReservation, beinhaltet. (Ein struct ist ein Konzept des SOAP Data Model, welches in [SOAP-Teil 2] definiert ist und einer Struktur oder Satzart aus Programmiersprachen entspricht.) Das Konstrukt des RPCs unseres Beispiels (dessen formelle Beschreibung nicht explizit aufgeführt wurde) beinhaltet zwei Eingabe (oder "in") -Parameter. So entspricht die reservation der geplanten Reise, die über den Inhalt des Elements code und der Information aus creditCard identifiziert wird. Letzteres ist ebenfalls ein struct, welches drei Elemente beinhaltet, den Namen des Karteninhabers name, die Kartennummer number und das Ablaufdatum über das Element expiration.

Das env:encodingStyle Attribut mit dem Wert http://www.w3.org/2003/05/soap-encoding verdeutlicht, dass der Inhalt der Struktur chargeReservation gemäß den SOAP-Kodierungsregeln serialisiert worden ist. Einzelheiten zu den Regeln sind dem SOAP-Teil 2 Kapitel 3 zu entnehmen. Auch wenn SOAP dieses bestimmte Kodierungsschema spezifiziert, kann es optional verwendet werden. Außerdem geht aus der Spezifikation hervor, dass auch andere Kodierungsschemen wegen anwendungsspezifischer Daten mit einer SOAP-Nachricht verwendet werden können. Zu diesem Zweck existiert das Attribut env:encodingStyle, um Header-Blöcke und Subelemente des Body-Teils zu qualifizieren. Die Wahl des Attributwertes ist eine anwendungsspezifische Entscheidung. Kapitel 5.2 zeigt ein Beispiel, welches ein anderes Kodierungsschema benutzt.

Wie in Punkt 6 bereits angemerkt, kann es notwendig sein, dass RPCs zusätzliche Informationen transportieren, die für die Weiterverarbeitung des Aufrufs in einer verteilten Umgebung wichtig sind. Allerdings sind diese Informationen nicht Teil der formellen Prozedur oder Methode. (Hinweis: diese zusätzlichen Informationen sind auch nicht RPC-spezifisch, aber für eine generelle Verarbeitung einer verteilten Anwendung notwendig.) Der RPC aus dem Beispiel wird im Kontext einer allumfassenden Transaktion aufgerufen und beinhaltet verschiedenste Aktivitäten, die alle erfolgreich ausgeführt werden müssen, bevor dann letztendlich der RPC einen Abschluss findet. Beispiel 4 zeigt einen an den endgültigen Empfänger (wegen des fehlenden Attributes env:role) gerichteten Header-Block transaction, der verwendet wird um solche zusätzlichen Informationen zu transportieren. (Der Wert "5" ist irgend eine TransaktionID, die für die Anwendung von Bedeutung ist. Auf weitere anwendungsbedingte Informationen kann an dieser Stelle verzichtet werden.)

Nehmen wir an, dass der RPC des Reservierungs-Beispiels so entwickelt wurde, dass zwei Ausgabe (oder "out") -Parameter returniert werden. Der erste beinhaltet eine Referenznr. für die Reservierung und der zweite einen URL, über welche Details zu der Reservierung eingesehen werden können. Die RPC Antwort liegt im Element env:Body der SOAP-Nachricht vor, welche als struct modelliert ist, bei dem sich der Prozedurname aus chargeReservation und dem Wort "Response" zusammensetzt. Die zwei Ausgabe (oder "out") -Parameter der Antwort sind alphanumerischer code für die Reservierungsnr. und einen URI, viewAt, über die detaillierte Informationen zur Reservierung empfangen werden können.

Dies wird in Beispiel 5a gezeigt, wo über den Header wieder die Transaktion identifiziert wird, unter welcher der RPC durchgeführt wird.

Beispiel 5a
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservationResponse
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:code>FT35ZBQ</m:code>
<m:viewAt>http://travelcompany.example.org/reservations?code=FT35ZBQ</m:viewAt>
</m:chargeReservationResponse>
</env:Body>
</env:Envelope>
RPC-Antwort mit zwei Ausgabe (oder "out") -Parameter zu dem Aufruf aus Beispiel 4

Die Beschreibungen zu RPCs haben oft einen bestimmten Ausgabe-Parameter gekennzeichnet, den sog. "return"-Wert. Die SOAP RPC Konvention bietet die Möglichkeit diesen "return"-Wert von den anderen Ausgabe-Parametern in der Beschreibung zur Prozedur zu unterscheiden. Um dies zu verdeutlichen, wird das Beispiel zur Reservierung so modifiziert, dass eine RPC-Beschreibung vorliegt, die zwar der aus Beispiel 5a ähnelt (gleichen zwei "out"-Parameter) aber zusätzlich einen "return"-Wert beinhaltet, welcher eine Aufzählung der Werte von "confirmed" und "pending" darstellt. Die RPC-Antwort wird in Beispiel 5b gezeigt.

Beispiel 5b
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservationResponse
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"
xmlns:m="http://travelcompany.example.org/">
<rpc:result>m:status</rpc:result>
<m:status>confirmed</m:status>
<m:code>FT35ZBQ</m:code>
<m:viewAt>http://travelcompany.example.org/reservations?code=FT35ZBQ</m:viewAt>
</m:chargeReservationResponse>
</env:Body>
</env:Envelope>
RPC-Antwort mit einem "return"-Wert und zwei "out"-Parameter zu dem Aufruf in Beispiel 4

Im Beispiel 5b wird der "return"-Wert über das Element rpc:result identifiziert und beinhaltet den XML-qualifizierten Namen (vom Typ xs:QName) eines anderen Elements in struct, dem Element m:status. Diese wiederum führt den aktuellen "return"-Wert "confirmed". Auf diese Weise ist es möglich den aktuellen "return"-Wert gemäß eines bestimmten Schemas auszugeben. Wenn kein rpc:result Element vorliegt, wie im Beispiel 5a, dann wird kein Wert returniert oder der Aufruf ist vom Typ void.

Auch wenn die Entscheidung zur Verwendung von SOAP für RPC unabhängig davon erfolgen kann, wie RPC-Aufrufe und -Antworten übertragen werden sollen, sind andere Protokoll-Bindungen, die Request-Response message exchange pattern unterstützen, besser geeignet. Derartige Protokoll-Bindungen können Anfragen und Antworten in Beziehung zueinander setzten. Natürlich kann der Entwickler einer RPC-basierten Anwendung sich dazu entscheiden, über eine Beziehungs-ID im SOAP-Header einen Aufruf mit einer Antwort in Verbindung zu stellen und damit den RPC unabhängig von dem zugrunde liegenden Transfermechanismus machen. In solch einem Fall muss sich der Entwickler im Klaren sein, dass er alle charakteristischen Eigenheiten des von ihm gewählten Protokolls zum Transport von SOAP-RPCs, wie Wartezeit, Synchronisierung, etc. zu berücksichtigen hat.

Im allgemeinen wird HTTP als zugrunde liegendes Transferprotokoll benutzt (siehe SOAP-Teil 2 Kapitel 7), so dass ein RPC-Aufruf auf eine HTTP-Anfrage abgebildet wird und eine RPC-Antwort auf eine HTTP-Antwort. Kapitel 4.1 beinhaltet einige Beispiele zum Transport von RPCs unter Verwendung der HTTP-Bindung.

Allerdings, auch wenn die meisten SOAP-Beispiele für RPC auf eine HTTP-Protokoll-Bindung setzen, so ist, wie später zu sehen wird, der Transfer damit nicht nur auf dieses eine Protokoll beschränkt.

2.3 Fehlerszenarien

SOAP gibt ein Verhaltensmodell für Situationen vor, wenn Fehler (faults) durch Verarbeitung einer Nachricht auftreten. SOAP unterscheidet zwischen den Bedingungen die in einem Fehlverhalten enden und der Fähigkeit den Absender der fehlerhaften Nachricht oder einen anderen Knoten, über den aufgetretenen Fehler in Kenntnis zu setzen. Die Möglichkeit zur Signalisierung eines Fehlers hängt von der Art des verwendeten Transportmechanismus ab und, als Aspekt der Spezifikation der zugrunde liegende Bindung von SOAP, wie, wenn überhaupt, Fehler signalisiert werden sollen. Allerdings, im vorliegenden Kapitel wird davon ausgegangen, dass der Transportmechanismus in der Lage ist, Fehler, die während der Verarbeitung empfangener Nachrichten auftreten, zu signalisieren und konzentriert sich damit auf die grundlegende Struktur einer SOAP-Fehlernachricht (SOAP fault message).

Das SOAP-Element env:Body spielt eine andere kennzeichnende Rolle, da es der Ort ist, wo Informationen zu Fehlern hinterlegt werden. Das Fehlermodell von SOAP  (SOAP fault model, siehe SOAP-Teil 1, Kapitel 2.6) verlangt, dass alle SOAP-spezifischen und anwendungsspezifischen Fehler über ein einzelnes ausgezeichnetes Element, env:Fault, wiedergegeben werden. Es ist Teil des Elements env:Body. Das Element env:Fault beinhaltet zwei obligatorische Subelemente, env:Code und env:Reason, und (optional) anwendungsspezifische Informationen über das Subelement env:Detail. Ein anderes optionales Subelement, env:Node, hält über einen URI den SOAP-Knoten fest, welcher den Fehler erzeugt hat. Liegt es nicht vor, impliziert dies, dass der endgültige Empfänger der Nachricht den Fehler generiert hat. Ein weiteres optionales Subelement, env:Role, identifiziert die Rolle, die der Knoten zum Zeitpunkt der Fehlergenerierung eingenommen hat.

Das Subelement env:Code von env:Fault untergliedert sich in das obligatorische Subelement env:Value, dessen Inhalt in der SOAP-Spezifikation (siehe SOAP-Teil 1 Kapitel 5.4.6) erläutert ist, und in einem optional zweiten Subelement env:Subcode.

Beispiel 6a zeigt eine SOAP-Nachricht, die als Antwort auf die RPC-Anfrage aus Beispiels 4 generiert wurde und einen Fehler bei der Verarbeitung des RPC angibt.

Beispiel 6a
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'>
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:BadArguments</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text
xml:lang="en-US">Processing error</env:Text>
<env:Text
xml:lang="cs">Chyba zpracování</env:Text>
</env:Reason>
<env:Detail>
<e:myFaultDetails
xmlns:e="http://travelcompany.example.org/faults">
<e:message>Name does not match card number</e:message>
<e:errorcode>999</e:errorcode>
</e:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>
SOAP-Nachricht zeigt einen Fehler bei der Verarbeitung des RPC aus Beispiel 4

In Beispiel 6a verwendet das erste env:Value einen standardisierten XML-qualifizierten Namen (vom Typ xs:QName) um zu kennzeichnen, dass es sich um einen env:Sender Fehler (fault) handelt. Es weist darauf hin, dass ein syntaktischer Fehler oder eine unzutreffende Information innerhalb der Nachricht vorliegt. (Empfängt ein Absender einen env:Sender Fehler, wird erwartet, dass eine Korrektur an der Nachricht erfolgt, bevor diese wiederholt versandt wird.) Das Element env:Subcode ist optional und qualifiziert den Fehler (siehe Beispiel). In Beispiel 6a zeigt env:Subcode an, dass ein bestimmter RPC-Fehler, rpc:BadArguments (siehe SOAP-Teil 2 Kapitel 4.4), der Grund für die fehlerhafte Weiterverarbeitung der Anfrage ist.

Die Struktur des Elements env:Subcode ist hierarchisch - jedes Kindelement env:Subcode hat ein obligatorisches Subelement env:Value und ein optionales Subelement env:Subcode - um einen anwendungsspezifischen Code übertragen zu können. Die hierarchische Struktur des Elements env:Code erlaubt einen einheitlichen Mechanismus zur Übertragung verschiedenartiger Fehlercodes. Das oberste Element env:Value stellt einen Fehler dar, der über die SOAP-Version 1.2 spezifiziert ist (siehe SOAP-Teil 1 Kapitel 5.4.6) und damit von allen SOAP-Knoten verstanden werden muss. Weiter verschachtelte env:Values sind anwendungsspezifisch und zeigen eine weitere Ausarbeitung oder Verfeinerung des grundlegenden Fehlers aus Sicht der Anwendung. Einige dieser Werte sind standardisiert, wie die RPC-Codes in SOAP 1.2 (siehe SOAP-Teil 2 Kapitel 4.4) oder jene in anderen Standards, die SOAP als Protokoll nutzen. Applikationsspezifische Subcodes müssen über einen Namensraum qualifiziert werden, der sich vom SOAP-Namensraum env unterscheidet (dieser definiert bekanntermaßen die wesentlichen Klassifikationen zu SOAP-Fehlern (SOAP faults)). SOAP fordert nicht, dass Anwendungen die Inhalte aller Ebenen des Subcodes verstehen oder sogar danach suchen müssen.

Das Subelement env:Reason ist nicht zur algorithmischen Verarbeitung gedacht, sondern zur verständlichen Fehlerbeschreibung für menschliche Anwender; also, selbst wenn es sich um ein Pflichtelement handelt, muss dort kein Wert in standardisierter Form hinterlegt werden. Es hat die alleinige Aufgabe, die Fehlersituation umgangssprachlich zu beschreiben. Außerdem muss es ein oder mehrere Subelement env:Text beinhalten, wobei jedes mit einem einmaligen Attribut xml:lang beginnt, damit es Applikationen möglich ist, die Fehlerbeschreibungen in verschiedenen Sprachen anzuzeigen. (Applikationen könnten die Sprache der Fehlerbeschreibung unter Verwendung von SOAP-Header aushandeln; allerdings fällt dies nicht in den Bereich der SOAP-Spezifikation.)

Liegt ein Subelement env:Node nicht vor, wie in Beispiel 6a bei env:Fault, bedeutet dies, dass der Fehler von dem endgültigen Empfänger generiert wurde. Der Inhalt von env:Detail aus dem Beispiel ist applikationsspezifisch.

Während eine SOAP-Nachricht verarbeitet wird, kann ein Fehler auch dann generiert werden, wenn ein Pflichtfeld im SOAP-Header nicht verstanden wird oder die enthaltenen Informationen nicht verarbeitet werden können. Solche Fehler bzgl. des Headers werden auch über das Element env:Fault innerhalb des env:Body angezeigt, aber zusätzlich mit einem besonderen Header-Block, env:NotUnderstood, der auf den fehlerhaften Header-Block verweist.

Beispiel 6b ist eine Antwort auf den RPC aus Beispiel 4 und zeigt einen Fehler bei der Verarbeitung des t:transaction Header-Blocks. Zu beachten ist der env:MustUnderstand Fehlercode in env:Body und die Kennzeichnung des nicht verstandenen Headers, über das (unqualifizierte) Attribut qname, in dem (leeren) Header-Block env:NotUnderstood.

Beispiel 6b
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope>
<env:Header>
<env:NotUnderstood qname="t:transaction"
xmlns:t="http://thirdparty.example.org/transaction"/>
</env:Header>
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:MustUnderstand</env:Value>
</env:Code>
<env:Reason>
<env:Text
xml:lang="en-US">Header not understood</env:Text>
<env:Text
xml:lang="fr">En-tête non compris</env:Text>
</env:Reason>
</env:Fault>
</env:Body>
</env:Envelope>
SOAP-Nachricht verweist auf einen Fehler im Header-Block des Beispiels 4

Sollten mehrere obligatorische Header-Blöcke nicht verstanden worden sein, dann könnte jeder einzeln über das Attribut qname durch eine Folge von env:NotUnderstood Header-Blöcken identifiziert werden.

3. Verarbeitungsmodell von SOAP

Nachdem die verschiedenen syntaktischen Gesichtspunkte einer SOAP-Nachricht, wie auch grundlegende Formen des Nachrichtenaustausches erläutert worden sind, wird im vorliegenden Kapitel auf das Verarbeitungsmodell von SOAP (SOAP processing model, spezifiziert in SOAP-Teil 1, Kapitel 2) eingegangen. Es werden die Maßnahmen beschrieben, die eintreten, wenn ein SOAP-Knoten eine SOAP-Nachricht empfängt.

Beispiel 7a zeigt eine SOAP-Nachricht mit verschiedenen Header-Blöcken, deren Inhalt der Übersicht wegen weggelassen wurde. In diesem Abschnitt werden verschiedene Variationen dieser Nachricht benutzt, um unterschiedliche Aspekte des Verarbeitungsmodells darzustellen.

Beispiel 7a
<?xml version="1.0" ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<p:oneBlock
xmlns:p="http://example.com"
env:role="http://example.com/Log">
...
...
</p:oneBlock>
<q:anotherBlock
xmlns:q="http://example.com"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
...
...
</q:anotherBlock>
<r:aThirdBlock
xmlns:r="http://example.com">
...
...
</r:aThirdBlock>
</env:Header>
<env:Body>
...
...
</env:Body>
</env:Envelope>
SOAP-Nachricht mit unterschiedlichen Header-Blöcken

Das Verarbeitungsmodell von SOAP beschreibt die (logischen) Maßnahmen, die getroffen werden, wenn ein SOAP-Knoten eine SOAP-Nachricht empfängt. Der Knoten ist dazu verpflichtet, SOAP-spezifische Teile auszuwerten, also all jene Elemente aus dem SOAP-Namensraum "env". Diese Elemente sind der Envelope selbst, die Header-Elemente und die Body-Elemente. Als erstes erfolgt eine Prüfung, ob die SOAP-Nachricht syntaktisch korrekt ist. D. h. ob sie dem SOAP-XML Information Set entspricht, gemäß der Einschränkungen unter Verwendung entsprechender XML-Konstrukte - Anweisungen zur Verarbeitung und Dokumenttyp-Definitionen - wie in SOAP-Teil 1, Kapitel 5 definiert.

3.1 Das Attribut "role"

Die weitere Verarbeitung des Header-Blocks und Body-Bereichs einer SOAP-Nachricht hängt von der/den Rolle(n) (role(s)) ab, die einem SOAP-Knoten zugewiesen ist/sind. SOAP definiert das optionale Attribut env:role - syntaktisch, xs:anyURI - welches im Header-Block vorliegen kann und die Rolle angibt, für die die Header-Blöcke bestimmt sind. Ein SOAP-Knoten muss einen Header-Block verarbeiten, wenn er die Rolle einnimmt, die über den Wert der URI angegeben ist. Wie einem SOAP-Knoten eine Rolle zuteil wird, ist nicht Gegenstand der SOAP-Spezifikation.

SOAP-Teil 1, Kapitel 2.2 definiert drei standardisierte Rollen,

Der Header-Block oneBlock aus dem Beispiel 7a, ist für all jene SOAP-Knoten bestimmt, die die applikationsspezifische Rolle mit dem URI-Wert http://example.com/Log einnehmen. Zur Veranschaulichung wird angenommen, dass die Spezifizierung für einen solchen Header-Block vorsieht, dass all die SOAP-Knoten, die diese Rolle einnehmen, die gesamte Nachricht aufzeichnen.

Jeder SOAP-Knoten, der eine Nachricht mit einem Header-Block und dem Attribut env:role mit "next" empfängt, muss fähig sein den Inhalt des Elements verarbeiten zu können, weil es sich um eine standardisierte Rolle handelt, die, wenn gefordert, von jedem SOAP-Knoten einnehmbar sein muss. Ein solcher Header-Block muss vom nächsten SOAP-Knoten innerhalb des Nachrichtenpfades geprüft und (ggf.) verarbeitet werden. Dies kann selbstverständlich nur dann erfolgen, wenn der Header durch Verarbeitung am vorherigen Knoten nicht entfernt worden ist.

Der Header-Block aus Beispiel 7a, anotherBlock, ist an den nächsten SOAP-Knoten des Nachrichtenpfades gerichtet. In diesem Fall nimmt derjenige SOAP-Knoten die SOAP-Nachricht in Empfang, der die applikationsspezifische Rolle von "http://example.com/Log" und SOAP-definierte Rolle "next" erfüllt. Letzteres gilt ebenso für den endgültigen Empfänger der Nachricht, da dieser als letzter Knoten im Nachrichtenpfad folglich eine "next"-Rolle einnimmt.

Der dritte Header-Block, aThirdBlock, aus Beispiel 7a hat kein Attribut env:role. Er ist an den SOAP-Knoten gerichtet, der die Rolle "ultimateReceiver" annimmt. Die Rolle "ultimateReceiver" (die explizit mit angegeben werden kann oder als solche impliziert wird, wenn das Attribut env:role im Header-Block nicht aufgeführt ist) wird von einem SOAP-Knoten übernommen, der die Rolle eines endgültigen Empfängers einer bestimmten Nachricht einnimmt. Dadurch, dass kein Attribut env:role im Header-Block aThirdBlock vorliegt, ist dieses Header-Element an den SOAP-Knoten gerichtet, der die Rolle "ultimateReceiver" einnimmt.

Ein Element env:Body beinhaltet kein Attribut env:role. Das Body-Element ist immer an den SOAP-Knoten gerichtet, der die Rolle "ultimateReceiver" übernimmt. In diesem Sinne ist das Body-Element nichts anderes als ein Header-Block, der für den endgültigen Empfänger bestimmt ist. Allerdings ist es gekennzeichnet, um SOAP-Knoten (vornehmlich den Zwischenstationen) zu ermöglichen diesen Teil zu überspringen, wenn ihnen nicht die Rolle eines endgültigen Empfänger zufällt. SOAP schreibt dem Element env:Body keinerlei Struktur vor, außer, dass jedes Subelement XML-Namensraum-qualifiziert sein muss. Einige Anwendungen, wie in Beispiel 1, können ihre Subelemente in env:Body über Blöcke organisieren. Dieser Aspekt betrifft aber nicht das Verarbeitungsmodell von SOAP.

Eine andere Aufgabe, die das Element env:Body übernimmt, ist die eines Sammelbehälters, in den SOAP-spezifische Fehler, wie die fehlgeschlagene Verarbeitung von SOAP-Elementen, hinterlegt werden (siehe Kapitel 2.3).

Wenn ein Header-Element das standardisierte Attribut env:role mit dem Wert "none" besitzt, bedeutet dies, dass kein SOAP-Knoten den Inhalten verarbeiten soll. Jedoch gibt es Fälle, bei denen ein Knoten diesen dennoch berücksichtigen muss, weil auf seine Daten von einem anderen zu verarbeitenden Header-Element verwiesen wird.

Sollte ein Attribut env:role einen leeren Wert haben, also env:role="", wird der relative URI zum Base-URI der betroffenen Nachricht aufgelöst. SOAP-Version 1.2 definiert zwar keinen Base-URI für SOAP-Nachrichten, verweist aber auf den in [XMLBase] definierten Mechanismus zur Herleitung der Base-URI, welcher dazu genutzt werden kann, relative URIs in absolute umzuwandeln. Ein solcher Mechanismus ist für die Protokoll-Bindung gedacht, um einen Base-URI einzurichten. Dies ist unter Bezug des Protokolls, über das SOAP-Nachrichten transportiert werden, möglich. (Wenn SOAP-Nachrichten unter Verwendung von HTTP transportiert werden, definiert SOAP-Teil 2 Kapitel 7.1.2 den Base-URI als den Anfrage-URI der HTTP-Anfrage oder des Wertes eines "HTTP Content-Location header".)

Die folgende Tabelle fasst die standardisierten Rollen zusammen, die von den verschiedenen SOAP-Knoten eingenommen werden können. ("Ja" und "Nein" bedeutet dass der betroffene Knoten entweder die angegebene Rolle einnimmt oder eben nicht)

Rolle fehlt "none" "next" "ultimateReceiver"
Knoten        
ursprünglicher Absender nicht anwendbar nicht anwendbar nicht anwendbar nicht anwendbar
Zwischenstation Nein Nein Ja Nein
endgültiger Empfänger Ja Nein Ja Ja

3.2 Das Attribut "mustUnderstand"

Beispiel 7b erweitert das vorherige Beispiel durch die Einführung eines weiteren optionalen Attributs im Header-Block, das Attribut env:mustUnderstand.

Beispiel 7b
<?xml version="1.0" ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<p:oneBlock
xmlns:p="http://example.com"
env:role="http://example.com/Log"
env:mustUnderstand="true">
...
...
</p:oneBlock>
<q:anotherBlock
xmlns:q="http://example.com"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
...
...
</q:anotherBlock>
<r:aThirdBlock
xmlns:r="http://example.com">
...
...
</r:aThirdBlock>
</env:Header>
<env:Body>
...
...
</env:Body>
</env:Envelope>
Einer der vielen verschiedenen Header-Blöcke innerhalb der SOAP-Nachricht muss verarbeitet werden.

Nachdem ein SOAP-Knoten all jene über das Attribut env:role für ihn bestimmten Header-Blöcke ermittelt hat, legt das zusätzliche Attribut env:mustUnderstand fest, welche weitere Verarbeitungsschritte vollzogen werden müssen. Um zu gewährleisten, dass SOAP-Knoten diverse Header-Blöcke, die für den Zweck der Anwendung unabdingbar sind, nicht ignorieren, sehen SOAP-Header-Blöcke ein zusätzliches optionales Attribut env:mustUnderstand vor. Sollte das Attribut den Wert "true" haben, muss der betroffene SOAP-Knoten den Block unter Berücksichtigung der Anforderungen des Blocks, verarbeitet werden. Es handelt sich um einen sog. obligatorischen Header-Block (mandatory header block). Die Verarbeitung der SOAP-Nachricht von Seiten eines Knotens darf so lange nicht erfolgen, wie nicht alle obligatorischen Header-Blöcke, die den Knoten betreffen, identifiziert und "verstanden" worden sind. Mit Verstehen ist gemeint, dass der Knoten in der Lage sein muss, alle in dem betroffenen Block festgelegten Anforderungen erfüllen zu können. (Diese Anforderungen sind nicht Bestandteil der SOAP-Spezifikation.)

In Beispiel 7b ist der Header-Block oneBlock und env:mustUnderstand mit dem Wert "true" versehen, was bedeutet, dass dieser Block zu verarbeiten ist, wenn der SOAP-Knoten die über "http://example.com/Log" identifizierte Rolle einnimmt. Die zwei anderen Header-Blöcke sind nicht als solche gekennzeichnet. Somit müssen die SOAP-Knoten, an die jene Blöcke gerichtet sind, diese nicht verarbeiten.

Ein env:mustUnderstand mit dem Wert "true" bedeutet, dass der SOAP-Knoten den Header-Block gemäß der über die Header-Spezifikation beschriebenen Semantik verarbeiten muss, da ansonsten eine SOAP-Fehlernachricht generiert wird. Ordnungsgemäß wird der Header verarbeitet, wenn er aus jeder generierten SOAP-Nachricht entfernt, er mit gleichen oder veränderten Werten wieder eingefügt oder ein neuer Header eingefügt wird. Sollte es nicht möglich sein einen obligatorischen Header-Block zu verarbeiten, entfallen weiter vorgesehene Verarbeitungsschritte und es wird eine SOAP-Fehlernachricht generiert. Außerdem wird die Nachricht nicht mehr weitergeleitet.

Das env:Body Element hat zwar kein env:mustUnderstand Attribute, allerdings muss es von dem endgültigen Empfänger verarbeitet werden. In Beispiel 7b muss der endgültige Empfänger der Nachricht – der SOAP-Knoten der die Rolle "ultimateReceiver" einnimmt – env:Body verarbeiten und kann auch den Header-Block aThirdBlock verarbeiten. Ebenso kann er den Header-Block anotherBlock verarbeiten, da dieser die Rolle von "next" einnimmt. Allerdings ist er nicht dazu verpflichtet, wenn die Spezifikation zur Verarbeitung des Blocks dies nicht vorsieht. (Sollte allerdings die Spezifikation zu anotherBlock fordern, dass dieser von dem nächsten Empfänger-Knoten verarbeitet werden muss, müsste der Block mit einem env:mustUnderstand="true" versehen werden.)

Die Rolle(n), die ein SOAP-Knoten zur Verarbeitung von SOAP-Nachrichten einnehmen, können auf unterschiedliche Weise bestimmt werden. So kann sie von vornherein bekannt sein, durch "externe" Prozeduren zugewiesen werden oder ein Knoten kann alle Bestandteile einer Nachricht untersuchen und entscheiden, welche Rollen er vor Verarbeitung der Nachricht annimmt. Eine interessante Situation tritt auf, wenn sich während der Verarbeitung herausstellt, dass der SOAP-Knoten noch weitere Rollen annehmen soll. Ganz gleich wann diese Feststellung erfolgt, nach außen hin muss es so aussehen, als ob das Verarbeitungsmodell damit umgehen kann, also als ob die Rolle schon vor Verarbeitung der Nachricht bekannt war. Es muss erscheinen, als ob die Überprüfung von env:mustUnderstand eines jeden Header mit diesen zusätzlichen Rollen zu einem Zeitpunkt erfolgt ist, wo noch keine Verarbeitung begonnen hat. Außerdem, wenn ein SOAP-Knoten solche zusätzlichen Rollen annimmt, muss er sicherstellen, dass er auf alles vorbereitet ist, was die Spezifikationen zu diesen Rollen vorsehen.

Die folgende Tabelle fasst unter Berücksichtigung der Art des Knotens (über das Attribut env:role) und des Attribut env:mustUnderstand zusammen, ob die Verarbeitung eines Header zwingend notwendig ist oder nicht.

Knoten Zwischenstation endgültiger Empfänger
mustUnderstand    
"true" muss verarbeiten muss verarbeiten
"false" kann verarbeiten kann verarbeiten
fehlt kann verarbeiten kann verarbeiten

Nach fehlgeschlagener Verarbeitung einer SOAP-Nachricht, kann der SOAP-Knoten einen einzelnen SOAP-Fehler (SOAP fault) generieren oder, abhängig von der Applikation, eine zusätzliche Nachricht, die für andere SOAP-Knoten bestimmt ist, generieren. SOAP-Teil 1 Kapitel 5.4 beschreibt den Aufbau einer Fehlernachricht, während das Verarbeitungsmodell von SOAP (SOAP processing model) festlegt, unter welchen Gegebenheiten diese generiert wird. Wie im vorherigen Kapitel 2.3 gezeigt, ist eine SOAP-Fehlernachricht eine SOAP-Nachricht mit dem standardisierten env:Body-Subelement namens env:Fault.

SOAP unterscheidet zwischen der Fehlergenerierung selbst und der Sicherstellung, dass dieser Fehler zu dem Absender der SOAP-Nachricht oder einem anderen angemessenen Knoten, dem die Information zugute kommt, returniert wird. Allerdings, ob eine generierte SOAP-Fehlernachricht weitergeleitet wird, hängt von der zugrunde liegenden Protokoll-Bindung zum Austausch von SOAP-Nachrichten ab. Die Spezifikation legt nicht fest, was passiert, wenn eine Fehlernachricht während des Versands einer "one-way"-Nachricht generiert wird. Nur die zugrunde liegende normative Protokoll-Bindung, die Bindung von SOAP an HTTP, ermöglicht eine HTTP-Antwort, um über Fehler in der angekommenen SOAP-Nachricht zu berichten. (Siehe Kapitel 4 für genauere Angaben zur SOAP Protokoll-Bindung.)

3.3 Das Attribut "relay"

SOAP-Version 1.2 sieht ein weiteres optionales Attribut im Header-Block vor, env:relay vom Typ xs:boolean, welches angibt, ob ein an eine SOAP-Zwischenstation gerichteter Header-Block weitergeleitet werden muss, sollte er nicht verarbeitet worden sein.

Es sei darauf hingewiesen, dass die Regeln zur SOAP-Verarbeitung (siehe SOAP-Teil 1 Kapitel 2.7.2) im Falle eines verarbeiteten Header-Blocks vorsehen, dass dieser aus der ausgehenden Nachricht entfernt wird. (Allerdings kann dieser wieder unverändert oder mit modifiziertem Inhalt eingefügt werden, falls die Verarbeitung anderer Header-Blöcke ergibt, dass der betroffene Header-Block der weiterzuleitenden Nachricht erhalten bleiben soll.) Das standardisierte Verhalten von SOAP-Zwischenstationen ist, dass sie diejenigen Header-Blöcke, die sie nicht verarbeiten können, vor der weiteren Übertragung aus der Nachricht entfernen.

Der Grund für dieses standardisierte Verhalten liegt in der damit einhergehenden Sicherheit, dass SOAP-Zwischenstationen sich mit dem Fortbestand eines Header-Blocks nicht weiter beschäftigen müssen, auch wenn dieser der Rolle wegen, an die Station gerichtet ist. Vor allem dann, wenn die Zwischenstation entscheidet, den Header-Block nicht zu verarbeiten, meistens deswegen weil sie ihn nicht "versteht", entfällt der Entscheidungsprozess darüber, was mit dem Block dann geschehen soll. Meist sind gewisse Header-Blöcke mit ihrer Eigenschaft nur für eine bestimmte Zwischenstrecke gedacht und es macht damit keinen Sinn, diese aus reiner Unwissenheit vom einem Ende zum anderen wandern zu lassen. Da es Fälle geben kann, bei denen eine Zwischenstation nicht in der Lage sein wird eine Entscheidung zu fällen, schein es sicherer zu sein, unverarbeitete Header-Blöcke vor der weiteren Übertragung der Nachricht zu entfernen.

Es gibt einige Fälle in denen ein Anwendungsentwickler gerne neue erweiternde Eigenschaften über einen Header-Block einführen würde, die an irgendeinen passenden Knoten des SOAP-Nachrichtenpfades gerichtet sind. Solch ein Header-Block wäre für alle Zwischenstationen verfügbar, die diesen "verstehen", andererseits aber von denen ignoriert und weitergeleitet, die ihn nicht "verstehen". Bei einer neuen Eigenschaft, muss die Software, die in der Lage ist, den entsprechenden Header-Block zu verarbeiten, zumindest anfänglich in einigen aber nicht allen SOAP-Knoten implementiert werden. Es ist zwingend erforderlich, dass die betroffenen Header-Blöcke mit env:mustUnderstand = "false" gekennzeichnet werden, so dass Zwischenstationen, die diese neue Eigenschaften nicht implementiert haben, keine Fehlernachricht generieren. Um zu verhindern, dass das standardisierte Verhalten des Verarbeitungsmodells in Kraft tritt, muss des Weiteren der Header-Block mit dem zusätzlichen Attribut env:relay (Wert "true") gekennzeichnet werden. Damit ist es den Zwischenstationen erlaubt, die an sie gerichtete Header-Blöcke weiterzuleiten, auch wenn sie einen Block nicht verarbeitet haben.

Einen Header-Block mit der Rolle "next" und dem env:relay Attribute mit dem Wert "true" versehen, sichert ab, dass jede Zwischenstation den Header untersucht, da durch die Verwendung von "next" die Informationen fortdauernd entlang des SOAP-Nachrichtenpfades transportiert werden. Natürlich ist dem Anwendungsentwickler freigestellt, eine eigene Rolle festzulegen, die erlaubt eine bestimmte Zwischenstation, die diese Rolle einnimmt, anzusprechen. In Folge dessen gibt es kein Einschränkung bei der Verwendung des env:relay Attributes mit irgendeiner anderen Rolle. Ausnahmen bilden selbstverständlich nur die Rollen "none" und "ultimateReceiver", für welche dies sowieso keine Bedeutung hat.

Beispiel 7c zeigt die Anwendung des env:relay Attributes.

Beispiel 7c
<?xml version="1.0" ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<p:oneBlock
xmlns:p="http://example.com"
env:role="http://example.com/Log"
env:mustUnderstand="true">
...
...
</p:oneBlock>
<q:anotherBlock
xmlns:q="http://example.com"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:relay="true">
...
...
</q:anotherBlock>
<r:aThirdBlock
xmlns:r="http://example.com">
...
...
</r:aThirdBlock>
</env:Header>
<env:Body>
...
...
</env:Body>
</env:Envelope>
Die SOAP-Nachricht zeigt einige Header-Blöcke, von denen einer weitergeleitet werden muss, sollte er nicht verarbeitet worden sein.

Der Header-Block q:anotherBlock, gerichtet an den "next"-Knoten des Nachrichtenpfades, hat das zusätzliche Attribut env:relay="true". Ein SOAP-Knoten, der eine solche Nachricht empfängt, kann diesen Header-Block verarbeiten, wenn er ihn denn "versteht". Ist dem so, sehen die Verarbeitungsregeln vor, dass dieser Header-Block vor der Weiterleitung der Nachricht entfernt wird. Sollte sich der SOAP-Knoten dazu entscheiden, den Block zu ignorieren, weil z. B. Bearbeitung nicht notwendig ist, da das Attribut env:mustUnderstand fehlt, muss er den Header-Block mit weiterleiten.

Die Verarbeitung des Header-Blocks p:oneBlock ist Pflicht und die Regeln zur SOAP-Verarbeitung sehen vor, dass dieser nicht weiter übertragen wird. Es sei denn, die Verarbeitung anderer Header-Blöcke ergibt, dass dieser Header-Block in der ausgehenden Nachricht vorhanden sein muss. Der letzte Header-Block r:aThirdBlock hat kein Attribut env:relay, was gleichbedeutend mit env:relay="false" ist. Daher wird dieser Header nicht weitergeleitet, wenn er nicht verarbeitet wurde.

SOAP 1.2 Teil 1 Tabelle 3 fasst die Bedingungen zusammen die vorliegen müssen, damit ein SOAP-Knoten mit einer bestimmten Rolle unverarbeitete Header-Blöcke weiterleiten darf.

4. Anwendung verschiedener Protokoll-Bindungen

SOAP-Nachrichten können auf Grundlage verschiedener Protokolle, einschließlich denen der Anwendungsschicht, ausgetauscht werden. Die Spezifikation zur Weiterleitung einer SOAP-Nachrichten (von einem SOAP-Knoten zu einem anderen) auf Basis eines zugrunde liegenden Protokolls, nennt sich SOAP-Bindung (SOAP Binding). [SOAP-Teil 1] definiert eine SOAP-Nachricht als Form eines [XML InfoSet], dass heißt, im Rahmen von Informationseinheiten für Elemente und Attribute eines abstrakten Dokuments, dem env:Envelope (siehe SOAP-Teil 1, Kapitel 5). Jede Darstellung eines SOAP-env:Envelope Information Set wird über eine Protokoll-Bindung konkretisiert, deren Aufgabe unter anderem ist, eine serialisierte Darstellung des Information Sets bereitzustellen. Das Information Set wird zum nächsten SOAP-Knoten des Nachrichtenpfades übertragen und kann dort ohne Verlust an Informationen wiederhergestellt werden. In den üblichen Beispielen von SOAP-Nachrichten und auch in den Beispielen dieser Einführung, ist die dargelegte Serialisierung, die eines wohlgeformten [XML 1.0]-Dokuments. Es gibt durchaus andere Protokoll-Bindungen - z. B. Protokoll-Bindungen zwischen zwei SOAP-Knoten mit geringer Bandbreite - wo eine alternative, komprimierte Serialisierung des gleichen Information Sets gewählt wird. Eine weitere Bindung mit anderer Absicht zielt z. B. auf eine Serialisierung mit verschlüsselter Struktur ab, die aber den gleichen Information Set darstellt.

Zusätzlich zur Realisierung eines SOAP-Information Sets zwischen benachbarten SOAP-Knoten des Nachrichtenpfades, beinhaltet die Protokoll-Bindung einen Mechanismus zur Unterstützung von Eigenschaften (features), die von SOAP-Anwendungen benötigt werden. Eine Eigenschaft ist die Spezifizierung auf eine bestimmte Funktionalität, die von einer Bindung vorgesehen wird. Eine solche Spezifizierung wird über einen URI identifiziert, so dass alle Anwendungen, die sich auf eine solche beziehen, der gleichen Semantik sicher sein können. Z. B., ein typischer Anwendungsfall bezieht sich auf den mehrfachen Austausch von Anfragen und Antworten zwischen benachbarten SOAP-Knoten. In diesem Fall wird eine Eigenschaft benötigt, die diese Anfragen und Antworten zueinander in Beziehung setzen kann. Andere Beispiele warten mit einem "Verschlüsselungskanal" auf, der Eigenschaft einer "garantierten Übertragung" oder einer besonderen Form zum SOAP-Nachrichtenaustausch (SOAP message exchange pattern feature.)

Die Spezifikation zur SOAP-Bindung (siehe SOAP-Teil 1 Kapitel 4) beschreibt unter anderem, welche Eigenschaften sie beinhaltet. Einige Eigenschaften sind bereits Teil des zugrunde liegenden Protokolls. Sollte eine bestimmte Eigenschaft nicht über die Bindung bereitstehen, kann sie über SOAP-Header-Blöcke im SOAP-Envelope realisiert werden. Die Spezifikation für eine implementierte Eigenschaft über SOAP-Header-Blöcke, wird als sog. SOAP Modul (SOAP module) bezeichnet.

Z. B., wenn der SOAP-Nachrichtenaustausch direkt über das Datagram-Protokoll UDP erfolgt, muss die Eigenschaft zur Nachrichtenkorrelation anderweitig implementiert werden, entweder direkt durch die Applikation oder eher als Bestandteil des SOAP-Information Sets, der ausgetauscht wird. Letzteres würde einen bindungsspezifischen Ausdruck in dem SOAP-Envelope notwendig, machen der Beziehungseigenschaften ausdrücken kann. Im SOAP-Header-Block würde dann ein Modul vorliegen, das für "Anfrage-Antwort-Beziehungen" über einen URI identifiziert wird. Wenn das SOAP-Information Set über ein darunter liegendes Protokoll ausgetauscht wird, das von sich aus her bereits "Anfrage-Antwort-Beziehungen" unterstützt, kann sich dies die Applikation zu Nutze machen und damit auf eine explizite Unterstützung von Seiten der Applikation oder auf SOAP-Ebene verzichten. (Die HTTP-Bindung für SOAP nutzt genau diese Eigenschaft des HTTP aus.)

Allerdings, eine SOAP-Nachricht wandert über unterschiedliche Strecken zwischen dem Sender und dem endgültigen Empfänger, wobei jede Teilstrecke eine andere Protokoll-Bindung haben kann. Mit anderen Worten, eine Eigenschaft (z. B., Nachrichtenkorrelation, Zuverlässigkeit etc.), die auf einer Teilstrecke von der Protokoll-Bindung berücksichtigt wird, könnte ggf. auf einer anderen Teilstrecke innerhalb des Nachrichtenpfades nicht mehr berücksichtigt werden. SOAP hält keinen Mechanismus bereit, der es erlauben würde, die Differenzen der Eigenschaften zugrunde liegender Protokolle zu verbergen. Allerdings, jede Eigenschaft, die von einer bestimmten Anwendung benötigt wird, aber von der zugrunde liegenden Infrastruktur entlang des erwarteten Nachrichtenpfades nicht zur Verfügung steht, kann als Teil des Information Sets einer SOAP-Nachricht ersetzt werden, also als SOAP-Header-Block definiert in Modulen.

So ist es offensichtlich, dass eine Menge von Aspekten durch den Anwendungsentwickler zunächst geklärt werden muss, um bestimmte Anforderungen an die Applikation überhaupt vollenden zu können, einschließlich wie sich Vorteile aus dem/den zugrunde liegenden Protokoll(en) der gewählten Umgebung nutzen lassen. SOAP-Teil 1 Kapitel 4.2 beinhaltet ein allgemeines Rahmenwerk, das beschreibt, wie SOAP-basierte Applikationen die Eigenschaften zugrunde liegender Protokoll-Bindungen für bestimmte Anwendungsaspekte nutzen können. Geplant ist die Aufstellung von Richtlinien für interoperable Protokoll-Bindungen zum Austausch von SOAP-Nachrichten.

Unter anderem muss eine Spezifikation zu einer Bindung eine bestimmte Eigenschaft festlegen, nämlich die Form(en) des Nachrichtenaustauschs, die sie unterstützt. [SOAP-Teil 2] definiert zwei solcher Formen zum Nachrichtenaustausch, namentlich SOAP Request-Response message exchange pattern, bei dem eine SOAP-Nachricht in jedweder Richtung zwischen zwei benachbarten SOAP-Knoten ausgetauscht wird und einer Form zum Nachrichtenaustausch einer SOAP-Antwort, dem SOAP Response message exchange pattern, dessen Anfrage aus einer Nicht-SOAP-Nachricht besteht, gefolgt von einer SOAP-Nachricht als Teil der Antwort.

[SOAP-Teil 2] bietet dem Anwendungsentwickler auch eine allgemeine Eigenschaft, das sog. "SOAP Web Method feature". Es lässt eine vollständige Kontrolle über die Wahl der "Web-Methode" ("Web method") - GET, POST, PUT, DELETE, deren Semantik in den [HTTP 1.1] Spezifikationen definiert ist - zu, welche über die jeweiligen Bindungen genutzt werden kann. Diese Eigenschaft ist festgelegt worden, um sicherzustellen, dass Anwendungen, die SOAP nutzen, dies im Einklang mit den strukturellen Grundsätzen des World Wide Web tun können. (Kurz gesagt, die Einfachheit und Skalierbarkeit des Webs basiert weitestgehend darauf, dass es ein paar "generische" Methoden gibt (GET, POST, PUT, DELETE), die dazu genutzt werden können, mit jedweder Ressource, die im Web via URI zugänglich ist, zu interagieren.) Das "SOAP Web Method feature" wird von der SOAP-Bindung an HTTP unterstützt, obgleich es prinzipiell allen SOAP-Protokoll-Bindungen zur Verfügung steht.

SOAP-Teil 2 Kapitel 7 spezifiziert eine standardisierte Protokoll-Bindung auf Grundlage des Rahmenwerks für Bindungen aus [SOAP-Teil 1], nämlich wie SOAP in Verbindung mit HTTP als zugrunde liegendes Protokoll genutzt wird. SOAP-Version 1.2 beschränkt sich bei Definition der HTTP-Bindung nur auf die Verwendung von POST (Anfrage-Antwort-Nachrichtenaustausch) und GET (SOAP-Antwort). Zukünftige Spezifikationen könnten SOAP und unterschiedliche Web Methoden (wie PUT, DELETE) mit HTTP oder anderen Protokollen berücksichtigen.

Das nächste Kapitel zeigt Beispiele zweier zugrunde liegender Protokoll-Bindungen für SOAP, nämlich [HTTP 1.1] und Email. Es sollte noch einmal hervorgehoben werden, dass die einzig normative Bindung für SOAP 1.2-Nachrichten [HTTP 1.1] ist. Die Beispiele in Kapitel 4.2, in denen Email als einfacher Transportmechanismus für SOAP-Nachrichten verwendet wird, sollen nur verdeutlichen, dass in SOAP weitere Arten des Transfers von SOAP-Nachrichten möglich sind, selbst wenn diese z. Z. noch nicht standardisiert sind. Ein W3C Note [SOAP Email Binding] zeigt die Anwendung des Rahmenwerks zur SOAP-Protokoll-Bindung aus [SOAP-Teil 1], anhand der Beschreibung einer experimentellen Bindung von SOAP per Email-Transport, ein [RFC 2822]-basierter Nachrichtentransport.

4.1 SOAP-Bindung an HTTP

Das Verbindungsmodell und die Form des Nachrichtenaustauschs von HTTP sind allgemein bekannt. Der Client identifiziert den Server per URI, verbindet sich mit diesem über das zugrunde liegende TCP/IP Netzwerk, gibt eine HTTP-Anfrage ab und empfängt eine HTTP-Antwort über die gleiche TCP-Verbindung. HTTP setzt implizit die Anfrage- mit der Antwort-Nachricht in Beziehung; deswegen kann eine Anwendung, die diese Art der Bindung nutzt, auf einen Zusammenhang zwischen einer innerhalb des Body einer HTTP-Anfrage versendeten SOAP-Nachricht und einer über eine HTTP-Antwort returnierten SOAP-Nachricht, schließen. HTTP identifiziert den Server-Endpunkt per URI, den Anfrage-URI (Request-URI), welcher gleichermaßen als Identifikation eines SOAP-Knotens in einem Server dienen kann.

HTTP berücksichtigt mehrere Stationen zwischen dem initialen Client und eigentlichen Server (origin server), der über einen Anfrage-URI identifiziert wird, so dass sich in diesem Fall das Modell zur Anfrage/Antwort als Folge solcher Paarungen darstellt. Es sei darauf hingewiesen, dass sich HTTP-Zwischenstationen von SOAP-Zwischenstationen unterscheiden.

Die HTTP-Bindung in [SOAP-Teil 2] nutzt das "SOAP Web Method feature", um Applikationen zu ermöglichen, eine sog. Web-Methode auszuwählen - z. Z. nur GET oder POST - um HTTP-Nachrichten auszutauschen. Zusätzlich stützt sie sich auf zwei verschiedene Formen des  Nachrichtenaustauschs, damit Applikationen SOAP-Nachrichten auf zweierlei Weise via HTTP austauschen können: 1) Verwendung der HTTP POST-Methode zum Versenden von SOAP-Nachrichten im Body einer HTTP-Anfrage- wie HTTP-Antwort-Nachricht und 2) Verwendung der HTTP GET-Methode bei einer HTTP-Anfrage, damit eine SOAP-Nachricht im Body einer HTTP-Antwort erfolgt. Erstgenannte Verwendungsform betrifft die HTTP-spezifische Instantiierung einer Bindungs-Eigenschaft, dem sog. SOAP request-response message exchange pattern, während zweites die Eigenschaft namens SOAP response message exchange pattern nutzt.

Beide Typen werden angeboten, da beide Interaktionsparadigmen im World Wide Web gebräuchlich sind. Der erste Interaktionstyp ermöglicht die Verwendung von Daten innerhalb des HTTP POST-Body, um den Zustand einer Ressource, die über einen URI identifiziert wird und an die die HTTP-Anfrage gerichtet ist, zu erstellen oder zu ändern. Der zweite Typ an Interaktionsmuster ermöglicht eine HTTP GET-Anfrage abzusetzen, um die Darstellung einer Ressource zu erlangen ohne ihren Zustand zu ändern. Im ersten Fall liegt im Body der HTTP POST-Anfrage eine SOAP-Nachricht vor, die anwendungsseitig verarbeitet werden muss (auf Grundlage des Verarbeitungsmodells von SOAP) und dies gemäß der POST-Semantik. Im zweiten Fall, sieht die typische Anwendung so aus, dass die angefragte Darstellung einer Ressource, nicht als HTML oder in Form eines generischen XML-Dokuments vorliegt, sondern als eine SOAP-Nachricht. Dass heißt, dass der "HTTP content type header" der Antwortnachricht mit "application/soap+xml" gekennzeichnet ist. Wahrscheinlich gibt es Ressourcen im Web, deren Verantwortliche bestimmt haben, dass diese Ressourcen in Form von SOAP-Nachrichten am besten zugänglich sind. Es sei angemerkt, dass Ressourcen in vielen unterschiedlichen Darstellungsarten vorliegen können und die bevorzugte Darstellungsart von der anfragenden Applikation über den HTTP Accept-Header bestimmt wird.

Eine weitere Frage zur SOAP-Bindung an HTTP lautet, wie eine Applikation festlegt, welche der zwei Formen zum Nachrichtenaustausch verwendet werden soll. [SOAP-Teil 2] bietet eine Orientierungshilfe, unter welchen Umständen Applikationen eine der beiden Formen verwenden können. (Die richtungweisende Orientierungshilfe wird in den Spezifikationen eher in Form von "SHOULD", als in Form eines zwingend notwendigen "MUST" ausgedrückt. Beide Wörter sind gemäß der IETF [RFC 2119] zu interpretieren.) Die Form des Nachrichtenaustauschs per HTTP GET-Methode wird angewendet, wenn eine Applikation sicher ist, dass der Nachrichtenaustausch dem Empfang reiner Informationen dient, wobei die Informationsressource am Ende der Interaktion damit "unberührt" bleibt. Solche Interaktionen werden in den HTTP-Spezifikationen als sicher und idempotent (safe and idempotent ) bezeichnet. Da die Verwendung von HTTP SOAP-GET keine SOAP-Nachricht in der Anfrage ermöglicht, können Applikationen, die Eigenschaften in einer ausgehenden Nachricht benötigen, welche nur über einen spezifischen Bindungausdruck innerhalb des SOAP-Information Sets vorliegen können (nämlich als SOAP-Header-Block), diese Form des Nachrichtenaustauschs nicht verwenden. Die HTTP POST-Bindung hingegen, kann in allen Fällen angewandt werden.

Die folgenden Absätze beinhalten Beispiele für beide Formen des Nachrichtenaustauschs unter Verwendung der HTTP-Bindung.

4.1.1. SOAP-Anwendung mittels HTTP GET

Die Verwendung der HTTP-Bindung mit dem SOAP Response message exchange pattern beschränkt sich auf die HTTP GET-Methode. So ist die Antwort auf die HTTP GET-Anfrage eines anfragenden SOAP-Knotens eine SOAP-Nachricht in einer HTTP-Antwort.

Beispiel 8a zeigt ein HTTP GET von Seiten des Reservierungsprogramms des Reisenden (fortgesetztes Reisebuchungsszenario) an den URI http://travelcompany.example.org/reservations?code=FT35ZBQ, wo Informationen zur Reise eingesehen werden können. (Wie dieser URL verfügbar wird, ist in Beispiel 5a zu sehen.)

Beispiel 8a
GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: text/html;q=0.5, application/soap+xml
HTTP GET-Anfrage

Der HTTP-Accept-Header wird dazu verwendet, um anzugeben, welche Darstellungsart der angefragten Ressource bevorzugt wird. Im vorliegenden Beispiel wird der Typ "application/soap+xml" für einen maschinellen Client eher präferiert, als eine für den Browser bestimmte "text/html"-Darstellungsart, die für den Menschen in lesbarer Form wiedergegeben wird.

Beispiel 8b zeigt die HTTP-Antwort zum GET des Beispiels 8a. Die HTTP-Antwort beinhaltet eine SOAP-Nachricht, die die Reisedetails zeigt. Eine Erörterung zum Inhalt der SOAP-Nachricht erfolgt erst in Kapitel 5.2, da dies zum Verständnis der Anwendung der HTTP GET-Bindung nicht notwendig ist.

Beispiel 8b
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
</m:reservation>
</env:Header>
<env:Body>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://travelcompany.example.org/vocab#"
env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<x:ReservationRequest
rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
<x:passenger>Åke Jógvan Øyvind</x:passenger>
<x:outbound>
<x:TravelRequest>
<x:to>LAX</x:to>
<x:from>LGA</x:from>
<x:date>2001-12-14</x:date>
</x:TravelRequest>
</x:outbound>
<x:return>
<x:TravelRequest>
<x:to>JFK</x:to>
<x:from>LAX</x:from>
<x:date>2001-12-20</x:date>
</x:TravelRequest>
</x:return>
</x:ReservationRequest>
</rdf:RDF>
</env:Body>
</env:Envelope>
Returnierte SOAP-Nachricht als Antwort auf die HTTP GET-Anfrage in Beispiel 8a

Ohne weiteres hätten die Reservierungsdetails genauso gut als (X)HTML-Dokument verschickt werden können, aber in diesem Beispiel soll der Fall gezeigt werden, in dem das Reservierungsprogramm den Zustand der Ressource (der Reservierung) in einer datenbezogenen Form (als SOAP-Nachricht) wiedergibt, die von einer Maschine verarbeitet werden kann, anstatt (X)HTML, welches von einem Browser verarbeitet wird. Tatsächlich würde in den meisten Fällen zu SOAP, die verarbeitende Applikation kein Browser sein.

Wie in dem Beispiel zu sehen ist, ermöglicht die Verwendung von SOAP in der HTTP-Antwort, anwendungsspezifische Eigenschaften über die SOAP-Header anzulegen. Durch die Anwendung von SOAP wird eine Applikation durch ein sinnvolles und einheitliches Rahmenwerk, wie auch Verarbeitungsmodell unterstützt, um solche Eigenschaften auszudrücken.

4.1.2 SOAP-Anwendung mittels HTTP POST

Die Anwendung der HTTP-Bindung mit dem SOAP Request-Response message exchange pattern beschränkt sich auf die HTTP POST-Methode. Dieses Verfahren zum Austausch von Nachrichten mittels SOAP-Bindung über HTTP ist für alle Applikationen verwendbar, ganz gleich ob sie die in SOAP-Nachrichten eingeschlossenen XML-Daten oder RPCs (wie in folgendem Beispiel) austauschen.

9 und 10 zeigen Beispiele einer HTTP-Bindung unter Verwendung eines Kommunikationsverfahrens zur SOAP-Anfrage-Antwort. Es nutzt das gleiche Szenario wie aus Beispiel 4 und Beispiel 5a, allerdings wird ein RPC übermittelt und ein RPC innerhalb des Bodys einer SOAP-Nachricht returniert. Das Beispiel und die Erläuterung innerhalb des vorliegenden Kapitels beziehen sich nur auf den HTTP-Header und dessen Aufgabe.

Beispiel 9
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard
xmlns:o="http://mycompany.example.com/financial">
<n:name
xmlns:n="http://mycompany.example.com/employees">Åke Jógvan Øyvind</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation>
</env:Body>
</env:Envelope>
RPC aus Beispiel 4 innerhalb einer HTTP POST-Anfrage

Beispiel 9 zeigt eine RPC-Anfrage, die an das Reisebuchungssystem gerichtet ist. Die SOAP-Nachricht wird über den Body der HTTP POST-Methode versendet und verweist über den URI auf die Ressource "Reservations" des Servers travelcompany.example.org. Wenn HTTP verwendet wird, identifiziert der Anfrage-URI die Ressource, an die der Aufruf gerichtet ist. Außer dass der URI valide sein muss, stellt SOAP keine formellen Bedingungen an den Anfrage-URI (siehe [RFC 2396] für mehr Informationen zu URIs). Dennoch, einer der Grundsätze der Web-Struktur ist, dass alle bedeutsamen Ressourcen über URIs identifiziert werden. Dies bedeutet, dass die meisten der SOAP-Dienste eine riesige Anzahl an Ressourcen darstellen, wobei jeder seinen eigenen URI zugewiesen bekommt. Viele dieser Ressourcen werden aber nur vorübergehend während irgendeiner Aktion eines Dienstes erstellt, wie die im Beispiel gezeigte Reisereservierung. Deswegen würde eine sinnvoll entwickelte Reiseapplikation jeweils eine URIs für jede einzelne Reservierung vorsehen und nicht mit eine einzige monolithische "Reservierungs"-URI, wie in Beispiel 9. Beispiel 13 in Kapitel 4.1.3 zeigt, wie am ehesten Ressourcen als Teil einer Reisereservierung adressiert werden sollten. Dazu folgen weitere Erläuterungen in Kapitel 4.1.3.

Sollte eine SOAP-Nachricht im HTTP-Body hinterlegt werden, muss der "HTTP content type header" auf "application/soap+xml" gesetzt werden. (Im vorliegenden Beispiel ist ein optionaler Parameter für den Zeichensatz vorgegeben, z. B. Werte wie "utf-8" oder "utf-16". Fehlte diese Angabe, würde auf den Zeichensatz des Body der HTTP-Anfrage zurückgegriffen werden.)

Beispiel 10 zeigt die Rückgabe eines RPC (Details sind entfernt worden), welcher von dem Buchungssystem als HTTP-Antwort auf die Anfrage aus Beispiel 5a verschickt wurde. Unter Verwendung von HTTP folgt SOAP bzgl. dem Informationsstatus zur Kommunikation der Semantik des HTTP-Statuscodes. Z. B. verweist die Serie von 2xx des HTTP-Statuscodes darauf, dass die Anfrage des Clients (einschließlich der SOAP-Komponenten) erfolgreich empfangen, verstanden und akzeptiert wurde.

Beispiel 10
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
...
...
</env:Header>
<env:Body>
...
...
</env:Body>
</env:Envelope>
Returnierter RPC aus Beispiel 5a, eingeschlossen in einer HTTP-Antwort, mit Angabe über den erfolgreichen Verlauf

Sollte ein Fehler bei der Verarbeitung der Anfrage auftreten, sehen die Spezifikationen der HTTP-Bindung vor, dass ein HTTP 500 "Internal Server Error" angegeben wird, wie auch eine eingebettete SOAP-Nachricht, die den SOAP-Fehler, der serverseitig bei der Verarbeitung aufgetreten ist, beinhaltet.

Beispiel 11 stellt die gleiche SOAP-Fehlernachricht wie Beispiel 6a dar, allerdings mit zusätzlichem HTTP-Header.

Beispiel 11
HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:BadArguments</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text
xml:lang="en-US">Processing error</env:Text>
<env:Text
xml:lang="cs">Chyba zpracování</env:Text>
</env:Reason>
<env:Detail>
<e:myFaultDetails
xmlns:e="http://travelcompany.example.org/faults">
<e:message>Name does not match card number</e:message>
<e:errorcode>999</e:errorcode>
</e:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>
Beispielhafte SOAP-Nachricht in einer HTTP-Antwort, die auf einen Fehler innerhalb des  SOAP-Body aus Beispiel 4 verweist

SOAP-Teil 2 Table 16 beinhaltet detailliert, wie mit den verschiedenen HTTP-Antwortcodes umgegangen werden sollte, also den 2xx (erfolgreich), 3xx (Umleitung), 4xx (Clientfehler) und 5xx (Serverfehler).

4.1.3 SOAP-Verwendung gemäß der Web-Struktur

Eines der bedeutsamsten Konzepte des World Wide Web ist das des URI zur Identifizierung von Ressourcen. SOAP-Dienste, die die HTTP-Bindung nutzen und mit anderer Software im Web interagieren möchten, sollten URIs nutzen, um all deren Ressourcen adressieren zu können. Z. B., eine sehr wichtige - vorherrschende - Anwendung im World Wide Web ist der Empfang reiner Informationen, wo die Darstellung einer über einen URI erreichbaren Ressource, durch eine HTTP GET-Anfrage erfolgt, ohne dass die Ressource in irgendeiner Art und Weise verändert wird. (Man nennt dies in der HTTP-Terminologie eine "sichere und idempotente Methode" (safe and idempotent method ).) Die Ressource wird vom Anbieter über die zugehörigen URI veröffentlicht und wird dann vom Anwendern "geholt" ("GET").

Es gibt sehr viele Fälle, in denen SOAP-Nachrichten so entworfen werden, dass sie dem alleinigen Erwerb an Informationen dienen, z. B., wenn der Zustand einer Ressource (oder einem Objekt im Sinne der Programmierung) abgefragt wird. Im Gegensatz dazu Anwendungsfälle, die eine Änderung der Ressource hervorrufen. Die Fälle, in denen der SOAP-Body und die in ihm enthaltenen Elemente zur Abfrage eines Zustands benutzt werden, sind nicht im Sinne des Webs (sogar eher hinderlich), weil die Ressourcen nicht über den Anfrage-URI eines HTTP GET identifiziert werden können. (In einigen SOAP/RPC Implementierungen dient der HTTP-Anfrage-URI oftmals nicht der Identifizierung einer Ressource, sondern der einer Zwischenstationen, die dann die SOAP-Nachricht evaluieren muss, um die Ressource zu identifizieren.)

Um die notwendigen Änderungen zu verdeutlichen, zeigt Beispiel 12a wie es nicht empfohlen wird, Informationen "sicher" aus dem Web zu empfangen. Dies ist ein Beispiel eines RPC, welcher über eine SOAP-Nachricht transportiert wird. Es bezieht sich wieder auf das Reiseszenario, in dem nach der Reisebeschreibung einer bestimmten Reservierung, parametrisiert über reservationCode, gefragt wird. (Es wird angenommen, dass die Applikation keine Eigenschaften benötigt, die die Anwendung von SOAP-Header erforderlich machen würde.)

Beispiel 12a
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<m:retrieveItinerary
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservationCode>FT35ZBQ</m:reservationCode>
</m:retrieveItinerary>
</env:Body>
</env:Envelope>
Von dieser Darstellung ist in den Fällen abzuraten, wo ein "sicherer" Abruf erfolgen soll

Die Ressource wird nicht über den gerichteten URI identifiziert, sondern kann nur über eine Analyse des SOAP-Envelope erfolgen. Deswegen ist es nicht möglich diese nur via HTTP den Nachfragenden im World Wide Web zugänglich zu machen, wie es bei "erreichbaren" URIs im Web der Fall ist.

SOAP-Teil 2 Kapitel 4.1 legt Empfehlungen dar, wie RPCs zum Empfang sicherer und idempotenter Informationen in "Web-kompatibler" Art und Weise definiert werden können. Dies erfolgt über die Unterscheidung in der RPC-Definition zwischen den Methoden und spezifischen Parameter, die dazu dienen eine Ressource zu identifizieren, von denen, die andere Ziele verfolgen. In Beispiel 12a wird die Ressource die abgefragt werden soll, über zwei Dinge identifiziert: das erste ist das der Reisebeschreibung (Teil des Methodennamen) und das zweite ist der Verweis auf eine bestimmte Instanz (ein Parameter der Methode). In diesem Fall wird empfohlen, dass die Teile zur Identifizierung über den HTTP-Anfrage-URI dargestellt werden, um die eigentliche Ressource zu identifizieren. So z. B.: http://travelcompany.example.org/reservations/itinerary?reservationCode=FT35ZBQ.

Außerdem, wenn eine RPC-Definition so angelegt ist, dass sich alle Teile ihrer Methode zur Identifizierung einer Ressource (resource-identifying) anwenden lassen, dann kann das Ziel des RPC vollständig über einen URI identifiziert werden. Sollte der Anbieter der Ressource dann auch noch bestätigen können, dass die eingetroffene Anfrage "sicher" ist, empfiehlt die SOAP-Version 1.2, dass die Wahl des "SOAP Web Method feature" auf GET und dem SOAP Response message exchange pattern, gemäß Kapitel 4.1.1 fallen sollte. Dies gewährleistet, dass der SOAP RPC in einer gemäß der Web-Struktur angepassten Art und Weise durchgeführt wird. Beispiel 12b zeigt die bevorzugte "sichere" Anfrage eines SOAP-Knotens nach einer Ressource.

Beispiel 12b
GET /Reservations/itinerary?reservationCode=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: application/soap+xml
Die alternative, gemäß der Web-Struktur angepassten Anfrage eines RPC aus Beispiel 12a

Es sollte erwähnt werden, dass die SOAP-Version 1.2 keinen Algorithmus festschreibt, wie sich eine URI aus den Bestimmungen zu einem RPC, der zur Abfrage reiner Informationen dient, zusammensetzt.

Allerdings, sollte die Applikation Eigenschaften benötigen, die nur bindungsspezifisch innerhalb des SOAP-Information Sets vorliegen können, z. B. bei Anwendung der SOAP-Header-Blöcke, dann muss die HTTP POST-Methode mit einer SOAP-Nachricht im Body angewandt werden.

Außerdem wird das SOAP Request-Response message exchange pattern notwendig, angewandt via HTTP POST, wenn die RPC-Beschreibung Daten (Parameter) beinhalten, die keine Identifizierung von Ressourcen erlauben. Sogar in einem solchen Fall, kann ein HTTP POST mit einer SOAP-Nachricht auf "Web-kompatible" Art und Weise dargestellt werden. Wie bei der Verwendung von GET, empfiehlt [SOAP-Teil2] im Allgemeinen alle Teile der SOAP-Nachricht, die zur Identifizierung einer Ressource beitragen, in den HTTP-Anfrage-URI einzubinden. Die gleichen Parameter können natürlich auch innerhalb des SOAP-env:Body-Elements vorliegen. (Die Parameter müssen im Falle eines SOAP-basierten RPCs im Body vorliegen, wenn dies aus der Prozedur-/Methoden-Beschreibung der empfangenden Applikation hervorgeht.)

Beispiel 13 ist das gleiche wie Beispiel 9, mit dem Unterschied, dass der HTTP-Anfrage-URI den Reservierungscode beinhaltet, der zur Identifikation der Ressource dient (die betreffende Reservierung, welche bestätigt und bezahlt wurde).

Beispiel 13
POST /Reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0'?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard
xmlns:o="http://mycompany.example.com/financial">
<n:name
xmlns:n="http://mycompany.example.com/employees">Åke Jógvan Øyvind</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation>
</env:Body>
</env:Envelope>
RPC aus Beispiel 4, hier über eine HTTP POST-Anfrage in Web-freundlicher Form transportiert

In Beispiel 13 wird die zu ändernde Ressource über zwei Kriterien identifiziert: als erstes handelt es sich um eine Reservierung (Teil des Methodennamen) und als zweites liegt eine bestimmte Instanz einer Reservierung vor (die den Wert des Parameters code der Methode betrifft). Der andere Parameter des RPC, wie die creditCard-Nummer dienen nicht der Identifizierung der Ressource, sind aber zusätzliche Daten, die von der Ressource zur Verarbeitung nötig sind. Laut Empfehlung des [SOAP-Teil 2] sollten, wenn möglich, Ressourcen, die über einen SOAP-basierten RPC aufgerufen werden, solche Informationen immer in den URI zur Identifizierung des RPC-Ziels einfließen lassen. Allerdings legt [SOAP-Teil 2] keinen Algorithmus dafür fest. Solche Algorithmen können zukünftig entwickelt werden. Wie zu sehen ist, sind alle zur Identifizierung der Ressource notwendigen Elemente aus Beispiel 9 in ihrer Form beibehalten worden.

Mit anderen Worten, wie aus dem obigen Beispiel hervorgeht, lautet die Empfehlung der SOAP-Spezifikationen, URIs zur Identifizierung von Ressourcen entsprechend der Web-Struktur zu nutzen, gleich ob GET oder POST verwendet wird.

4.2 SOAP mittels Email

Anwendungsentwickler können Email-Infrastruktur nutzen, um SOAP-Nachrichten entweder als Text oder als Anhang zu verschicken. Das unten aufgeführte Beispiel zeigt einen möglichen Weg zum Transport einer SOAP-Nachricht, sollte aber nicht als ein standardisierter Versand von SOAP-Emails verstanden werden. Die Spezifikationen zu SOAP-Version 1.2 sehen keine Bestimmungen zu dieser Art der Bindung vor. Dennoch gibt es eine nicht-normative W3C Note [SOAP Email Binding], die ein Email-Bindung für SOAP beschreibt, mit der Absicht, das allgemeingültige Rahmenwerk zur SOAP-Protokoll-Bindung zu demonstrieren [SOAP-Teil 1].

Beispiel 14 zeigt die Anfrage zur Reisereservierung aus Beispiel 1, die hier per Email zwischen dem sendenden und dem empfangenden Emailprogramm verschickt wird. Es wird vorausgesetzt, dass der empfangende Knoten fähig ist, den SOAP-Teil der Nachricht zu verarbeiten. (Außerdem wird angenommen, dass der sendende Knoten SOAP-Fähigkeiten besitzt, die es ermöglichen, SOAP-Fehler, die er als Antwort empfängt, zu verarbeiten oder eine empfangene SOAP-Nachricht mit einer von ihm gesendeten Nachricht in Beziehung zu setzen.)

Beispiel 14
From: a.oyvind@mycompany.example.com
To: reservations@travelcompany.example.org
Subject: Travel to LA
Date: Thu, 29 Nov 2001 13:20:00 EST
Message-Id: <EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>
SOAP-Nachricht aus Beispiel 1, befördert von einer SMTP-Nachricht

Der Header aus Beispiel 14 ist gemäß [RFC 2822] für Email-Nachrichten standardisiert.

Obwohl eine Email einen one-way-Nachrichtenaustausch darstellt und es für die ordnungsgemäße Übertragung keine Garantie gibt, bietet eine Infrastruktur, wie die des Simple Mail Transport Protocol (SMTP) [SMTP] (ein Mechanismus zur Übertragungsbenachrichtigung (delivery notification mechanism)), der im Falle von SMTP Delivery Status Notification (DSN) und Message Disposition Notification (MDN) genannt wird. Diese Benachrichtigungen werden in Form von Email-Nachrichten zu den entsprechenden Email-Adressen aus dem Email-Header versandt. Applikationen, wie auch die Email-Endanwender, können diesen Mechanismus nutzen, um über den Stand der Email-Übertragung informiert zu sein. Allerdings sind es Benachrichtigungen auf SMTP-Ebene. Der Entwickler muss die Fähigkeiten und Grenzen dieser Übertragungsbenachrichtigungen vollständig verstehen, ansonsten geht er evt. irrtümlich von einer erfolgreichen Übertragung aus, weil die Rückmeldung fehlt.

"SMTP delivery status"-Nachrichten werden von der Nachrichtenverarbeitung auf SOAP-Ebene getrennt. Resultierende SOAP-Antworten werden über eine neue Email returniert, die auf SMTP-Ebene mit der ursprünglich versendeten Email-Nachricht in Beziehung gesetzt werden kann. Die Verwendung des [RFC 2822] In-reply-to:-Header kann eine solche Beziehung auf SMTP-Ebene leisten, bietet aber eine solche Beziehung nicht unbedingt auf SOAP-Ebene an.

Beispiel 15 entspricht dem Szenario Beispiel 2, wo die SOAP-Nachricht gezeigt wird (der Übersicht wegen ohne Details), die von dem Buchungssystem zum Reservierungsprogramm versandt worden ist, um einige Reservierungsdetails zu klären, mit dem Unterschied, dass hier der Transport per Email stattfindet. In dem Beispiel wird die ursprüngliche Email-Message-Id über den zusätzlichen Email-Header In-reply-to: transportiert. Dies führt zu einer Korrelation zwischen den Email-Nachrichten auf SMTP-Ebene, jedoch nicht zu einer SOAP-spezifischen Korrelation. In diesem Beispiel verlässt sich die Applikation auf den reservation-Header-Block, um SOAP-Nachrichten in Beziehung zu setzen. Betont sei, dass die Art des Zustandekommens dieser Korrelation, in den Zuständigkeitsbereich der Applikation und nicht in den von SOAP fällt.

Beispiel 15
From: reservations@travelcompany.example.org
To: a.oyvind@mycompany.example.com
Subject: Which NY airport?
Date: Thu, 29 Nov 2001 13:35:11 EST
Message-Id: <200109251753.NAA10655@travelcompany.example.org>
In-reply-to:<EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml

<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:itineraryClarifications>
...
...
</p:itineraryClarifications>
</p:itinerary>
</env:Body>
</env:Envelope>
SOAP-Nachricht aus Beispiel 2, transportiert in einer Email-Nachricht, die durch den Header mit einer vorhergehenden Nachricht in Beziehung gesetzt wird.

5. Weiterführende Anwendungsfälle

5.1 Einsatz von SOAP-Zwischenstationen

Das durchgängig in dieser Einführung verwendete Szenario zur Reisereservierung bietet die Darstellung einiger Verwendungsmöglichkeiten von SOAP-Zwischenstationen. Zur Erinnerung, die erste einfache Kommunikation stellt den Austausch einer Reservierungsanfrage zwischen einem Reservierungsprogramm und dem Buchungssystem dar. SOAP legt nicht fest wie ein Nachrichtenpfad bestimmt und verfolgt wird. Es ist nicht Bestandteil der Spezifikationen zu SOAP. Allerdings beschreiben diese, wie sich ein SOAP-Knoten zu verhalten hat, wenn er eine SOAP-Nachricht empfängt, die nicht für ihn bestimmt ist. Die SOAP-Version 1.2 sieht zwei Typen von Zwischenstationen vor: weiterleitende (forwarding intermediaries) und aktive Zwischenstationen (active intermediaries).

Eine weiterleitende Zwischenstation (forwarding intermediary) ist ein SOAP-Knoten der, abhängig von der Semantik des Header-Blocks einer empfangenen SOAP-Nachricht oder abhängig von dem verwendeten "message exchange pattern", die SOAP-Nachricht an einen anderen SOAP-Knoten weiterleitet. Z. B., die Verarbeitung eines "routing"-Header-Blocks, der Aussagen zum Nachrichtenpfad einer ankommenden SOAP-Nachricht macht, kann festlegen, dass die SOAP-Nachricht auf Grundlage der Daten im Header-Block an einen weiteren SOAP-Knoten geleitet werden soll. Das Format des SOAP-Header der ausgehenden SOAP-Nachricht, d. h. die Platzierung von eingefügten oder wieder eingefügten Header-Blöcken, wird bestimmt durch die gesamte Verarbeitung der weiterleitenden Zwischenstation (auf Basis der Semantik der verarbeiteten Header-Blöcke).

Eine aktive Zwischenstation (active intermediary) nimmt zusätzliche Verarbeitungen an der ankommenden SOAP-Nachricht vor und leitet diese erst dann weiter. Die Kriterien zum Eingriff in eine Nachricht sind nicht über die SOAP-Header-Blöcke oder dem verwendeten "message exchange pattern" beschrieben. Als Beispiel für eine solche Verarbeitung von einem SOAP-Knoten könnte die Verschlüsselung einiger Teile einer SOAP-Nachricht darstellen und das Hinterlegen von Informationen zum Schlüssel in Header-Blöcken. Es könnten aber auch Zeitstempel und Anmerkungen über neu eingefügte Header-Blöcke in eine ausgehende Nachricht gepackt werden, die von nachgelagerten Knoten ausgewertet werden.

Um zu kennzeichnen, was eine aktive Zwischenstation an einer Nachricht was geändert hat, fügt sie Header-Blöcken in die ausgehende SOAP-Nachricht ein. Diese neuen Header-Blöcke tragen dazu bei, dass nachfolgende SOAP-Knoten, denen eine bestimmte Rolle zugewiesen ist, nur auf Grundlage dieser zusätzlichen Informationen ordnungsgemäß arbeiten können. In einem solchen Fall sollten die eingesetzten Header-Blöcke von den anschließenden Zwischenstationen, so weit wie nötig, (wieder) eingefügt werden, damit gewährleistet ist, dass die nachfolgenden Knoten die Nachricht sicher verarbeiten können. Sollten z. B. die Header-Blöcke, der Verschlüsselung wegen, aus einer Nachricht entfernt worden sein und diese Nachricht nun die zweite Zwischenstation passieren (ohne das diese die originalen Header-Blöcke entschlüsselt und rekonstruiert), dann muss die Kennzeichnung bzgl. der Verschlüsselung in der zweiten weitervermittelten Nachricht verbleiben.

Im folgenden Beispiel wird ein SOAP-Knoten in den Nachrichtenpfad zwischen dem Reservierungsprogramm und dem Buchungssystem eingefügt, der die Nachricht aus dem Beispiel 1 abhört. So könnte ein solcher SOAP-Knoten alle Reiseanfragen aufzeichnen, damit eine nachträgliche Prüfung von Seiten eines Reisebüros möglich sind. Die Header-Blöcke reservation und passenger aus dem Beispiel sind für diejenigen Knoten bestimmt, die die Rolle "next" einnehmen, also für die nächsten SOAP-Knoten innerhalb des Nachrichtenpfades, die die Nachricht empfangen. Das die Header-Blöcke obligatorisch sind (das Attribut mustUnderstand ist mit "true" belegt), muss der betroffene Knoten Kenntnis (durch eine externe Spezifizierung zur Semantik der Header-Blöcke) darüber haben, was seinerseits zu tun ist. Eine Spezifikation zur Aufzeichnung solcher Header-Blöcke könnte die einfache Anforderung darstellen, dass diverse Details der Nachricht von jedem Knoten, der diese Nachricht empfängt, aufgezeichnet werden und dass die Nachricht unverändert entlang des Nachrichtenpfades weitergeleitet wird. (Es ist noch anzumerken, dass die Spezifikationen zum Header-Block vorsehen sollten, dass die gleichen Header-Blöcke wieder in die ausgehende Nachricht eingefügt werden, weil das Verarbeitungsmodell von SOAP vorsieht, dass diese ansonsten entfernt werden.) In einem solchen Fall agiert der SOAP-Knoten als weiterleitende Zwischenstation.

Ein komplexeres Szenario stellt sich ein, wenn eine empfangene Nachricht so verändert worden ist, wie es vom ursprünglichen Absender nicht vorauszusehen war. Im folgenden Beispiel wird davon ausgegangen, dass eine korporative Reiseanwendung an einer SOAP-Zwischenstation der Nachricht aus Beispiel 1 einen Header-Block hinzufügt. Dann leitet diese die Nachricht entlang des Nachrichtenpfades zum Buchungssystem, dem endgültigen Empfänger, weiter. Der Header-Block enthält die Reisebedingungen zur angefragten Reise. Die Spezifikationen zu dem Header-Block können verlangen, dass der endgültige Empfänger (und zwar nur der endgültige Empfänger, angedeutet durch das fehlende Attribut role) von diesen Informationen während der Verarbeitung des Body der Nachricht Gebrauch macht.

Beispiel 16 zeigt wie ein aktiver Zwischenstation einen zusätzlichen Header-Block, travelPolicy, eingefügt hat. Bestimmt ist dieser für den endgültigen Empfänger.

Beispiel 16
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger
xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
<z:travelPolicy
xmlns:z="http://mycompany.example.com/policies"
env:mustUnderstand="true">
<z:class>economy</z:class> <z:fareBasis>non-refundable<z:fareBasis> <z:exceptions>none</z:exceptions> </z:travelPolicy> </env:Header> <env:Body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>New York</p:departing> <p:arriving>Los Angeles</p:arriving> <p:departureDate>2001-12-14</p:departureDate> <p:departureTime>late afternoon</p:departureTime> <p:seatPreference>aisle</p:seatPreference> </p:departure> <p:return> <p:departing>Los Angeles</p:departing> <p:arriving>New York</p:arriving> <p:departureDate>2001-12-20</p:departureDate> <p:departureTime>mid morning</p:departureTime> <p:seatPreference/> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:Body> </env:Envelope>
SOAP-Nachricht aus Beispiel 1 zur Reisereservierung, nachdem eine aktive Zwischenstation einen obligatorischen Header für den endgültigen Empfänger der Nachricht eingefügt hat.

5.2 Anwendung anderer Kodierungsschemen

Obwohl die SOAP-Version 1.2 ein bestimmtes Kodierungsschema definiert (siehe SOAP-Teil 2 Kapitel 3), kann es optional angewandt werden. So hebt die Spezifikation hervor, dass abhängig von der Anwendung, andere Kodierungsschemen für SOAP-Nachrichten verwendet werden können. Zu diesem Zweck sieht sie das Attribut env:encodingStyle vom Typ xs:anyURI vor, um Header-Blöcke, beliebige Kindelemente des Elements des SOAP env:Body, Kindelemente des Elements env:Detail und ihren Nachkommen zu qualifizieren. Es signalisiert ein Serialisationsschema für den verschachtelten, oder zumindest einfachen Inhalt, bis ein anderes Element vorliegt, dass ein anderes Kodierungsschema für seinen verschachtelten Inhalt vorsieht. Die Wahl für den Wert des Attributs env:encodingStyle, ist eine anwendungsbezogene Entscheidung und so wird vorausgesetzt, dass der Umgang damit "extern" geregelt ist. Sollte das Attribut nicht vorliegen, wird keine Forderung zur verwendeten Kodierung gestellt.

Die Anwendung eines alternativen Kodierungsschema wird in Beispiel 17 vorgestellt. Anknüpfend am Szenario der Reisereservierung zeigt dieses Beispiel eine SOAP-Nachricht mit Reisedetails, die vom Buchungssystem nach der Reservierungsbestätigung an einen Reisenden verschickt wird. (Gleiche Nachricht wurde bereits in anderen Zusammenhang in Beispiel 8b verwendet.)

Beispiel 17
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
</m:reservation>
</env:Header>
<env:Body>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://travelcompany.example.org/vocab#"
env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<x:ReservationRequest
rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
<x:passenger>Åke Jógvan Øyvind</x:passenger>
<x:outbound>
<x:TravelRequest>
<x:to>LAX</x:to>
<x:from>LGA</x:from>
<x:date>2001-12-14</x:date>
</x:TravelRequest>
</x:outbound>
<x:return>
<x:TravelRequest>
<x:to>JFK</x:to>
<x:from>LAX</x:from>
<x:date>2001-12-20</x:date>
</x:TravelRequest>
</x:return>
</x:ReservationRequest>
</rdf:RDF>
</env:Body>
</env:Envelope>
Die SOAP-Nachricht zeigt eine alternative Kodierung für das Element Body

In Beispiel 17 beinhaltet der Body der SOAP-Nachricht eine Beschreibung zum Reiseverlauf unter Verwendung der Syntax des Resource Description Framework (RDF) [RDF]. (Kurz gesagt, "RDF graph" setzt Ressourcen - wie die Ressource zur Reisereservierung, erreichbar unter http://travelcompany.example.org/reservations?code=FT35ZBQ - mit anderen Ressourcen (oder Werten) über Eigenschaften, z. B. den passenger, die Abreise (outbound) und Rückreise (return), in Beziehung zueinander. Die RDF-Kodierung könnte z. B. aus dem Grund gewählt worden sein, damit das Reservierungsprogramm des Reisenden die RDF-Daten in eine RDF-kompatible Kalenderapplikation speichert, die auf unterschiedliche Weise abgefragt werden könnte.)

6. Änderungen zwischen SOAP 1.1 und SOAP 1.2

SOAP-Version 1.2 weist eine Menge syntaktischer Änderungen auf und wurde um zusätzliche (oder klärende) Inhalte aus [SOAP 1.1] erweitert. Die folgende Liste zeigt die Unterschiede beider Spezifikationen. Ziel dieser Liste ist eine schnelle und einfache Übersicht der Unterschiede, die zwischen beiden Spezifikationen bestehen. Zur einfacheren Zuordnung sind die betroffenen Merkmale Kategorien zugeteilt worden und so kann es durchaus vorkommen, dass der eine oder andere Punkt genauso gut in einer anderen Kategorie vorzufinden ist.

Dokumentstruktur

Zusätzliche oder geänderte Syntax

SOAP-Bindung an HTTP

RPC

SOAP-Kodierungen

SOAP-Teil 1 Anhang A beinhaltet Regeln für einen SOAP-Knoten, wie er die Umstellung von der [SOAP 1.1] Version zur SOAP-Version 1.2 bewerkstelligen kann. Genau genommen definiert dieser einen env:Upgrade Header-Block, der von einem SOAP 1.2-Knoten so benutzt werden kann, dass bei dem Empfang einer [SOAP 1.1] Nachricht eine SOAP-Fehlernachricht zum ursprünglichen Absender verschickt wird, um anzuzeigen, welche SOAP-Version unterstützt wird.

7. Quellenangaben

[SOAP-Teil 1] W3C Recommendation "SOAP 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (siehe http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)

[SOAP-Teil 2] W3C Recommendation "SOAP 1.2 Part2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (siehe http://www.w3.org/TR/2003/REC-soap12-part2-20030624.)

[RFC 2396] IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (siehe http://www.ietf.org/rfc/rfc2396.txt.)

[HTTP 1.1] IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (siehe http://www.ietf.org/rfc/rfc2616.txt.)

[XML 1.0] W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (siehe http://www.w3.org/TR/2000/REC-xml-20001006.

[Namespaces in XML] W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (siehe http://www.w3.org/TR/1999/REC-xml-names-19990114/.)

[XML Schema Teil 1] W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (siehe http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ )

[XML Schema Teil 2] W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (siehe http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ )

[SMTP] SMTP wird über eine Reihe an RFCs definiert:

[RDF] W3C Recommendation "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999. (siehe http://www.w3.org/TR/REC-rdf-syntax.)

[SOAP 1.1] W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box et al., 8 May, 2000 (siehe http://www.w3.org/TR/SOAP/)

[XML Infoset] W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (siehe http://www.w3.org/TR/xml-infoset/)

[SOAP MediaType] IETF Internet Draft "The 'application/soap+xml' media type", M. Baker, M. Nottingham, "draft-baker-soap-media-reg-03.txt", May 29, 2003. (siehe http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt, dieser Internet Draft ist bloß bis November 2003 gültig)

[SOAP Email Binding] W3C Note "SOAP Version 1.2 Email Binding", Highland Mary Mountain et al, draft June 13, 2002. (siehe http://www.w3.org/TR/2002/NOTE-soap12-email-20020626.)

[XML Base] W3C Recommendation "XML Base", Jonathan Marsh, 27 June 2001. (siehe http://www.w3.org/TR/2001/REC-xmlbase-20010627/)

[RFC 2119] IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (siehe http://www.ietf.org/rfc/rfc2119.txt.)

A. Danksagungen

Highland Mary Mountain (Intel) trug wesentlich zum Kapitel der SMTP-Bindung bei. Paul Denning besorgte die Anwendungsszenarien, die bis dahin im SOAP Version 1.2 Usage Scenarios Working Draft vorlagen. Stuart Williams, Oisin Hurley, Chris Ferris, Lynne Thompson, John Ibbotson, Marc Hadley, Yin-Leng Husband und Jean-Jacques Moreau steuerten detaillierte Kommentare zu vorherigen Versionen dieses Dokuments bei, wie es auch viele andere zur letzten Besprechung des Working Draft getan haben. Jacek Kopecky besorgte eine Liste von Änderungen der RPC- und SOAP-Kodierungen.

Dieses Dokument ist eine Arbeit der W3C XML Protocol Working Group.

Teilnehmer der Arbeitsgruppe sind (zum Zeitpunkt des Verfassens und in alphabetischer Reihenfolge): Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly of Allaire), David Fallside (IBM, Chair), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Hervé Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Pete Wenzel (sieheBeyond), Volker Wiechers (SAP AG.)

Vorherige Teilnehmer waren: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred), formerly of Sun Microsystems), Philippe Bedu (EDF (Electricité de France)), Olivier Boudeville (EDF (Electricité de France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Don Mullen (TIBCO), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft.)

Wir möchten allen danken die zur Diskussion unter xml-dist-app@w3.org beigetragen haben.