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".
“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.
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.
Patentoffenlegungen, die diese Spezifikation betreffen,
können, in Konformität zu den W3C Richtlinien, auf
der Seite der Arbeitsgruppe patent
disclosure page gefunden werden.
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.
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.
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.
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.
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.
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.
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.
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:
Die Adresse des SOAP-Empfängerknoten.
Den Prozedur- oder Methodennamen.
Die Identitäten und Werte eines jeden Arguments, dass der
Methode oder Prozedur übermittelt werden muss, mit den
entsprechenden Ausgabeparametern und ihren Rückgabetyp.
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.
Die Form des Nachrichtenaustauschs, die zur
Übertragung des RPCs benutzt wird und die angewandte "Web
Methode" (dazu später mehr).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"http://www.w3.org/2003/05/soap-envelope/role/none" (im
Folgenden "none")
"http://www.w3.org/2003/05/soap-envelope/role/next" (im
Folgenden "next") und
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver"
(im Folgenden "ultimateReceiver").
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)
Beispiel 7b erweitert das vorherige
Beispiel durch die Einführung eines weiteren optionalen
Attributs im Header-Block, das Attribut env:mustUnderstand.
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.)
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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).
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.)
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.
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).
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.
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.)
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
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.
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
SOAP-Nachricht aus Beispiel 2, transportiert in einer
Email-Nachricht, die durch den Header mit einer vorhergehenden
Nachricht in Beziehung gesetzt wird.
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.
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.
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.)
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.)
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
Die SOAP 1.2 Spezifikationen erstrecken sich
über zwei Teile. [SOAP-Teil 1]
beinhaltet eine abstrakte Information Set-basierte Definition der
SOAP-Nachrichtenstruktur, das Verarbeitungsmodell und das
Rahmenwerk zur grundlegenden Protokoll-Bindung,
während [SOAP-Teil
2] Serialisierungsregeln zum Versenden des Information
Sets beinhaltet, wie auch eine detailliertes HTTP-Bindung.
SOAP 1.2 wird nicht als Abkürzung verwendet.
SOAP 1.2 wurde in Hinblick auf XML Information Sets
umgeschrieben und nicht als Serialisation in Form von
<?xml....?>, wie von SOAP 1.1 gefordert.
Zusätzliche oder geänderte Syntax
SOAP 1.2 erlaubt kein Element nach dem Body. Auch wenn es die
Beschreibung verschwieg, war es doch per SOAP 1.1 Schemadefinition
(schema
definition) möglich.
SOAP 1.2 erlaubt nicht, dass das Attribut
env:encodingStyle auf SOAP-env:Envelope
angewandt wird, wo es hingegen bei SOAP 1.1 bei jedem Element
angewandt werden konnte. SOAP 1.2 spezifiziert bestimmte Elemente,
bei denen das Attribut verwendet werden kann.
SOAP 1.2 definiert das neue Header-Element
env:NotUnderstoodzur Übertragung von
Informationen zu einem obligatorischen Header-Block, der nicht
verarbeitet werden konnte. Die Angabe erfolgt über einen
env:MustUnderstand Fehlercodes. SOAP 1.1 sieht
bereits Fehlercodes vor, aber ohne Details zu dessen
Verwendung.
In der SOAP 1.2 Information Set-basierten Beschreibung, nimmt
das Attribut env:mustUnderstand in den
Header-Elementen die (logischen) Werte "true" oder "false" an,
wobei in SOAP 1.1 die Werte "1" oder "0" verwendet
werden.
SOAP 1.2 beinhaltet den neuen
Fehlercode DataEncodingUnknown.
Die verschiedenen Namensräume beider Protokollen
unterscheiden sich zwnagsläufig.
SOAP 1.2 ersetzt das Attribut env:actor durch
env:role, allerdings mit gleicher Bedeutung.
SOAP 1.2 definiert ein neues Attribute env:relay
für Header-Blöcke, um anzuzeigen, ob unverarbeitete
Header-Blöcke weitergeleitet werden sollen.
SOAP 1.2 definiert zwei neue Rollen "none" und
"ultimateReceiver" zusammen mit einem detaillierten
Verarbeitungsmodell.
SOAP 1.2 hat die "dot"-Notation für Fehlercodes entfernt,
die nun einen einfachen XML-qualifizierten Namen darstellt,
wobei der Namensraum-Präfix den SOAP-Envelope-Namensraum
darstellt.
SOAP 1.2 ersetzt "client" und "server" Fehlercodes durch
"Sender" und "Receiver".
SOAP 1.2 verwendet nun die
Elementnamen env:Code und
env:Reason, die in SOAP 1.1 faultcode und
faultstring genannt wurden. SOAP 1.2 erlaubt ebenso
mehrere Kindelemente env:Text von
env:Reason durch xml:lang um den Grund
eines Fehlers in verschiedenen Sprachen abzubilden.
SOAP 1.2 beinhaltet eine hierarchische Struktur für das
obligatorische SOAP Subelement env:Code des
Elements env:Fault und führt zwei neue
Subelemente env:Node und env:Role
ein.
SOAP 1.2 hebt die Trennung zwischen Header- und Body-Fehler,
die durch die Angabe vom Element env:Details in
env:Fault der SOAP-Version 1.1 angezeigt wurden, auf.
In SOAP 1.2 macht die Gegenwart des Elements
env:Details keine Aussage dazu, welche Teile einer
fehlerhaften SOAP-Nachricht verarbeitet wurden.
SOAP 1.2 verwendet XML-Base [XML Base], um
den absolute URI einer relativen URI zu ermitteln, wobei in SOAP
1.1 keine Aussage dazu getroffen wurde.
SOAP-Bindung an HTTP
Aus dem SOAP 1.2 Bindung an HTTP wurde der in SOAP 1.1
definierte HTTP-Header SOAPAction entfernt und ein
neuer HTTP-Statuscode 427 von der IANA erfragt, um zu
kennzeichnen, dass seine Anwesenheit von der serverseitigen
Anwendung gefordert ist. Der Inhalt des vorherigen HTTP-Header
SOAPAction wird nun als ein Wert des
(optionalen) Parameters "action"
vom Medientyp "application/soap+xml" ausgedrückt, der
über die HTTP-Bindung angezeigt wird.
Im SOAP 1.2 Bindung an HTTP sollte der "Content-type header"
mit "application/soap+xml" statt "text/xml" wie in SOAP 1.1 belegt
werden. Die IETF Registrierung dieses neuen Medientyps
[SOAP MediaType] steht noch aus.
SOAP 1.2 beinhaltet eine genauere Beschreibung zur Verwendung
der verschiedenen 2xx, 3xx, 4xx HTTP-Statuscodes.
Die Unterstützung zum Rahmenwerk der HTTP-Erweiterungen
entfällt in SOAP 1.2.
SOAP 1.2 beinhaltet ein zusätzliches
Kommunikationsverfahren, welches als Teil der HTTP-Bindung genutzt
werden kann und die Verwendung von HTTP GET zum "sicheren und
idempotenten" Empfang von Informationen erlaubt.
RPC
SOAP 1.2 beinhaltet ein Element
rpc:result für RPCs.
SOAP 1.2 beinhaltet verschiedene zusätzliche Fehlercodes
im RPC
Namensraum.
SOAP 1.2 bietet Unterstützung für Web-kompatibel
gestaltete RPCs, die dem reinen, "sicheren" Empfang von
Informationen dient.
SOAP-Kodierungen
Es wurde ein abstraktes Datenmodell entwickelt und an SOAP 1.2
angepasst, das auf einen beschrifteten gerichteten
Graphen basiert. Die SOAP 1.2 Kodierungen hängen von
diesem Datenmodell ab. Die Konventionen zu SOAP RPC hängen
zwar auch von dem Datenmodell ab, sind aber nicht abhängig von
der SOAP-Kodierung. Die Verwendung der SOAP 1.2 Kodierung und der
SOAP 1.2 RPC Konventionen ist optional.
Die Syntax zur Serialisierung eines Array wurde
geändert.
Die Verwendung in SOAP 1.1 für teilweise übermittelte
Arrays ist in SOAP 1.2 nicht vorgesehen.
SOAP 1.2 erlaubt die inline (embedded) Serialisation von
"multiref values".
Das Attribut href in SOAP 1.1 (vom Typ
xs:anyURI) lautet in SOAP 1.2 nun
enc:ref und ist vom Typ IDREF.
In SOAP 1.2, "omitted accessors of compound types are made
equal to NILs".
SOAP 1.2 beinhaltet mehrere Fehler-Subcodes zur Anzeige von
Kodierungsfehler.
"Knotentypen sind in SOAP 1.2 optional".
SOAP 1.2 hat zusammenhängende Werte aus
dem SOAP-Daten-Modell entfernt.
SOAP 1.2 sieht ein zusätzlich optionales Attribute
enc:nodeType für kodierte Elemente der
SOAP-Kodierung vor, das die Struktur identifiziert (d. h., ein
simpler Wert, eine Struktur oder ein Array).
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.
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.
