Enterprise Service Bus: Zentrale Plattform für Transport, Umwandlung und Weiterleitung

Integration

Enterprise Service Bus

Zentrale Plattform für Transport, Umwandlung und Weiterleitung

Die Idee und ihr Nutzen

Eine Versicherung führt ihre Verträge in einem Bestandssystem. Legt ein Makler im Maklerportal der Versicherung einen neuen Vertrag an, muss das Bestandssystem den Vertrag speichern. Danach muss die Druckstraße, eine Anlage für den Massendruck von Briefen, den Vertragsbrief drucken. Die drei Systeme verwenden unterschiedliche Datenformate und unterschiedliche Übertragungswege. Das Bestandssystem erwartet zum Beispiel Datensätze, in denen jede Angabe an einer festen Zeichenposition steht, und die Druckstraße liest nur Dateien aus einem Verzeichnis. Alle Systeme der Versicherung schicken ihre Nachrichten deshalb nicht direkt einander zu, sondern an eine zentrale Plattform. Die Plattform übersetzt jede Nachricht in das Format des Empfängers und leitet sie an ihn weiter. Jedes System braucht so nur eine einzige Verbindung, nämlich zur Plattform, auch wenn es mit vielen anderen Systemen Daten austauscht. Diese Plattform heißt Enterprise Service Bus, kurz ESB. „Bus“ bedeutet in der Technik eine gemeinsame Leitung, an die alle Geräte angeschlossen sind; beim Enterprise Service Bus sind Maklerportal, Bestandssystem und Druckstraße an dasselbe Programm angeschlossen.

Bausteine: Maklerportal: eigenes Datenformat; Enterprise Service Bus: nimmt Nachrichten an, übersetzt sie, leitet sie weiter; Bestandssystem: eigenes Datenformat; Druckstraße: liest Aufträge nur aus Dateien. Verbindungen: Maklerportal — Enterprise Service Bus; Enterprise Service Bus — Bestandssystem; Enterprise Service Bus — Druckstraße. Alle Systeme sind nur mit dem Enterprise Service Bus verbunden; er übersetzt jede Nachricht in das Format des Empfängers.

Wie funktioniert es?

Ein Makler legt im Maklerportal einen neuen Hausratvertrag an. Das Maklerportal schickt die Vertragsdaten mit der Kundenadresse an den Enterprise Service Bus, nicht direkt an das Bestandssystem. Der Bus wandelt die Nachricht in das Format des Bestandssystems um und übermittelt dem Bestandssystem den Auftrag „Vertrag anlegen“. Das Bestandssystem legt den Vertrag an und meldet die neue Vertragsnummer an den Bus zurück. Aus Vertragsnummer und Kundenadresse erzeugt der Bus einen Druckauftrag und legt ihn als Datei in das Druckverzeichnis, aus dem die Druckstraße ihre Aufträge liest. Die Druckstraße druckt den Vertragsbrief. Das Maklerportal kennt weder das Format des Bestandssystems noch das Druckverzeichnis. Ebenfalls an den Bus angeschlossen sind die Buchhaltung und das Schadensystem, in dem die Versicherung ihre Schadenfälle bearbeitet. Mit dem neuen Hausratvertrag haben Buchhaltung und Schadensystem nichts zu tun.

Jedes angeschlossene System hat sein eigenes Datenformat und seinen eigenen Übertragungsweg:

Das Bestandssystem läuft auf einem Großrechner und arbeitet mit Datensätzen fester Länge, bei denen jede Angabe an einer festgelegten Zeichenposition steht, etwa die Postleitzahl immer an den Zeichen 41 bis 45.
Das Maklerportal tauscht Daten über Webdienste aus, also über Aufrufe, die ein Programm über das Netz an ein anderes richtet.
Die Druckstraße liest Dateien aus einem Verzeichnis.
Die Buchhaltung empfängt Nachrichten über eine Warteschlange, einen Zwischenspeicher, in dem Nachrichten warten, bis der Empfänger sie abholt.

Der Bus kann folgende Aufgaben übernehmen:

