Seite 2: Theorie und Praxis

Inhaltsverzeichnis

ESB – die Theorie

Der Begriff ESB wurde laut Wikipedia 2002 durch Gartner für eine neue Kategorie von Software geprägt. Das schließt natürlich nicht aus, dass schon vorher Produkte mit ähnlichen Eigenschaften existierten. Mit den Veröffentlichungen "Enterprise Integration Patterns" (EIP) und "Staged Event Driven Architecture" (SEDA) kam dann ein theoretisches Fundament hinzu, auf das sich praktisch alle ESB-Hersteller berufen.

Die beiden Veröffentlichungen ergänzen sich gut: Enterprise Integration Patterns bilden die Außensicht, mit ihrer Hilfe definiert man den Daten- und Kontrollfluss im ESB. SEDA dagegen ist ein Architekturvorschlag (nicht nur) für ESBs.

Doch zuerst zu den Patterns. Für eine Kopplung muss man meist mehrere nutzen, selbst bei einem einfachen Fall, einer 1:1-Kopplung zweier Systeme,benötigt man mindestens zwei, oft drei Patterns:

1. ein Eingang, zum Beispiel ein HTTP-Server.
2. ein Transformator, der das Datenformat umwandelt. (Dieser Teil kann entfallen, falls beide Systeme das gleiche Datenformat nutzen.)
3. ein "Sender", der die transformierten Daten an ein anderes System schickt, zum Beispiel über eine JMS-Queue (Java Messaging Service).

Die Einzelteile könnte man daher auch Bausteine statt Patterns nennen. Verbunden sind sie in der grafischen Darstellung (s. Abb. 1) durch Pfeile, die den Nachrichten- und Kontrollfluss im ESB symbolisieren.

Im Beispiel beginnt die Aktivität des ESB durch einen ankommenden HTTP-Request. Aus diesem wird eine Nachricht gebaut, die entlang der Pfeile durch den ESB wandert, bis am Ende eine Nachricht über eine JMS-Queue (Java Messaging Service) verschickt wird.

Hier kommt SEDA ins Spiel: Nach dem Architekturvorschlag steckt hinter jedem Kasten eine "Stage", die ein Thread (oder mehrere in einem Pool) ausführt. Die Pfeile stehen nicht nur für Nachrichtenfluss, sondern auch für Warteschlangen, sodass sich vor jeder Stage Nachrichten stauen können. Nach der reinen SEDA-Lehre dürfen in den einzelnen Schritten keine blockierenden Aktionen (z. B. Warten auf ein anderes System bei einem Aufruf) vorkommen, da dadurch Threads "verschwendet" würden. Ein ESB sorgt also dafür, dass man nur wenige Threads benötigt, die aber durchgehend aktiv sind. Sie ruhen nur, wenn ihre Komponente nichts zu tun hat.

ESB – die Praxis

Was lassen die ESB-Hersteller von der Theorie in der Praxis übrig? Auf jeden Fall bunte Bilder, die sind – alleine aus Marketingsicht – wichtig. Zu den Bildern gehört natürlich auch ein grafisches Modellierungstool (gerne in Eclipse integriert), mit dem sich die Bilder per Drag & Drop zusammenbauen lassen. Das ist als Übersicht nett, enthält aber nicht die ganze Wahrheit: Hinter den einzelnen Kästchen stecken meist in der Grafik nicht sichtbare Konfigurationsparameter.

Was heute oft auf der Strecke bleibt, ist SEDA. Dahinter steckt keine Faulheit oder Dummheit der ESB-Entwickler, sondern die Erkenntnis, dass sich das Thread-Handling der Betriebssysteme in den letzten zehn Jahren weiterentwickelt hat. Viele Threads sind heute weniger das (Performance-)Problem, eher viele unnötige Thread-Wechsel und Kopieroperationen im Speicher. Schließlich ist Speicherbandbreite heutzutage ein rares Gut, ebenso wie Platz in diversen Caches. Wer trotzdem SEDA möchte, muss die Stages und Warteschlangen dazwischen explizit modellieren.

Wer bunte Bilder verspricht, sollte sie auch liefern: Daher kommt jetzt eine hypothetische Aufgabenstellung, die sich mit zwei konkreten Open-Source-Produkten lösen lässt, den ESBs Mule und JBoss Fuse (für beide gibt es auch kommerziellen Support). Ihre Aufgabe ist es, alle Suchanfragen mit einem gesetzten Header-Feld X von Google ausführen zu lassen, die restlichen von Bing. Das ist eine klassische ESB-Aufgabe, in deren Zentrum das Choice- oder Routing-Pattern steht, in dem mit einer Bedingung eine Entscheidung getroffen wird.

