Jedes große tschechische Unternehmen hat ein IT-Museum in sich. Einen Mainframe aus den Neunzigern, den niemand neu starten kann. Ein COBOL-Programm, dessen Autor seit fünf Jahren in Rente ist. Und irgendwo dazwischen ein Dutzend Java-Anwendungen, die miteinander kommunizieren müssen. Genau das ist es, was wir mit unserem SOA-Ansatz angehen — und hier ist, was wir gelernt haben.
Das Problem: Ein Systeme-Gulasch¶
Unser typischer Kunde — sagen wir eine mittelgroße Versicherungsgesellschaft — hat ungefähr diese Technologielandschaft: ein Kernversicherungssystem auf AS/400, CRM in .NET, Buchhaltung in SAP, ein paar Java-Webanwendungen und Excel-Makros, die alles zusammenhalten. Buchstäblich.
Point-to-Point-Integration sieht anfangs einfach aus. System A braucht Daten von System B? Einen Connector schreiben. System C braucht Daten von A und B? Zwei weitere Connectoren. Aber bei 20 Systemen haben Sie potenziell 190 Integrationen, und niemand weiß, was wohin fließt.
ESB als zentrales Nervensystem¶
Enterprise Service Bus ist keine sexy Technologie — kein Startup schreibt über ESB auf Medium. Aber für die Enterprise-Integration ist es das Fundament. Wir verwenden Oracle Service Bus (OSB), weil sich die meisten unserer Kunden im Oracle-Ökosystem befinden.
ESB gibt uns einfache Dinge: Message Routing, Protocol Mediation (SOAP, JMS, File, FTP), Transformation (XSLT, XQuery) und vor allem — einen zentralen Punkt für Monitoring und Logging. Wenn etwas nicht funktioniert, schaut man an einer Stelle nach, nicht in zwanzig Log-Dateien.
Kanonisches Datenmodell — Eine Investition, die sich auszahlt¶
Jedes System hat sein eigenes Datenmodell. Das CRM hat einen Customer mit einer Adresse als String. Das Kernsystem hat einen CLIENT mit der Adresse aufgeteilt in Straße, Stadt und Postleitzahl. SAP hat einen DEBITOR mit einer völlig anderen Struktur. Wenn Sie Daten direkt zwischen Systemen transformieren, ertrinken Sie in Kombinationen.
Deshalb definieren wir ein kanonisches Datenmodell (CDM) — eine gemeinsame Sprache, in die und aus der alles transformiert wird. Ja, das ist Arbeit am Anfang. Ja, die Meetings über das Datenmodell sind langweilig. Aber jedes neue System, das Sie integrieren, braucht nur eine Transformation (in/aus CDM) statt N Transformationen in jedes andere System.
WSDL-First-Ansatz¶
Das mag altmodisch klingen, aber wir erstellen WSDL-Verträge immer zuerst, nicht Code-first. Warum? Weil der Vertrag eine Vereinbarung zwischen Teams ist. Das Backend-Team in Prag und das Frontend-Team in Brünn brauchen eine klare Spezifikation, auf die sie sich vor dem Codieren geeinigt haben.
Wir validieren XSD-Schemata über Schematron für Geschäftsregeln, die sich in XSD nicht ausdrücken lassen. Wir versionieren Services über Namespaces (v1, v2) und pflegen alte Versionen mindestens ein Jahr nach dem Deployment einer neuen. Abwärtskompatibilität ist im Enterprise entscheidend — man kann dem Kunden nicht sagen „schreib deinen Code um, wir haben eine neue Version veröffentlicht.”
Sicherheit: WS-Security¶
In regulierten Umgebungen (Banken, Versicherungen) reicht HTTPS nicht aus. Man braucht WS-Security für Sicherheit auf Nachrichtenebene — Payload-Verschlüsselung, digitale Signaturen, SAML-Token. Oracle Service Bus handhabt dies nativ, aber die Konfiguration ist… sagen wir nicht-trivial.
In unserem letzten Projekt haben wir zwei Wochen nur mit der Einrichtung der gegenseitigen Authentifizierung zwischen OSB und dem Mainframe-System über X.509-Zertifikate verbracht. Es funktioniert, aber es ist nichts für Zartbesaitete. Die Dokumentation für IBM MQ + Oracle OSB Interoperabilität ist spärlich, um es diplomatisch auszudrücken.
Monitoring und Governance¶
SOA bereitzustellen ist eine Sache. Sie zu verwalten eine andere. Ohne Governance wird Ihre SOA-Landschaft innerhalb eines Jahres in dasselbe Chaos verfallen, aus dem Sie zu entkommen versuchten.
Wir haben einfache Regeln: Jeder Service hat einen Eigentümer (sowohl geschäftlich als auch technisch), einen SLA-Vertrag mit definierter Antwortzeit und Verfügbarkeit, und ist in einem Service Repository registriert. Wir nutzen Oracle Enterprise Repository, aber ehrlich gesagt — selbst ein gemeinsamer Confluence-Bereich ist besser als nichts.
Was ich anders machen würde¶
REST. Ich weiß, dass ich in meinem letzten Artikel SOAP verteidigt habe. Und für komplexe Enterprise-Integrationen gilt das nach wie vor. Aber für einfachere Services — Nachschlagedaten, Benachrichtigungen, einfaches CRUD — würde ich heute REST wählen. Es gibt keinen Grund, den SOAP-Overhead mitzuschleppen, wo man den WS-*-Stack nicht braucht.
Und Testing. Wir haben zu spät begonnen, das automatisierte Testen von SOA-Services anzugehen. SoapUI-Tests sollten vom ersten Tag an Teil der CI-Pipeline sein. Regressionstests für Integrationspunkte sind kritisch — eine kleine Änderung in einem System und die gesamte Integration bricht zusammen.
SOA ist nicht tot¶
In der Community wird darüber gesprochen, dass SOA überholt sei. Für Startups vielleicht. Aber für eine tschechische Versicherungsgesellschaft mit einem Mainframe von 1995 ist solide SOA-Integration über ESB immer noch der praktischste Weg, Systeme zu verbinden, die nie miteinander kommunizieren sollten. Und genau das ist es, was wir tun.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns