Was ist ein ESB und wofür kann man ihn nutzen?

Was ist ein ESB? Ein abflauender Hype? Besser als jede Middleware zur Kopplung von IT-Systemen? Die Bezeichnung für sündhaft teure Produkte namhafter Anbieter? Eine hier neu startende Serie von Blog-Artikeln wird hoffentlich etwas Licht in das große Dickicht ESB bringen. Heute geht es erst mal um die Grundlagen und Abgrenzungen. Weitere Artikel werden dann eine praktische Einführung in die Open-Source-Lösung Mule ESB beinhalten. ESB klingt immer nach Riesenprojekten. In dieser Serie soll klar werden, dass sich auch klein starten lässt und ESB-Projekte nach kurzer Zeit schon produktive Vorteile bringen können.

ESB: Was ist das?

Der Begriff ESB ist durch das 2004 erschienene Buch Enterprise Service Bus: Theory in Practice  (David A. Chappel) bekannt geworden. Erfunden hat Chappel den ESB nicht. Er selbst schreibt, dass der Begriff aus einer Gartner-Analyse von 2002 stammt. Der Begriff ESB kann drei verschiedene Dinge bedeuten:

1. Einen Architekturstil
2. Ein Softwareprodukt
3. Konkrete Implementierung (Instanz), z.B. in einem Unternehmen

Was mit dem Kürzel ESB in diesem Blog an verschiedenen Stellen gemeint ist, sollte jeweils aus dem Zusammenhang klar werden. Punkt 1 ist unabhängig von irgendwelchen Produkten, Punkt 2 wird im Blog mit Mule ESB als Beispiel abgearbeitet, es sind aber auch Vergleiche mit anderen Produkten (Open Source und kommerziell) geplant. Punkt 3 ist leider nur mit hypothetischen oder anonymisierten Beispielen möglich, da sich die meisten Unternehmen nicht gerne in die Karten schauen lassen.

Also, was ist ein ESB?  Hangeln wir uns einfach mal an den drei Buchstaben entlang. Zuerst mal ein E für Enterprise (Unternehmen). Es geht also um Software in einem Unternehmen als Ganzes, nicht um die Software zur Lagerverwaltung oder die Buchführung. Wer jetzt schon politischen Streit zwischen den Abteilungen befürchtet: Ja, auch das gehört bei ESB-Projekten dazu. Der zweite Buchstabe, das S für Service (Dienst) nährt diese Furcht: Die Abteilungen – oder die Software der Abteilungen – sollen sich gegenseitig Dienste zur Verfügung stellen bzw. Dienste nutzen. Der dritte Buchstabe – B für Bus – wird bei wörtlicher Übersetzung klarer: Der Lateiner mag sich erinnern, dass Bus nur die Endung von Omnibus ist, übersetzt „für alle“. Im Idealfall sind alle IT-Lösungen in einem Unternehmen an den ESB angeschlossen. Disclaimer: Word darf auch noch offline genutzt werden. Bei Excel ist es jedoch schon nicht mehr selbstverständlich, wie wir in späteren Beispielen sehen werden.

Fassen wir zusammen:

• Es geht um die IT eines Unternehmens.
• Die einzelnen Teile der IT sollen zusammenarbeiten, über Dienste, die sie sich untereinander zur Verfügung stellen.
• Es ist für alle, nicht nur eine einzelne Software (z.B. Buchhaltung)

Wenn man den Begriff Bus aus der Elektrotechnik kennt (Datenbus, Energieverteilungsbus etc.), sieht man eine gewisse Analogie: Dort werden auch mehrere Verbraucher und Anbieter auf einen gemeinsamen Bus geschaltet. Auch die grafische Darstellung eines ESB wird meist analog zur Elektrotechnik gewählt: Eine dicke waagerechte Linie oder ein breites Rechteck, an den oben (und unten) die einzelnen Komponenten bzw. Softwaresysteme angeschlossen sind.