Transport: Der Bus nimmt Nachrichten über viele Übertragungswege an und gibt sie über viele Übertragungswege aus. Solche Übertragungswege sind etwa Dateien in einem Verzeichnis, Aufrufe von Webdiensten, Warteschlangen oder Einträge direkt in einer Datenbank.
Übersetzung: Der Bus wandelt Formate um. Er macht zum Beispiel aus einem Datensatz fester Länge vom Großrechner eine Nachricht in einem der verbreiteten Textformate XML oder JSON, und umgekehrt.
Weiterleitung: Der Bus entscheidet anhand von Regeln, an welchen Empfänger eine Nachricht geht. Eine Regel legt zum Beispiel fest, dass Nachrichten über Beitragszahlungen an die Buchhaltung gehen.
Ablaufsteuerung: Der Bus führt mehrere Schritte nacheinander aus, so wie beim Hausratvertrag.
Gemeinsame Aufgaben: Der Bus protokolliert alle Nachrichten, prüft Zugriffsrechte und wiederholt gescheiterte Übertragungen.

Häufig verantwortet ein eigenes Integrationsteam den Bus mit seinen Übersetzungs- und Weiterleitungsregeln, während verschiedene Teams die einzelnen Systeme verantworten. Die Versicherung muss ausdrücklich festlegen, wer was tut, etwa wer die Übersetzungsregel anpasst und testet, wenn das Bestandssystem sein Format ändert. Fachliche Regeln gehören nicht in den Bus, sondern in die angeschlossenen Systeme, deren Teams diese Regeln verstehen und testen können. Eine solche Regel legt zum Beispiel fest, welche Verträge einen Begrüßungsbrief erhalten.

Ist das Bestandssystem kurzzeitig nicht erreichbar, kann der Bus die Übertragung später wiederholen, ohne dass das Maklerportal eingreifen muss. Bis das Bestandssystem die Vertragsnummer gemeldet hat, ist der Vertrag nicht angelegt, auch wenn der Bus die Nachricht des Maklerportals schon angenommen hat. Der Bus erzeugt deshalb erst nach dieser Rückmeldung einen Druckauftrag, und das Maklerportal darf dem Makler erst dann einen angelegten Vertrag anzeigen, wenn die Vertragsnummer vorliegt.

Beteiligte: Makler: legt einen Hausratvertrag an; Maklerportal: schickt Vertragsdaten an den Bus; Enterprise Service Bus: übersetzt Formate, leitet weiter, steuert den Ablauf; Bestandssystem: legt Verträge an, eigenes Datenformat; Druckstraße: druckt Briefe aus Dateien im Druckverzeichnis. Ablauf: 1. Ein Makler legt im Maklerportal einen neuen Hausratvertrag an. 2. Das Maklerportal schickt Vertragsdaten und Kundenadresse an den Enterprise Service Bus, nicht direkt an das Bestandssystem. 3. Der Enterprise Service Bus wandelt die Nachricht in das Format des Bestandssystems um. 4. Der Enterprise Service Bus übermittelt dem Bestandssystem den Auftrag „Vertrag anlegen“. 5. Das Bestandssystem legt den Vertrag an und meldet die neue Vertragsnummer an den Bus zurück. 6. Der Enterprise Service Bus erzeugt aus Vertragsnummer und Kundenadresse einen Druckauftrag und legt ihn als Datei in das Druckverzeichnis, aus dem die Druckstraße ihre Aufträge liest. 7. Die Druckstraße druckt den Vertragsbrief. Das Schadensystem und die Buchhaltung sind ebenfalls an den Bus angeschlossen, haben mit diesem Vorgang aber nichts zu tun. Stecken später zu viele fachliche Regeln im Bus, braucht jede Änderung eine Abstimmung mit dem Integrationsteam, das den Bus verantwortet.

Wann ist es sinnvoll und wann nicht?

Ein Enterprise Service Bus lohnt sich

