SOAP

Netzwerkprotokoll
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 12. September 2005 um 16:48 Uhr durch 194.94.24.1 (Diskussion) (Abkürzung für SOAP). Sie kann sich erheblich von der aktuellen Version unterscheiden.
SOAP im TCP/IP-Protokollstapel
Anwendung SOAP
HTTP HTTPS ...
Transport TCP
Netzwerk IP
Netzzugang Ethernet Token
Ring
FDDI ...

SOAP (Simple Object Access Protocoll) ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP stützt sich auf die Dienste anderer Standards, XML zur Repräsentation der Daten und Internet-Protokolle der Transport- und Anwendungsschicht (vgl. TCP/IP-Referenzmodell) zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über HTTP und TCP. Ursprünglich war SOAP die Abkürzung für Simple Object Access Protocol (Einfaches Objekt-Zugriffs-Protokoll), seit Version 1.2 ist SOAP jedoch offiziell keine Abkürzung mehr, da es nicht (nur) dem Zugriff auf Objekte dient.

Geschichtlicher Abriss

Ursprünglich wurde SOAP durch Dave Winer und Microsoft entwickelt, ein erstes Produkt aus dieser Zusammenarbeit ist XML-RPC. Das Ziel war jedoch SOAP, das zum ersten Mal Ende 1999 mit der Unterstützung durch Don Box veröffentlicht wurde. Damals war die Version 0.9 aktuell, die Reaktion der Entwickler jedoch noch sehr zurückhaltend. Später im Jahr 1999 wurde die Version 1.0 veröffentlicht. Das war der Zeitpunkt, an dem die Entwicklung mehr Unterstützung fand. Dies kann man vor allem daran erkennen, dass sich die Firma IBM im Jahr 2000 der Entwicklung von SOAP anschloss, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) SOAP 1.1 als Note beim World Wide Web Consortium (W3C) einreichten. Dabei wurde das Ziel verfolgt, eine Arbeitsgruppe anzustoßen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2. Eine wichtige Änderung ist, dass SOAP keine Abkürzung mehr ist, da sämtliche Deutungen für SOAP, wie "Simple Object Access Protocol" oder "Service Oriented Architecture Protocol", den Sinn von SOAP nicht treffen. Zudem ist es so möglich, SOAP als Namen in den USA anzumelden, eine Abkürzung könnte nicht geschützt werden..

Struktur einer SOAP Nachricht

Eine SOAP-Nachricht ist nach dem Head-Body Pattern modelliert. Im Head-Bereich der Nachricht werden die Metainformationen der Nachricht untergebracht. Diese können Informationen über das Routing der Nachricht, über eine eventuelle Verschlüsselung und / oder über die Zugehörigkeit zu einer Transaktion umfassen.

Im Body der Nachricht sind, wie auch bei HTML, die Nutzdaten untergebracht. Diese Daten müssen vom Empfänger der Nachricht interpretiert werden, mögliche Zwischenstationen können diese auch ignorieren. Die Daten können dabei unter anderem für entfernte Methodenaufrufe, (Fehler-)Meldungen oder reine Daten (z. B. Abbildung einer Klassenstruktur) stehen.

Anschließend können mögliche Anhänge folgen, diese werden abhängig von dem Transportprotokoll an die Nachricht angehängt. Binärdateien (Sound, Video, Grafik etc.) können durch Nutzung von MIME-Mechanismen angebunden werden.

Beispielablauf einer SOAP-Kommunikation

Angenommen es existiert ein Webservice mit dem Namen "CardValidator" zum Validieren von Kreditkarten und vereinfacht erwartet der Server nur eine Kreditkartennummer und das Gültigkeitsdatum der Karte. Der Server würde dann mit "true" oder "false" antworten - je nachdem, ob die Kartendaten gültig sind oder nicht.

Eine gültige Kreditkartennummer sei 1234 5678 9876 5432 und diese Karte sei bis 12/08 (Dezember 2008) gültig. Bei unserem Beispiel-Webservice würde die Methode validate auf dem Server aufgerufen um die Überprüfung durchzuführen. Es könnte folgender Datenaustausch zwischen Client und Server stattfinden:

SOAP-Anfrage vom Client (ohne HTTP-Header):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <ns1:validate soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
           xmlns:ns1="urn:CardValidator">
   <number xsi:type="xsd:string">1234 5678 9876 5432</number>
   <valid xsi:type="xsd:string">12/08</valid>
  </ns1:validate>
 </soapenv:Body>
</soapenv:Envelope>

SOAP-Antwort vom Server (ohne HTTP-Header):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <ns1:validateResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
                   xmlns:ns1="urn:CardValidator">
   <addReturn xsi:type="xsd:string">true</addReturn>
  </ns1:validateResponse>
 </soapenv:Body>
</soapenv:Envelope>                            

Nachteile von SOAP

An diesem einfachen Beispiel wird bereits deutlich, dass SOAP die Menge der zu übertragenden Daten erheblich (ca. Faktor 25 beim Request und Faktor >500 bei der Antwort) aufbläht. Dies ist nicht nur ein Problem der beanspruchten Netzwerkbandbreite, auch das Generieren und Auswerten (Parsen) der Nachrichten erfordert sehr viel Rechenzeit, verglichen mit anderen, einfacheren RPC-Protokollen.

Aussicht

Als Transportschicht diente früher ausschließlich HTTP. In den heutigen Implementationen ist die Transportschicht aber weitgehend abstrahiert und lässt sich fast beliebig austauschen. Neuere Erweiterungen betreffen den Bereich des Transports von binären Daten. Außerdem entstehen viele nützliche Tools zur Entwicklung von SOAP-Clients, aber auch von Serveranwendungen für das Bereitstellen (Deployment) und Managen, resp. Überwachen, der Dienste (Applikationsserver).

Implementierungen

Siehe auch