SOAP

Aus WM 2.0 Wissensmanagement-Wiki

Wechseln zu: Navigation, Suche

SOAP (Simple Object Access Protocol / Service Oriented Architecture Protocol) ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote- Procedure-Calls durchgeführt werden können. SOAP wird hautpsächlich für die Realisierung von Webservices eingesetzt und spielt in vielen Web-2.0-Anwendungen eine zentrale Rolle.

SOAP ist ein relativ langsames Protokoll mit sehr viel Overhead (siehe Performance Messung SOAP vs. COBRA, RMI, ICMP).

In der MSDN-Library ist folgender Artikel über SOAP veröffentlicht:

SOAP ist das Kommunikationsprotokoll für XML Web Services. Wenn SOAP als ein Kommunikationsprotokoll bezeichnet wird, denken die meisten an DCOM oder CORBA und stellen beispielsweise folgende Fragen: "Wie funktioniert die Objektaktivierung bei SOAP?" oder "Welchen Naming Service verwendet SOAP?". Obwohl eine SOAP-Implementierung diese Dinge wahrscheinlich enthält, legt der SOAP-Standard diese nicht fest. Bei SOAP handelt es sich um eine Spezifikation, die das XML-Format für Nachrichten definiert - mehr enthält der erforderliche Teil der Spezifikation nicht. Wenn Sie über ein wohlgeformtes XML-Fragment verfügen, das in ein paar SOAP-Elemente eingeschlossen ist, haben Sie bereits eine SOAP-Nachricht. Einfach, nicht wahr?

Es gibt andere Teile der SOAP-Spezifikation, die beschreiben, wie Programmdaten als XML darzustellen und wie mit SOAP Remoteprozeduraufrufe (RPC) durchzuführen sind. Diese optionalen Teile der Spezifikation dienen der Implementierung von RPC-artigen Anwendungen. Dabei werden eine SOAP-Anwendung mit einer aufrufbaren Funktion und die Parameter zur Übergabe an die Funkion vom Client gesendet, und der Server gibt eine Nachricht mit den Ergebnissen der ausgeführten Funktion zurück. Die meisten aktuellen Implementierungen von SOAP unterstützen RPC-Anwendungen, da Programmierer, die an COM- und CORBA-Anwendungen gewöhnt sind, den RPC-Stil verstehen. SOAP unterstützt auch Anwendungen im Dokumentstil, bei denen die SOAP-Nachricht nur ein Wrapper um ein XML-Dokument ist. SOAP-Anwendungen im Dokumentstil sind sehr flexibel, und viele neue XML Web Services nutzen diese Flexibilität zur Erstellung von Diensten, die mit RPC schwer zu implementieren wären.

Der letzte optionale Teil der SOAP-Spezifikation definiert das Aussehen einer HTTP-Nachricht, die eine SOAP-Nachricht enthält. Diese HTTP-Bindung ist wichtig, da HTTP von fast allen aktuellen (und vielen nicht so aktuellen) Betriebssystemen unterstützt wird. Obwohl die HTTP-Bindung optional ist, wird sie fast von allen SOAP-Implementierungen unterstützt, da es sich um das einzige standardisierte Protokoll für SOAP handelt. Aus diesem Grund wird oft fälschlicherweise angenommen, dass SOAP das HTTP-Protokoll erfordert. Obwohl einige Implementierungen MSMQ, MQ Series, SMTP oder TCP/IP-Transporte unterstützen, verwenden fast alle aktuellen XML Web Services HTTP, da es überall verbreitet ist. Da HTTP ein Kernprotokoll im Internet ist, verfügen die meisten Organisationen bereits über eine Netzwerkinfrastruktur, die HTTP unterstützt, und das entsprechende Personal für deren Verwaltung. Die Sicherheits-, Überwachungs- und Lastenausgleichsinfrastruktur für HTTP ist heute überall verfügbar.

Eine Hauptursache für Missverständnisse beim Einstieg in SOAP ist der Unterschied zwischen der SOAP-Spezifikation und den vielen Implementierungen der SOAP-Spezifikation. Die meisten Benutzer von SOAP schreiben SOAP-Nachrichten nicht direkt, sondern verwenden ein SOAP-Toolkit zur Erstellung und Analyse von SOAP-Nachrichten. Diese Toolkits übersetzen im Allgemeinen Funktionsaufrufe von einer bestimmten Sprache in eine SOAP-Nachricht. Beispiel: Das Microsoft SOAP Toolkit 2.0 übersetzt COM-Funktionsaufrufe in SOAP, und das Apache Toolkit übersetzt JAVA-Funktionsaufrufe in SOAP. Die Arten der Funktionsaufrufe und die Datentypen der unterstützten Parameter sind je nach SOAP-Implementierung unterschiedlich, so dass eine Funktion, die mit einem Toolkit funktioniert, eventuell nicht mit einem anderen funktioniert. Dies ist keine Einschränkung von SOAP, sondern vielmehr der spezifischen Implementierung, die verwendet wird.

Bei weitem das beeindruckendste Merkmal von SOAP ist die Tatsache, dass es auf vielen unterschiedlichen Hardware- und Softwareplattformen implementiert wurde. Dies bedeutet, dass SOAP zur Verbindung unterschiedlicher Systeme innerhalb und außerhalb Ihrer Organisation verwendet werden kann. In der Vergangenheit wurden viele Versuche unternommen, ein gemeinsames Kommunikationsprotokoll zu finden, das für die Systemintegration verwendet werden konnte, jedoch fand keines davon eine so breite Akzeptanz wie SOAP. Woran liegt das? Der Grund liegt darin, dass SOAP viel kleiner und viel einfacher zu implementieren ist als viele der früheren Protokolle. DCE und CORBA brauchten beispielsweise Jahre für ihre Implementierung, weshalb nur wenige Implementierungen jemals freigegeben wurden. SOAP hingegen kann vorhandene XML-Parser und HTTP-Bibliotheken nutzen, um einen Großteil der schwierigen Arbeit zu erledigen. Auf diese Weise lässt sich eine SOAP-Implementierung in wenigen Monaten abschließen. Aus diesem Grund stehen bereits mehr als 70 SOAP-Implementierungen zur Verfügung. Natürlich kann SOAP nicht alles, was DCE oder CORBA können, aber es ist diese Simplizität kontra Funktionsvielfalt, die SOAP so populär macht.

Es ist anzumerken, dass Microsoft den Service für das SOAP-Toolkit zugunsten .NET Framework eingestellt hat.

«The Microsoft® SOAP Toolkit is deprecated by the .NET Framework. The toolkit provides basic Web services capabilities for COM components and applications. SOAP Toolkit support will be retired on July 1, 2004....» zu lesen unter The Microsoft® SOAP Toolkit

Links

Persönliche Werkzeuge