Viele technisch sehr unterschiedliche Altsysteme müssen verbunden werden. Ohne Bus braucht jede direkte Verbindung ihre eigene Übersetzung, ihre eigene Fehlerbehandlung und ihre eigene Überwachung. Tauschen zehn Systeme alle miteinander Daten aus, braucht jedes Paar von Systemen eine eigene Verbindung. Das sind 45 Verbindungen, denn jedes der zehn Systeme ist mit neun anderen verbunden, und jede Verbindung gehört zu zwei Systemen. Mit Bus sind es zehn.
Die Systeme lassen sich kaum noch ändern. Das gilt vor allem für das Bestandssystem auf dem Großrechner und die Druckstraße. Ohne Bus müsste jedes System, das dem Bestandssystem Daten schickt, selbst Datensätze fester Länge erzeugen. Der Bus übersetzt in die Formate dieser beiden Systeme, ohne dass das Bestandssystem oder die Druckstraße angepasst werden müssen.
Ein System soll sein Datenformat ändern können, ohne dass jede Verbindung zu diesem System angepasst wird. Ohne Bus müsste bei einer Formatänderung des Bestandssystems jedes System angepasst werden, das mit dem Bestandssystem Daten austauscht. Ändert das Bestandssystem sein Format, passt das Integrationsteam nur die Übersetzung im Bus an.
Gemeinsame Aufgaben wie die Protokollierung aller Nachrichten und die Prüfung von Zugriffsrechten sollen für alle Verbindungen auf dieselbe Art erledigt werden. Ohne Bus weiß bald niemand mehr, welche Daten wohin fließen. Mit den Protokollen des Busses kann das Integrationsteam nachvollziehen, welche Daten vom Maklerportal zum Bestandssystem und zur Druckstraße geflossen sind.
Die Abläufe, die über den Bus laufen, ändern sich selten, und ein Integrationsteam verantwortet die Verbindungen. Jede Änderung an einem Ablauf muss nämlich das Integrationsteam umsetzen. Bei seltenen Änderungen müssen die Teams der angeschlossenen Systeme deshalb selten auf das Integrationsteam warten.

Ein Enterprise Service Bus ist nicht das Richtige

Die Teams der angeschlossenen Systeme wollen unabhängig voneinander und häufig neue Versionen ausliefern. Mit einem zentralen Bus wartet dann jede Änderung an einem Ablauf, bis das Integrationsteam sie umgesetzt hat. Das Team des Maklerportals will zum Beispiel ein neues Feld an das Bestandssystem schicken und muss warten, bis das Integrationsteam die Übersetzungsregel angepasst und getestet hat. Stattdessen bauen die Teams ihre Systeme als Microservices, also als viele kleine Dienste, die jedes Team getrennt ausliefert. Jeder Dienst übersetzt selbst, enthält seine fachlichen Regeln und protokolliert seine Nachrichten. Die Nachrichten überträgt zum Beispiel ein Nachrichtensystem nach dem Ansatz Messaging, ohne sie umzuwandeln. Jedes Team ändert so seine Übersetzung selbst, ohne sich mit einem Integrationsteam abzustimmen. Das setzt voraus, dass die Teams ihre Systeme selbst ändern können, etwa weil die Systeme neu gebaut werden.
Nur wenige Systeme mit ähnlichen Formaten tauschen Daten aus. Tauschen drei Systeme alle miteinander Daten aus, sind das drei direkte Verbindungen, mit Bus ebenfalls drei. Dann verbinden die Teams diese Systeme direkt miteinander, und jedes System protokolliert seine Nachrichten und wiederholt gescheiterte Übertragungen selbst. Betrieb und Absicherung eines Busses auf mehreren Servern und ein eigenes Integrationsteam entfallen. Braucht eine dieser Verbindungen eine Übersetzung, übernimmt das ein Message Translator, ein Programmbaustein, der die Nachrichten des einen Systems in das Format des anderen übersetzt.

Nachteile und typische Fehler

Weil viele Verbindungen über den Bus gehen, muss er auf mehreren Servern gleichzeitig laufen, damit der Ausfall eines Servers nicht alle Verbindungen unterbricht. Auf jedem dieser Server läuft ein Exemplar desselben Busses mit denselben Übersetzungs- und Weiterleitungsregeln, sodass jedes Exemplar jede Nachricht bearbeiten kann. ESB-Plattformen bestehen oft aus vielen Bausteinen mit eigenen Einstellungen und brauchen spezialisierte Fachleute für Betrieb und Weiterentwicklung. Wer die Übersetzungsregeln des Busses schreibt, muss wissen, was jedes Feld bedeutet, zum Beispiel welches Feld in der Nachricht des Maklerportals die Kundenadresse ist und welches die Anschrift des Maklers. Bei jeder Änderung an einem Datenformat muss deshalb auch das Integrationsteam mitarbeiten. Hat das Integrationsteam gerade keine Zeit, wartet zum Beispiel das Team des Bestandssystems mit seiner Formatänderung. Mit den Jahren kommen Abläufe hinzu und mit ihnen der Aufwand, sie zu dokumentieren, zu testen und zu überwachen.

Typische Fehler und woran man sie erkennt:

Ausfall des Busses: Das Integrationsteam spielt ein fehlerhaftes Update auf allen Servern des Busses ein, und alle Exemplare des Busses fallen zugleich aus. Dann stehen alle Verbindungen still, die über den Bus laufen: Das Maklerportal kann keine Verträge mehr übergeben, und Druckstraße und Buchhaltung erhalten keine Aufträge. Erkennbar ist das an Fehlern im Maklerportal, in der Druckstraße und in der Buchhaltung zur selben Zeit.
Fachliche Regeln im Bus: Das Integrationsteam baut Regeln wie die zum Begrüßungsbrief in die Abläufe des Busses ein. Die Teams der angeschlossenen Systeme finden diese Regeln nicht in ihrem eigenen Code und können sie nicht selbst testen. Nach zehn Jahren enthält der Bus der Versicherung 400 Abläufe wie den für den Hausratvertrag, und in vielen davon stecken fachliche Regeln. Jede Änderung an einer dieser Regeln muss das Integrationsteam umsetzen, und die Änderungswünsche aller Teams warten beim Integrationsteam. Erkennbar ist das, wenn eine Änderung am Maklerportal eine Abstimmung mit dem Integrationsteam braucht, obwohl sich an den Datenformaten nichts ändert. Die Versicherung verlagert die fachlichen Regeln deshalb schrittweise zurück in die angeschlossenen Systeme und nutzt den Bus nur noch für Transport und Übersetzung.
Falsch übersetztes Feld: Die Nachricht des Maklerportals enthält neben der Kundenadresse auch die Anschrift des Maklers. Das Integrationsteam kennt die Bedeutung der beiden Felder nicht genau und ordnet in der Übersetzungsregel für den Druckauftrag die Anschrift des Maklers zu. Der Bus schreibt dann in jeden Druckauftrag die Anschrift des Maklers statt der Kundenadresse. Erkennbar ist das an Vertragsbriefen, die an die falsche Anschrift gehen.
Unbemerkt liegen gebliebene Druckaufträge: Der Bus legt den Druckauftrag als Datei in das Druckverzeichnis und wertet das als Erfolg. Die Druckstraße kann die Datei aber nicht lesen, etwa weil die Übersetzungsregel nach einer Änderung ein Feld in der falschen Länge schreibt. Die Druckstraße meldet dem Bus nichts zurück, weil sie nur Dateien aus dem Verzeichnis liest. Erkennbar ist das an Dateien, die im Druckverzeichnis liegen bleiben, während Makler nach fehlenden Vertragsbriefen fragen.

Weiterführend

Werkzeuge und Umsetzungen

Apache Camel: Programmbibliothek mit mehreren hundert Anbindungen an Systeme und Übertragungswege. Camel lässt sich als Grundlage eines zentralen Busses oder innerhalb einzelner Dienste einsetzen.
WSO2 Micro Integrator: Integrationsplattform mit Übersetzung, Weiterleitung und Ablaufsteuerung.
Apache Synapse: Enterprise Service Bus für die Vermittlung und Übersetzung von Nachrichten.
Mule: Integrationsplattform. Das Programm, das die Abläufe ausführt, heißt Laufzeitumgebung. Diese Laufzeitumgebung gab es als frei verfügbare Community Edition. Viele Funktionen gibt es nur in der kostenpflichtigen Ausgabe. Der Quellcode der Community Edition liegt öffentlich auf der Plattform GitHub. Er wurde dort im September 2026 archiviert, also schreibgeschützt gestellt. Wie es mit der frei verfügbaren Ausgabe weitergeht, sollte ein Team vor dem Einsatz beim Hersteller klären.

Quellen

David A. Chappell: Enterprise Service Bus: Buch von 2004, das den ESB mit Übersetzung von Formaten, Weiterleitung nach Inhalt und Anbindung von Altsystemen beschreibt.
James Lewis, Martin Fowler: Microservices: Aufsatz von 2014, der kritisiert, dass viele Umsetzungen Weiterleitung, Ablaufsteuerung und fachliche Regeln im ESB verstecken, und stattdessen empfiehlt, dass die Übertragung die Nachrichten nur transportiert und die fachlichen Regeln in den Diensten stehen.
Gregor Hohpe, Bobby Woolf: Message Bus: beschreibt das zugrunde liegende Muster eines gemeinsamen Busses mit gemeinsamem Datenmodell, gemeinsamen Befehlen und gemeinsamer Übertragungstechnik.