XML-Webdiensttransportformate
Dieses Thema bezieht sich auf eine veraltete Technologie. XML-Webdienste und XML-Webdienstclients sollten nun mithilfe der folgenden Technologie erstellt werden: Windows Communication Foundation.
Binäre Protokolle wie DCOM bestehen aus einer Methodenanforderungsebene, die sich oberhalb eines proprietären Kommunikationsprotokolls befindet. Solche Protokolle eignen sich nicht zum Erstellen global verfügbarer XML-Webdienste. Dies schließt die Verwendung solcher Protokolle in einem XML-Webdienstszenario nicht aus. Ihr Nachteil besteht aber darin, dass solche Protokolle von der jeweiligen Architektur der zugrunde liegenden Systeme abhängen und daher das Spektrum potenzieller Clients einschränken.
Sie können stattdessen XML-Webdienste erstellen, die mit einem oder mehreren offenen Protokollen arbeiten, z. B. einer Kombination aus HTTP und SOAP. Für die Unterstützung verschiedener Protokolle gelten jeweils unterschiedliche Infrastrukturanforderungen.
XML-Webdienste unterstützen nicht nur RPC-Zugriffe (Remote Procedure Call, Remoteprozeduraufruf). Sie können auch zum Austausch strukturierter Informationen, z. B. Bestellungen und Rechnungen, und zur Automatisierung und Verknüpfung interner und externer Geschäftsprozesse verwendet werden.
HTTP-GET und HTTP-POST
HTTP-GET und HTTP-POST sind Standardprotokolle, in denen HTTP (Hypertext Transfer Protocol)-Verben für die Codierung und Übergabe von Parametern als Name/Wert-Paare zusammen mit der zugehörigen Anforderungssemantik verwendet werden. Beide bestehen aus einer Reihe von HTTP-Anforderungsheadern, die u. A. definieren, was der Client vom Server anfordert, der wiederum mit einer Reihe von HTTP-Antwortheadern und gegebenenfalls den angeforderten Daten antwortet.
HTTP-GET übergibt seine Parameter in Form von URL-codiertem Text und verwendet dafür den MIME-Typ "application/x-www-form-urlencoded". Der Text wird der URL des Servers angehängt, der die Anforderung bearbeitet. Die URL-Codierung ist eine Form von Zeichencodierung, mit der sichergestellt wird, dass die übergebenen Parameter aus entsprechendem Text bestehen, beispielsweise durch die Codierung eines Leerzeichen als %20. Die angefügten Parameter werden auch als Abfragezeichenfolge bezeichnet.
Wie bei HTTP-GET werden auch HTTP-POST-Parameter URL-codiert. Die Name/Wert-Paare werden jedoch nicht als Teil der URL, sondern innerhalb der eigentlichen HTTP-Anforderungsnachricht übergeben.
SOAP
SOAP ist ein einfaches, kompaktes XML-basiertes Protokoll zum Austausch von strukturierten Informationen und Typinformationen im Internet. Das allgemeine Entwurfsziel von SOAP besteht darin, das Protokoll so einfach wie möglich zu halten und ein Minimum an Funktionalität zur Verfügung zu stellen. Das Protokoll definiert ein Messagingframework, das keine Anwendungs- oder Transportsemantik enthält. Dadurch ist das Protokoll modular und stark erweiterbar.
Indem SOAP über Standardtransportprotokolle übertragen wird, kann es die vorhandene offene Architektur des Internets verwenden und wird von jedem beliebigen System akzeptiert, das die grundlegenden Internetstandards unterstützt. Die zur Unterstützung eines SOAP-kompatiblen XML-Webdiensts erforderliche Infrastruktur ist recht simpel, aber dennoch leistungsstark, da sie der vorhandenen Infrastruktur des Internets relativ wenig hinzufügt und doch universellen Zugriff auf die mit SOAP erstellten Dienste ermöglicht.
Die Spezifikation des SOAP-Protokolls besteht aus vier Hauptteilen. Der erste Teil definiert einen erforderlichen, erweiterbaren Umschlag zum Kapseln von Daten. Der SOAP-Umschlag definiert eine SOAP-Nachricht und stellt die Basiseinheit für den Datenaustausch zwischen SOAP-Nachrichtenprozessoren dar. Dies ist der einzige obligatorische Teil der Spezifikation.
Der zweite Teil der Spezifikation des SOAP-Protokolls definiert optionale Datencodierungsregeln zur Darstellung von anwendungsabhängigen Datentypen und gerichteten Graphen sowie ein einheitliches Modell zur Serialisierung nicht syntaktischer Datenmodelle.
Der dritte Teil definiert ein RPC-artiges (Anforderungs/Antwort)-Nachrichtenaustauschmuster. Jede SOAP-Nachricht ist eine unidirektionale Übertragung. Obwohl SOAP auf RPC basiert, ist es nicht auf einen Anforderungs-/Antwortmechanismus beschränkt. XML-Webdienste kombinieren SOAP-Nachrichten häufig, um solche Muster zu implementieren. SOAP erfordert jedoch kein Nachrichtenaustauschmuster, und dieser Teil der Spezifikation ist ebenfalls optional.
Der vierte Teil der Spezifikation definiert eine Bindung zwischen SOAP und HTTP. Dieser Teil ist ebenfalls optional. Sie können SOAP mit jedem Transportprotokoll oder Mechanismus kombinieren, mit dem der SOAP-Umschlag transportiert werden kann, einschließlich SMTP, FTP oder sogar Diskette.
Weitere Informationen zur SOAP-Spezifikation finden Sie auf der W3C-Website unter http://www.w3.org/TR/soap (nur auf Englisch verfügbar).