WSDL
Servicevertrag mit Operationen, Nachrichten, Bindings und Endpoint.
Integration · Prio 9 · Version 4
SOAP / ESB Integrationsschicht
WSDL-basierte Services, XML-Schemas, Routing, Transformation, Orchestrierung, Fehlerkanal und Vertragsstabilitaet.
Kurzverständnis und Systemgrenze
SOAP- und ESB-Landschaften entstanden oft, um Punkt-zu-Punkt-Kopplungen zu reduzieren. In der Praxis enthalten sie aber nicht nur Routing, sondern auch Mapping, Validierung, Anreicherung, Orchestrierung, Fehlerkanal und manchmal versteckte Fachentscheidungen.
WSDL und XSD sind mehr als technische Dateien. Sie beschreiben, welche Daten ein Unternehmen offiziell zwischen Systemen austauscht. Ein neues REST-API kann den Altvertrag nicht ersetzen, wenn die fachliche Semantik der XML-Felder unklar bleibt.
Modernisierung bedeutet hier: Verträge verstehen, kanonische Modelle kritisch pruefen, Consumer identifizieren, Versionierung sauber planen und ESB-Logik schrittweise in klar testbare Adapter oder Prozessdienste ueberfuehren.
Daten- und Verantwortungsgrenze: Die Integrationsschicht besitzt selten die fachliche Wahrheit, aber sie besitzt den technischen Vertrag zwischen Systemen. Eine Aenderung kann viele Konsumenten brechen. Deshalb muss man Versionierung, Transformation und Fehlersemantik ernst nehmen.
Fachliche und technische Darstellung
Wichtige Begriffe und Artefakte
XSD
Schema fuer Request/Response, Typen, Pflichtfelder und Wertebereiche.
SOAP Fault
Standardisierte Fehlerantwort mit technischem oder fachlichem Fehlerinhalt.
Mediation
ESB-Schritt fuer Routing, Mapping, Validierung, Protokollwechsel oder Enrichment.
Typischer Ablauf Schritt für Schritt
- Consumer ruft SOAP Operation mit XML-Request auf.
- ESB validiert XSD, prueft Security und leitet nach Routingregel weiter.
- Transformation uebersetzt Partnerdaten in internes kanonisches Format.
- Backend-Service verarbeitet Anfrage und liefert Response oder Fault.
- ESB protokolliert Correlation-ID, technische Laufzeit und Fehlerkanal.
Ausführliche Praxisbeispiele mit Code und Konfiguration
Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.
WSDL-Auszug fuer BillingService
<wsdl:definitions name="BillingService" targetNamespace="http://example.com/billing/v1">
<wsdl:message name="CreateInvoiceRequest">
<wsdl:part name="payload" element="tns:createInvoiceRequest"/>
</wsdl:message>
<wsdl:portType name="BillingPortType">
<wsdl:operation name="CreateInvoice">
<wsdl:input message="tns:CreateInvoiceRequest"/>
<wsdl:output message="tns:CreateInvoiceResponse"/>
<wsdl:fault name="BusinessFault" message="tns:BusinessFault"/>
</wsdl:operation>
</wsdl:portType>
</wsdl:definitions>
XSLT Mapping von Partner- zu Internformat
<xsl:template match="partnerInvoice">
<bill:createInvoiceRequest>
<bill:customerNumber><xsl:value-of select="customer/id"/></bill:customerNumber>
<bill:invoiceDate><xsl:value-of select="header/date"/></bill:invoiceDate>
<bill:sourceSystem>PARTNER-PORTAL</bill:sourceSystem>
</bill:createInvoiceRequest>
</xsl:template>
Java SOAP Client hinter Port-Interface
public class SoapBillingGateway implements BillingPort {
private final BillingServiceSoap soap;
public InvoiceCreationResult createInvoice(CreateInvoiceCommand command) {
try {
CreateInvoiceResponse response = soap.createInvoice(map(command));
return InvoiceCreationResult.accepted(response.getInvoiceNumber());
} catch (BusinessFault_Exception ex) {
return InvoiceCreationResult.rejected(ex.getFaultInfo().getReasonCode());
} catch (WebServiceException ex) {
throw new IntegrationTimeoutException("Billing SOAP unavailable", ex);
}
}
}
Risiken, Fehlerbilder und Diagnose
| Aspekt | Beschreibung |
|---|---|
| Fachliches Risiko | Unklare Verantwortung fuer Servicevertrag fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem. |
| Technisches Risiko | WSDL und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen. |
| Betriebsrisiko | Fehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert. |
| Migrationsrisiko | Neue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern. |
Typische Fallen:
- Fachliche Logik in XSLT oder ESB-Flows versteckt.
- XSD-Kompatibilitaet gebrochen, weil optionale Felder ploetzlich Pflicht werden.
- SOAP Faults nicht differenziert: fachliche Ablehnung, Validierungsfehler und technischer Timeout werden gleich behandelt.
- Neue REST-Fassade mappt nur Happy Path und vergisst WS-Security, Auditing und Retry-Verhalten.
Modernisierungspfad und geeignete Entwurfsmuster
| Pattern | Einsatz in diesem System |
|---|---|
| Strangler Fig Pattern | Neue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen. |
| Anti-Corruption Layer | Altbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen. |
| Facade | Komplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln. |
| Adapter | Protokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen. |
| Golden Master Test | Bestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen. |
Empfohlene Schritte:
- Baue pro Altservice Consumer-Contract-Tests mit Beispielnachrichten.
- Extrahiere Mappingregeln in dokumentierte, testbare Mapper.
- Fuehre Versionierung mit parallelen Endpunkten oder kompatiblen Schemaerweiterungen ein.
- Nutze Adapter Pattern fuer SOAP-Clients und Anti-Corruption Layer fuer kanonische Altmodelle.
Analysefragen für echte Projekte
- Wer besitzt fachlich die Wahrheit fuer Servicevertrag?
- Welche technische Komponente ist kritisch: WSDL, XSD, SOAP Fault?
- Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
- Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
- Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
- Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
- Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
- Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung
Nimm eine SOAP-Operation und erstelle eine Vertragstabelle: Operation, Request-Felder, Response-Felder, Pflichtlogik, Fault-Typen, bekannte Consumer, Beispiel-XML, Versionierungsrisiko und moderner Zieladapter.