Damit haben wir auch schon die erste zentrale Eigenschaft der ESB-Architektur: Unterschiedliche Systeme reden nicht direkt miteinander. Stattdessen laufen sämtliche Interaktionen über den Bus. Damit lässt sich die (theoretische) Komplexität verringern: Statt n*(n-1)/2 Verbindungen (falls jedes System mit jedem anderen interagiert) gibt es  nur noch n Verbindungen zwischen den Systemen und dem Bus. In der Praxis wird der Effekt nicht ganz so drastisch ausfallen, da in einem Unternehmen nicht jedes Softwaresystem mit jedem anderen gekoppelt ist. Außerdem ist die grafische Darstellung mit einer kleinen, unschuldigen Linie geschönt: Je nach IT-Landschaft können auf dem Bus komplexe Transformationen stattfinden.

Einige Leser fragen sich jetzt bestimmt, worin sich ESB von Hub and Spoke unterscheidet. In der Grafik ganz einfach: ESB nutzt eine Linie oder ein Rechteck, Hub and Spoke einen Kreis als zentrales Element. Ansonsten interagieren in beiden Fällen n Systeme über n Verbindungen mit einer Zentrale. Der Unterschied liegt in den Daten: Beim ESB wird erwartet, dass auf dem Bus ein einheitliches Datenformat vorliegt. Bei Hub and Spoke reden die einzelnen Systeme in verschiedenen Formaten miteinander. Im worst case benötigt jedes System n-1 Datentransformatoren, wenn es mit allen anderen System redet. Mehr dazu: ESB or not to ESB revisited – Part 2.

Damit haben wir die zweite zentrale Eigenschaft einer ESB-Lösung: Auf dem Bus existiert ein einheitliches Datenformat. Eine Entität „Kunde“ sieht also immer gleich aus, egal ob nun das CRM oder die Buchhaltung damit arbeitet. In dem einheitlichen Format liegt sowohl die größte Chance als auch das größte Risiko von ESB-Projekten: Klappt die Definition eines einheitlichen Formats, braucht man maximal n Adapter, die Formate der einzelnen Systeme in das Bus-Format umwandeln. Auf der anderen Seite können Projekte in einer nicht endenden Debatte über die wesentlichen Eigenschaften eines Kunden scheitern. Technische Unterschiede wie XML versus JSON sind da ganz schnell Details am Rande, wenn sich die verschiedenen Fachabteilungen schon nicht einigen können.

Wie David A. Chappel in seinem Buch schreibt, ist die Welt jedoch nicht schwarz oder weiß: „… you can refactor toward an ESB and away from an accidental architecture in incremental steps.“ Setzt man ein ESB-Produkt ein, das kein einheitliches Format erzwingt, kann man schrittweise die unterschiedliche Formaten vereinheitlichen. Schrittweises Vorgehen ist generell bei der ESB-Einführung empfehlenswert. Das bezieht sich nicht nur auf das Datenformat, sondern auch auf die zu koppelnden Systeme: Klein anfangen, erst mal mit zwei bis drei Systemen starten. Erst wenn man damit Erfolge vorweisen kann, weitere Systeme hinzunehmen. So reduziert man die Zeit, bis erste Erfolge sichtbar sind und hat handfeste Argumente, um die Skeptiker in anderen Abteilungen zu überzeugen.

Von der Architektur zum Produkt

ESB als Architekturstil ist also die Kopplung mehrerer Systeme mit einem gemeinsamen Datenformat (auf dem Bus). Das lässt natürlich noch etwas Interpretationsspielraum dafür, welche Funktionen ein Produkt bieten muss, damit es sich ESB nennen darf. Der Bus muss mit verschiedensten Systemen zusammenarbeiten, von der alten COBOL-Hostanwendung bis zum neumodischen Node.js-Webserver. Zusätzlich tummeln sich in der eigenen IT vielleicht noch ein paar C/C++ oder Java-Anwendungen mit den für sie spezifischen Schnittstellen und Datenformaten. Der ESB muss „die üblichen Verdächtigen“ unter den Schnittstellen unterstützen. Weiterhin muss er (möglichst einfach) um weitere Schnittstellen erweiterbar sein: Nach Murphys Law kann man davon ausgehen, im Laufe eines Integrationsprojekts auf eine Schnittstelle zu stoßen, die das gewählte Produkt gerade nicht unterstützt. Konkrete Schnittstellen sind zum Beispiel: Http-Zugriffe (als Client und als Server), Dateiaustausch (lokal oder per FTP), Corba, RMI, JMS.

Manche Schnittstellen (z.B. SOAP-Webservice) legen ein technisches Datenformat (XML) fest. Andere Schnittstellen (Dateiaustausch) erlauben beliebige Datenformate. Der ESB sollte die Fähigkeit besitzen, diese Formate ineinander umzuwandeln. Das kann komplett implizit funktionieren (XML nach JSON), es kann aber auch mit expliziten Umwandlungen verbunden sein, zum Beispiel mit einem XSLT-Prozessor. Zusätzlich zur Strukturänderung können noch Werte umgewandelt werden, was Bedingungen, Formeln oder Mapping-Tabellen erforderlich macht. Da nicht alle Datentransformationen alleine durch Konfiguration definiert werden können, muss es möglich sein, selbst geschriebene Transformationen in den ESB einzuhängen.

Der innere Aufbau eines ESB kam bisher recht kurz, wir wissen nur, dass er viele Schnittstellen hat und intern Daten von einem in ein anderes Datenformat umwandeln kann. Aber wie spielt das alles zusammen? Zentrales Element innerhalb des ESBs ist die Nachricht (Message). Ein Auftrag oder Aufruf von außen an einer Schnittstelle wird in eine Nachricht verpackt. Die Nachricht läuft dann durch den ESB. An einer anderen Schnittstelle kann die Nachricht dann wieder zu einer Interaktion mit einem weiteren System führen. Die Nachrichten erfüllen zwei wesentliche Funktionen:

1. Sie transportieren die Daten (Nutz- und ggf. Steuerungsdaten)
2. Sie steuern den Ablauf: Sobald sie an einer Komponente (Schnittstelle, Transformator etc.) eintreffen, wird die Komponente aktiv.

Wie sieht es in der Praxis aus? Nehmen wir ein einfaches (und daher nicht ganz realistisches) Beispiel: Ein Batch-System legt in einem Verzeichnis Bilder im Tiff-Format ab. Der ESB soll die Dateien lesen und anschließend die Bilder in einem anderen Verzeichnis im Jpeg-Format ablegen. In der grafischen Sprache von Mule ESB ergibt sich folgende Darstellung:

Links sieht man eine Schnittstelle vom Typ „File“, sie liest Dateien. In der Mitte ist der Transformer, der mit den Daten irgendeine Umwandlung vornimmt, rechts ist wieder eine Schnittstelle vom Typ „File“, die eine Datei schreibt. Es handelt sich hier um eine „one way“ Verarbeitung: Der Absender legt seine Datei ab und kümmert sich nicht um den weiteren Ablauf. Sobald eine Datei vorliegt, kann der ESB sie sofort vollständig verarbeiten, er muss auf keine anderen System warten.

Man könnte eine oder beide Dateischnittstellen gegen andere Schnittstellen austauschen, die Daten „one way“ verarbeiten: Einen JMS-Endpunkt, eine FTP-Komponente, etc. An der Struktur würde sich dadurch nichts ändern. Dem Transformer in der Mitte ist es egal, woher sein linker Nachbar die Daten erhält und wie sein rechter Nachbar sie weiterschickt. Er sieht jeweils die Message, sonst nichts.

Im nächsten Beispiel sieht das Bild noch sehr ähnlich aus, es kommt jedoch ein drittes System ins Spiel:

Wieder wird links eine Datei gelesen und rechts eine Datei geschrieben. In der Mitte wird jedoch zur Verarbeitung ein anderes System per Http angesprochen. Die Nachricht muss in einen Http-Request verwandelt und verschickt werden. Anschließend wartet die Http-Schnittstelle auf eine Antwort, wandelt sie wieder in eine Nachricht um und gibt sie an die rechte Komponente weiter. Dort wird der Inhalt in eine Datei geschrieben. Aus der Sicht des linken und des rechten Systems ist es eine one-way-Verarbeitung. Schaut man genauer hin, erkennt man die zusätzliche request-reply-Interaktion mit einem dritten System.

Jetzt kommt der umgekehrte Fall, die Server-Seite eines „request-reply“:

Der ESB nimmt links einen Http-Request entgegen, lässt ihn von einem Transformer verarbeiten und schickt ein Ergebnis wieder an den ursprünglichen Auftraggeber zurück. (In der Praxis würde der Transformer vermutlich mit einem weiteren System interagieren.) Links ist die Doppelaufgabe der Http-Komponente erkennbar: Sie nimmt zuerst den Request entgegen und wandelt ihn in eine Message um. Am Ende wird aus einer anderen Message ein Reply.

Die Beispiele zeigen sogenannte Enterprise Integration Patterns. Wer in das Thema tiefer einsteigen möchte, findet in dem Buch Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions  (Gregor Hohpe, Bobby Woolf) mehr. Auch die Web-Seite zum Buch ist sehr informativ und enthält eine Übersicht der Patterns.

Ein ESB muss es ermöglichen, die EI-Patterns zu implementieren. Neben den bereits beschriebenen sind noch folgende Pattern sehr gängig:

• Message Router: Leitet die Nachricht basierend auf Regeln an einen von n Empfängern.
• Filter: Lässt basierend auf Regeln nur einige Nachrichten durch und verwirft den Rest.
• Splitter: Teilt eine Nachricht in mehrere auf.

Die EI-Patterns lassen sich theoretisch auch ohne ein Produkt umsetzen, das ESB im Namen trägt. Genau so könnte man seine Anwendungen auch ohne Datenbank implementieren: Geht zwar, ist aber nicht sinnvoll, da man sich in beiden Fällen um zu viele Details selbst kümmern muss. Die Vorteile der ESB-Architektur in Verbindung mit einem ESB-Produkt sind:

1. Man schafft Struktur. Die beteiligten Systeme kümmern sich um ihre Kernaufgaben, die gesamte Integrationslogik findet im ESB statt. Sucht man ein Stück System oder Architektur weiß man dadurch sofort, wo man es suchen muss.
2. Man muss sich weniger um technische Details kümmern. ESB-Produkte bringen typischerweise einen großen Korb an Adaptern und Transformatoren mit, die sich um gängige Probleme kümmern. Das kann sowohl auf niedriger (technischer) Ebene stattfinden (z.B. Corba zu Http), es existieren aber teilweise auch schon fertige Adapter mit fachlicher Anbindung konkreter Anwendungen.

Abgrenzung: Was ist nicht ESB?

Die grafische ESB-Darstellung erinnert manche vielleicht an BPMN, man darf die beiden Ansätze aber nicht verwechseln: BPMN ist für länger laufende Workflows gedacht, die zwischendurch in einer Komponente stoppen und – gegebenenfalls auch länger – auf externe Ereignisse warten. Ein Vorgang kann zum Beispiel im Postkorb eines Sachbearbeiters landen und erst Tage oder Wochen später bearbeitet werden. Es liegt bei BPMN also ein länger existierender Zustand vor. Die Komponenten eines ESB sollten so weit wie möglich zustandslos sein. Der Zustand liegt in den Nachrichten, die den ESB durchlaufen. Eine Ausnahme bilden Komponenten, die eine request-reply-Schnittstelle bedienen. Sie müssen die beiden zuordnen können. Das gilt sowohl für den Fall, dass sie selbst Server sind, als auch für den Fall, dass sie selbst Client sind. BPMN und ESB stehen also trotz der grafischen Ähnlichkeit für unterschiedliche Architekturen, die verschiedene Probleme lösen. Hat man in einem Unternehmen sowohl langlaufende Prozesse als auch Integration vieler Systeme, spricht natürlich nichts gegen den Einsatz beider Systeme. Jedes dabei bitte für seine konkreten Aufgaben.

Viele IT-Landschaften sind langfristig gewachsen und bestehen aus einem bunten Strauß verschiedener Technologien. Bei jungen Unternehmen oder nach aufwändigen Modernisierungen liegt möglicherweise eine homogene Landschaft aus lauter Anwendungen in einer Technologie vor, die untereinander auch noch über eine einheitliche Technik gekoppelt sind, zum Beispiel alle über REST-Services oder alle per JMS. Wenn man nicht plant andere Technologien zu integrieren, kann man mit der Lösung gut leben. Diese einheitliche Kopplung ist jedoch kein ESB.