In Abbildung 2 sieht man die Umsetzung mit JBoss Fuse: Links werden HTTP-Anfragen entgegengenommen, der folgende Choice-Router verteilt sie auf Basis der Bedingung an Google (if-Zweig) oder an Bing (else-Zweig).

Dass das Ergebnis der Suche an den ursprünglichen Aufrufer zurückgeschickt wird, muss man sich bei Fuse selbst denken. Der grundsätzliche Aufbau ist gleich, mit folgenden Unterschieden:

• Der Rückweg wird explizit dargestellt.
• Die Bedingungen sind erst zu sehen, wenn man eine Dialogbox für den Choice-Router öffnet.
• Die Symbole orientieren sich eher an Flussdiagrammen als an den EIP-Patterns.

Hinter den ähnlichen grafischen Darstellungen liegt bei beiden Produkten eine ähnliche XML-Datei zum Speichern. Da die XML-Darstellung bei beiden Werkzeugen vor der grafischen Darstellung existierte, lässt sich mit ihr auch gut im XML-Editor arbeiten. Beide erlauben ein Umschalten zwischen den beiden Darstellungen.

Wenn sich – wie bei UML – ein Standard durchgesetzt hätte, könnte man die Projekte zwischen den ESBs sogar austauschen. Es hat dazu mit Java Business Integration (JBI) zwar einen Ansatz gegeben, der sich aber getrost als tot ansehen lässt. Die meisten derzeit verfügbaren ESBs unterstützen ihn nicht.

Das Duo aus grafischer Darstellung und XML ist eine gängige Kombination, die bei guter Umsetzung praktisch ist: Die Grafiken bieten einen schnellen Überblick und sind gerade beim Einstieg in das Thema ESB leichter zu benutzen als XML. Das dahinter liegende XML hat auf der anderen Seite den Vorteil, dass es gut mit Versionsverwaltungen zu verwenden ist: Zwei Versionsstände lassen sich vernünftig über Diff-Werkzeuge vergleichen, auch ein Zusammenführen (Merge) ist möglich, was sich beim Binärformat verbietet.

Sich mit DSLs behelfen

Manche ESBs setzen auf domänenspezifische Sprachen, meistens als interne DSLs in einer Programmiersprache integriert. Ein Tool mit diesem Ansatz ist Apache Camel, dort sogar mit verschiedenen Basissprachen (Java, Scala, Groovy etc.). Eine DSL ist meistens kompakter und bietet – dank Java oder Groovy als Basis – die Turing-Mächtigkeit einer Programmiersprache: Mit Schleifen und Ähnlichem kann man auch komplexere Konfigurationen erzeugen. (Bleibt die Frage, ob das der zuständige Programmierer selbst nach zwei Monaten noch versteht.)

IDE-Unterstützung (Dokumentation in Pop-ups, Autovervollständigung) können sowohl eine DSL als auch XML bieten. Sofern für das XML-Format entsprechende Schema-Dateien vorliegen, bieten gute XML-Editoren einen ähnlichen Komfort wie gute für Java, inklusive Pop-ups mit Dokumentation. Die Kombination einer internen DSL mit einem grafischen Editor ist schwer vorstellbar, dafür ist die DSL wegen der oben erwähnten Turing-Vollständigkeit zu mächtig. Dem Autor ist auch kein ESB bekannt, der diese Kombination unterstützt.

Programmieren durch Konfigurieren ist schön und gut, doch irgendwann ist Schluss mit lustigem Klicken und das Tool an seiner Grenze: Es muss doch wieder von Hand Code geschrieben werden. Dafür existieren Patterns (z. B. Router und Transformator) meistens nicht nur in einer konfigurierbaren Variante, sondern in einer zweiten, bei der an händisch geschriebenen Programmcode delegiert wird. Java-ESBs konfigurieren dann eine Klasse, die ein bestimmtes Interface implementieren muss.

Im weitesten Sinne ist die Arbeit mit einem ESB immer noch Programmierung, oft jedoch auf einer anderen Abstraktionsebene: Es ist nicht immer Java- oder Groovy-Code, sondern viel Programmierung im Sinne des Zusammensteckens fertiger Komponenten. Das war nur ein kurzer Abriss mit Beispielen zweier ESBs. Wer es genauer wissen will: Beide sind Open-Source-Produkte, Ausprobieren kostet nichts.