Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Binäre Protokolle wie DCOM bestehen aus einer Methodenanfrageebene, die sich oberhalb eines Herstellerkommunikationsprotokolls befindet. Solche Protokolle sind zum Erstellen universal verfügbarer XML-Webdienste nicht geeignet. Dies schließt die Verwendung solcher Protokolle in einem XML-Webdienstszenario nicht aus. Der 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.
Alternativ können Sie XML-Webdienste erstellen, die mit einem oder mehreren offenen Protokollen arbeiten, z. B. einer Kombination aus HTTP und SOAP. Die erforderliche Infrastruktur hängt jeweils von den verschiedenen zu unterstützenden Protokollen ab.
XML-Webdienste unterstützen nicht nur RPC (Remote Procedure Call)-Zugriffe. 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, die HTTP (Hypertext Transfer Protocol)-Verben für die Codierung und Übergabe von Parametern wie Name/Wert-Paare zusammen mit der zugehörigen Anforderungssemantik verwenden. Beide bestehen aus einer Reihe von HTTP-Anfrageheadern, die u. a. festlegen, was der Client vom Server abfragt, der wiederum mit einer Reihe von HTTP-Antwortheadern und ggf. 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". Diese wird dem URL des Servers angehängt, der die Anforderung bearbeitet. URL-Codierung ist eine Form der Zeichencodierung, bei der sichergestellt wird, dass übergebene Parameter aus übereinstimmendem Text bestehen, wie bei der Codierung eines Speicherplatzes als %20. Die angehängten Parameter werden auch als Abfragezeichenfolge bezeichnet.
Wie bei HTTP-GET sind auch HTTP-POST-Parameter URL-codiert. Die Name/Wert-Paare werden jedoch nicht als Teil des URL, sondern innerhalb der eigentlichen HTTP-Anforderungsmeldung übergeben.
SOAP
SOAP ist ein einfaches, kompaktes, XML-basiertes Protokoll zum Austausch von strukturierten und typbezogenen Informationen über das Internet. Das allgemeine Gestaltungsziel 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 Meldungsframework, das keine Anwendungs- oder Transportsemantik enthält. Dadurch ist es in hohem Maße modular und erweiterbar.
Indem SOAP Standardtransportprotokolle durchläuft, kann es die offene Architektur des Internets ausnutzen und ist damit mit jedem beliebigen System kompatibel, das die grundlegenden Internetstandards unterstützt. Die zur Unterstützung eines SOAP-kompatiblen XML-Webdienstes erforderliche Infrastruktur ist zwar sehr vereinfachend, aber dennoch leistungsstark, da sie der bestehenden Infrastruktur des Internets relativ wenig hinzufügt, aber dennoch universellen Zugriff auf die mit SOAP erstellten Dienste ermöglicht.
Die Spezifikation des SOAP-Protokolls umfasst vier Hauptkomponenten: Die erste Komponente definiert einen obligatorischen, erweiterbaren Envelope zur Einkapselung von Daten. Der SOAP-Envelope definiert eine SOAP-Meldung und stellt die Basiseinheit für den Austausch zwischen SOAP-Meldungsprozessoren dar. Dies ist die einzige obligatorische Komponente der Spezifikation.
Die zweite Komponente der Spezifikation des SOAP-Protokolls definiert optionale Datencodierungsregeln zur Repräsentation von anwendungsabhängigen Datentypen und gerichteten Graphen sowie ein einheitliches Modell zur Serialisierung nicht syntaktischer Datenmodelle.
Die dritte Komponente definiert ein RPC-artiges (Anforderung/Antwort) Meldungsaustauschmuster. SOAP-Meldungen sind unidirektionale Übertragungen. Obwohl SOAP auf RPC basiert, ist es nicht auf einen Anforderungs-/Antwortmechanismus beschränkt. XML-Webdienste kombinieren SOAP-Meldungen häufig, um solche Muster zu implementieren. SOAP erfordert jedoch kein Austauschmuster, und dieser Teil der Spezifikation ist ebenfalls optional.
Die vierte Komponente der Spezifikation definiert eine Bindung zwischen SOAP und HTTP. Diese Komponente ist ebenfalls optional. Sie können SOAP mit jedem Transportprotokoll oder Mechanismus kombinieren, der zum Transport des SOAP-Envelopes in der Lage ist, einschließlich SMTP, FTP oder auch einer Diskette.
Weitere Informationen zur SOAP-Spezifikation finden Sie auf der Website des W3C (http://www.w3.org/TR/soap).