In modernen IT-Systemen ist der zuverlässige Austausch von Daten zwischen Anwendungen essenziell. Das SOAP-Protokoll (Simple Object Access Protocol) bietet hierfür eine plattformunabhängige, standardisierte Lösung auf XML-Basis. Es ermöglicht strukturierte Kommunikation über Netzwerke – typischerweise via HTTP.
Im Gegensatz zu REST zeichnet sich SOAP durch umfangreiche Spezifikationen und Erweiterungen wie WS-Security oder WS-ReliableMessaging aus. Es eignet sich besonders für komplexe, unternehmenskritische Systeme mit hohen Anforderungen an Sicherheit und Transaktionssicherheit.
Obwohl moderne REST-APIs in vielen Bereichen dominieren, bleibt SOAP in komplexen Unternehmensumgebungen wie der Finanzbranche, im Gesundheitswesen oder bei sicherheitskritischen Anwendungen von zentraler Bedeutung. Dies liegt vor allem an den umfangreichen Spezifikationen, die SOAP mitbringt, um Sicherheit, Transaktionen und Nachrichtenrouting zu ermöglichen.
Die folgende Darstellung beleuchtet die Grundlagen, die Funktionsweise sowie ein Beispiel zur Nutzung von SOAP-Webservices.
Historischer Hintergrund und Motivation
SOAP wurde ursprünglich von Microsoft entwickelt und im Jahr 1999 als offener Standard veröffentlicht. Ziel war es, einen einheitlichen Mechanismus zur Kommunikation zwischen Systemen unterschiedlicher Plattformen und Technologien zu schaffen – ohne auf proprietäre Lösungen angewiesen zu sein. SOAP wurde später von der W3C (World Wide Web Consortium) übernommen und weiterentwickelt.
Im Gegensatz zu REST, das einen ressourcenbasierten Ansatz verfolgt, ist SOAP eine klassische Remote Procedure Call (RPC)-Lösung, bei der Methoden auf entfernten Servern aufgerufen und deren Ergebnisse zurückgegeben werden – verpackt in eine strukturierte XML-Nachricht.
Aufbau und Struktur einer SOAP-Nachricht
SOAP-Nachrichten sind vollständig in XML geschrieben und bestehen aus vier Hauptkomponenten.
Envelope
Der Umschlag der Nachricht – definiert den Beginn und das Ende der Nachricht und enthält alle weiteren Informationen.
Body
Der Hauptinhalt der Nachricht – enthält die eigentlichen Daten oder Funktionsaufrufe.
Optionaler Header
Enthält Metainformationen wie Sicherheitsangaben, Transaktionsinformationen oder Routinganweisungen.
Optionaler Fault
Wird verwendet, um Fehler oder Ausnahmen zu beschreiben, wenn etwas bei der Verarbeitung der Nachricht schiefläuft.
Ein einfaches SOAP-Beispiel (XML)
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- Optionale Header-Informationen -->
</soap:Header>
<soap:Body>
<m:GetUser xmlns:m="http://example.com/users">
<m:UserId>123</m:UserId>
</m:GetUser>
</soap:Body>
</soap:Envelope>
Das Kommunikationsmodell von SOAP
SOAP unterstützt zwei grundlegende Kommunikationsmuster, das RPC und das WSDL.
Die RPC (Remote Procedure Call)
Der Client ruft explizit eine Methode auf dem Server auf.
Der Documenten Stil
Die Nachricht übermittelt ein XML-Dokument als Payload, ohne dass konkrete Methoden definiert sind.
Zusätzlich unterstützt SOAP sowohl synchronen als auch asynchronen Nachrichtenaustausch, was besonders in Enterprise-Architekturen mit Message Queues oder ESB-Systemen (Enterprise Service Bus) genutzt wird.
Transportprotokolle und Bindungen
Obwohl SOAP am häufigsten über HTTP (genauer gesagt POST-Anfragen) transportiert wird, ist es nicht darauf beschränkt. Es kann auch über andere Protokolle wie SMTP, FTP oder sogar JMS (Java Message Service) gesendet werden. Die sogenannte „SOAP Binding“ definiert, wie genau SOAP mit einem Transportprotokoll interagiert.
Die SOAP over HTTP-Bindung ist jedoch die am weitesten verbreitete Form, da sie gut mit existierender Infrastruktur wie Firewalls und Proxies zusammenarbeitet.
WSDL – Die Schnittstellenbeschreibung
Ein zentrales Element der SOAP-Architektur ist die WSDL (Web Services Description Language). Dabei handelt es sich um ein standardisiertes XML-Format zur Beschreibung von Webservices, das sowohl die verfügbaren Operationen (Methoden), deren Parameter und Rückgabewerte als auch das Protokoll (Binding), die Adresse des Services (Endpoint) und die Nachrichtenstruktur definiert.
Eine typische WSDL-Datei gliedert sich in Abschnitte
Types
Definition komplexer Datentypen (z. B. mittels XML Schema).
Message
Definition der Nachrichten (Input/Output).
PortType
Logische Schnittstellenbeschreibung mit Methoden.
Binding
Verknüpfung der logischen Schnittstelle mit einem Transportprotokoll.
Service
Definition der eigentlichen Adresse (Endpoint), unter der der Dienst erreichbar ist.
Die Verwendung einer WSDL-Datei ermöglicht es Entwicklern, automatisch Client-Proxies zu generieren – z. B. mit wsimport in Java oder dem „Add Service Reference“-Tool in .NET.
Methoden und Operationen in SOAP
SOAP selbst kennt keine HTTP-Methoden wie GET oder POST, sondern verwendet ausschließlich POST-Anfragen, bei denen die spezifische Operation in der XML-Struktur im Body definiert ist. Typische Methoden im Sinne der Schnittstellennutzung sind in der Regel die folgenden (ähnlich den CRUD-Operationen).
Create
Erstellen eines neuen Objekts (z. B. CreateUser)
Read
Abfragen von Informationen (z. B. GetUser, ListUsers)
Update
Ändern eines bestehenden Objekts (z. B. UpdateUser)
Delete
Löschen eines Objekts (z. B. DeleteUser)
Diese Operationen werden innerhalb der WSDL als sogenannte portType-Operationen definiert und später mittels XML implementiert.
Sicherheit in SOAP
SOAP unterstützt durch Erweiterungen wie WS-Security sehr umfangreiche Sicherheitsmechanismen:
Vertraulichkeit
Verschlüsselung des Nachrichteninhalts.
Integrität
Digitale Signaturen garantieren, dass Nachrichten nicht verändert wurden.
Authentifizierung
Benutzeridentifikation über Tokens, Zertifikate oder Benutzername/Passwort.
Zugriffssteuerung
Rollen- und regelbasierte Zugriffsbeschränkungen.
Gerade diese starke Unterstützung für Standardsicherheit ist ein Grund dafür, dass SOAP heute noch in sicherheitskritischen Systemen verwendet wird, in denen REST mit seinen einfacheren Mitteln nicht ausreicht.
Vor- und Nachteile von SOAP
Vorteile
Plattformunabhängigkeit und Interoperabilität.
Umfangreiche Standards (WS-*) für Sicherheit, Transaktionen und Routing.
Automatisierte Codegenerierung durch WSDL.
Eindeutige Struktur und Formalisierung der Nachrichten.
Nachteile
Hoher Overhead durch XML-Struktur.
Komplexität der Spezifikationen.
Weniger geeignet für leichtgewichtige Anwendungen oder mobile Clients.
Nur POST-Anfragen – kein nativer Support für HTTP-GET.
Ein Beispiel, um Benutzerinformationen über SOAP abzurufen
Nehmen wir an, ein Webservice stellt eine Methode GetUser zur Verfügung, die Informationen zu einem Benutzer mit einer bestimmten ID zurückgibt. Die WSDL-Datei beschreibt die nachfolgende Methode.
WSDL-Auszug (XML)
<wsdl:operation name="GetUser">
<wsdl:input message="tns:GetUserRequest"/>
<wsdl:output message="tns:GetUserResponse"/>
</wsdl:operation>
SOAP Request (XML)
POST /UserService HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://example.com/GetUser"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:usr="http://example.com/users">
<soapenv:Header/>
<soapenv:Body>
<usr:GetUser>
<usr:UserId>123</usr:UserId>
</usr:GetUser>
</soapenv:Body>
</soapenv:Envelope>
SOAP Response (XML)
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUserResponse xmlns="http://example.com/users">
<User>
<Id>123</Id>
<Name>Max Mustermann</Name>
<Email>max@example.com</Email>
</User>
</GetUserResponse>
</soap:Body>
</soap:Envelope>
Fazit
SOAP ist ein mächtiges und formal stark standardisiertes Protokoll für die Kommunikation zwischen Webservices. Trotz der gestiegenen Popularität von REST ist SOAP nach wie vor ein relevanter Standard in vielen Enterprise-Umgebungen, insbesondere dort, wo Sicherheit, Transaktionssicherheit und umfangreiche Schnittstellenbeschreibungen notwendig sind.
Wer in der IT-Welt arbeitet, sollte die Grundlagen von SOAP, WSDL und den SOAP-spezifischen Mechanismen kennen – insbesondere im Hinblick auf Legacy-Systeme, B2B-Integrationen oder systemübergreifende Kommunikation in heterogenen IT-Landschaften.