Simple Object Access Protocol (SOAP)
SOAP ist ein standardisiertes, XML-basiertes Protokoll für den Austausch strukturierter Nachrichten zwischen Webdiensten. Es definiert Nachrichtentypen, Bindungen und Fehlerbehandlung und fokussiert auf Interoperabilität über heterogene Systeme.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Fehlkonfigurationen führen zu Sicherheitslücken (z. B. falsche WS-Security-Implementierung)
- Performance-Probleme durch große XML-Payloads
- Vendor-Lock-in durch proprietäre Erweiterungen
- WSDL strikt versionieren und Abwärtskompatibilität beachten
- Sicherheitsrichtlinien zentral verwalten (z. B. Policy-Repositories)
- Nutzlasten minimieren und Streaming/MTOM bei großen Binärdaten nutzen
I/O & Ressourcen
- WSDL-Definitionen und XSD-Schemata
- Sicherheitsanforderungen (z. B. WS-Security-Policy)
- Netzwerk- und Betriebsanforderungen (SLA)
- SOAP-Endpunkte mit dokumentierten WSDL-Verträgen
- Fehlerhafte Nachrichten in Dead-Letter-Queues
- Monitoring-Metriken und Log-Ausgaben
Beschreibung
SOAP (Simple Object Access Protocol) ist ein XML-basiertes Protokoll zum Austausch strukturierter Informationen zwischen Webdiensten. Es definiert Nachrichtentypen, Zugriffsmechanismen und Fehlerbehandlung und ist auf Interoperabilität und formale Vertragsspezifikationen (WSDL) ausgelegt. Es wird besonders in stark regulierten oder legacy-lastigen Umgebungen eingesetzt, wo strikte Typisierung und WS-* Standards wichtig sind.
✔Vorteile
- Hohe Interoperabilität zwischen heterogenen Systemen
- Formale, maschinenlesbare Verträge (WSDL)
- Ausgereifte Standards für Sicherheit und Transaktionen
✖Limitationen
- Hoher Overhead durch XML und umfangreiche Spezifikationen
- Komplexität bei WS-* Standards und Interoperabilität
- Weniger geeignet für leichte, mobil-orientierte APIs
Trade-offs
Metriken
- Mittlere Nachrichtenlatenz
Zeit zwischen Senden und Bestätigung einer SOAP-Nachricht, wichtig für SLAs.
- Fehlerrate / Fault-Rate
Anteil fehlgeschlagener SOAP-Aufrufe bezogen auf Gesamtaufrufe.
- Payload-Größe
Durchschnittliche XML-Nachrichtengröße, relevant für Netzwerk und Parsing-Performance.
Beispiele & Implementierungen
ERP-Anbindung per SOAP
Ein ERP-System stellt SOAP-Services zur Verfügung, um Bestell- und Rechnungsdaten mit externen Partnern auszutauschen.
Banking-Schnittstellen in regulierten Umgebungen
Banken nutzen SOAP und WS-* Standards für streng typisierte, nachverfolgbare Transaktionen zwischen Systemen.
Legacy-Providerschnittstelle
Externer Dienstleister bietet nur SOAP-APIs; interne Systeme integrieren über ESB und Adapter.
Implementierungsschritte
WSDL-Verträge entwerfen und versionieren
Sicherheitsanforderungen (WS-Security) festlegen und Infrastruktur bereitstellen
SOAP-Endpunkt implementieren und gegen WSDL testen
Monitoring, Logging und Retry-Strategien einrichten
⚠️ Technische Schulden & Engpässe
Tech Debt
- Veraltete SOAP-Endpunkte ohne aktuelle Sicherheitsupdates
- Fehlende WSDL-Versionierung in produktiven Schnittstellen
- Legacy-Adapter mit manuellen Anpassungen statt wiederverwendbarer Transformationsregeln
Bekannte Engpässe
Beispiele für Missbrauch
- SOAP für einfache, öffentliche RESTful APIs verwenden (unnötiger Overhead)
- Schutzmechanismen abschalten, um Performance zu gewinnen
- WSDL-Änderungen ohne Koordination ausrollen
Typische Fallen
- Inkompatible WS-* Implementierungen zwischen Parteien
- Fehlende Idempotenz bei Retry-Strategien
- Übermäßige Nutzung großer XML-Payloads ohne Streaming
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Erforderliche Infrastruktur für WS-Security und Zertifikatsmanagement
- • Legacy-Systeme mit festen WSDL-Verträgen
- • Performance-Anforderungen bei hohem Durchsatz