Wann lohnt ein ESB?

In Richtung ESB sollte man genau dann schielen, wenn ein dazu passendes Problem vorliegt. Ansonsten beschert man der Welt vermutlich ein weiteres gescheitertes ESB-Projekt, ohne dass die ESB-Architektur oder ein konkretes Produkt daran die Schuld trägt. Rob Mason (Gründer von MuleSource) hat im Blog von MuleSoft einen schönen Blog-Post zu dem Thema geschrieben: To ESB or not to ESB. Ich werde hier nur auf die wichtigsten Punkte der dort abgedruckten Checkliste eingehen, sonst könnte ich einfach den Blog-Post übersetzen. Zwei wesentliche Gründe sprechen für den Einsatz eines ESB:

• Es sind (ohne den ESB) mindestens drei Systeme beteiligt. Bei zwei Systemen ist es meistens einfacher, sie direkt miteinander zu koppeln.
• Die Systeme sprechen unterschiedliche Protokolle (HTTP vs. Dateitransfer) und/oder nutzen unterschiedliche Datenformate (XML, JSON, CSV, etc.)

Kein Grund für den Einsatz eines ESB sind ein netter Golf-Nachmittag mit dem Vertriebsmitarbeiter des ESB-Anbieters oder der Wunsch, ein ESB-Projekt im Lebenslauf zu haben.

Wenn es gute Gründe für einen ESB gibt, so gibt es immer noch viele Möglichkeiten zu scheitern. Die Technik an sich spielt dabei in den meisten Fällen die kleinste Rolle. Was man nicht unterschätzen darf sind die politischen Querelen, die mehrere an einem Projekt beteiligte Abteilungen mit sich bringen. Sind viele Systeme – und damit Abteilungen – beteiligt, ist auf jeden Fall ein schrittweises Vorgehen zu empfehlen. Man hat damit schneller Erfolge vorzuweisen und einen frühen Return of Investment. Außerdem kann man die Erfahrungen mit den ersten Systemen bei der Anbindung weiterer Systeme nutzen.

Was kommt jetzt?

Bis hier habe ich es hoffentlich geschafft, den Begriff ESB etwas zu präzisieren. Dies ist nur der Start einer Artikelserie, es werden noch weitere Artikel – nicht nur von mir – folgen. Nicht alle davon werden produktunabhängig sein, der Schwerpunkt wird auf Mule ESB liegen, einer recht weit verbreitete Open Source Lösung. Der nächste Artikel wird daher eine Einführung in die Architektur von Mule ESB und ein erstes „Hello, World!“ bringen. Welche weiteren Details zu Mule ESB folgen, ist noch offen. Auf jeden Falls wird es auch etwas zum Thema Deployment geben. Mule ist nicht das einzige ESB-Produkt. Neben kommerziellen existieren auch noch weitere Open-Source-Lösungen mit dem Label „ESB“, eine Übersicht mit Vergleich wird daher auch Thema sein. Also: Stay tuned…

Weitere Teile dieser Artikelserie

1. Was ist ein ESB und wofür kann man ihn nutzen?
2. Tutorial “Enterprise Service Bus mit Mule ESB”: Hello World/Bus
3. Tutorial “Enterprise Service Bus mit Mule ESB”: MuleMessage und Java-Komponenten
4. Tutorial „Enterprise Service Bus mit Mule ESB“: Nachrichten mit Java transformieren
5. Tutorial „Enterprise Service Bus mit Mule ESB“: Integration von CICS Programmen
6. Tutorial “Enterprise Service Bus mit Mule ESB”: Transport, Connector, Endpoint: Ein paar Grundlagen…
7. Tutorial “Enterprise Service Bus mit Mule ESB”: Performance und Threads
8. Tutorial “Enterprise Service Bus mit Mule ESB”: Steuerung und Kontrolle per JMX
9. Veröffentlichen von Informationen zu Mule Applikationen im Maven-Umfeld
10. Tutorial “Enterprise Service Bus mit Mule ESB”: Exceptions und Email