Relevanz eines Enterprise Service Bus
Seite 3: Fazit
Und die Antwort?
Ist der ESB der Sargnagel aller Integrationsprojekte oder der heilige Gral der Integration? Sicherlich beides nicht. Sobald man drei oder mehr Systeme koppeln muss, sollte man jedoch über den Einsatz eines ESBs nachdenken, bei zwei Systemen (deren Zahl auch in absehbarer Zeit nicht steigt) koppelt man besser "zu Fuß".
Der ESB nimmt einem nicht die politischen Querelen zwischen mehreren Abteilungen ab, sein Baukasten aus verschiedenen technischen Endpunkten, Transformatoren, Routern et cetera vereinfacht jedoch die technische Kopplung der Systeme. Schaut man sich den Klassenpfad von einem Mule- oder Fuse-ESB mit den vielen Open-Source-Komponenten an, erinnert das an Linux-Distributionen: Auch die könnte man sich aus dem Kernel und allen darum drapierten Projekten selbst zusammenstellen. Aber wie groß ist der Aufwand, kompatible Versionen zusammenzusuchen und den notwendigen Integrationskitt dazwischen zu kneten? Diese Arbeit nimmt einem der ESB ab. Dazu kommt Konfigurieren statt Programmieren, sei es nun mit XML, DSL oder grafisch.
Ein weiter Vorteil ist die Verlagerung des Integrationschaos von vielen Systemen und verteilten Adaptern in den ESB. Puristen werden dabei mit einem kanonischen Datenformat den Aufwand tatsächlich von quadratisch auf linear drücken wollen. Realisten sehen vermutlich ein, dass Marketing und Buchhaltung eine komplett andere Sicht auf den Kunden haben und sich nie auf eine gemeinsame Datenstruktur einigen werden. (Ist die Kontonummer oder die E-Mail-Adresse ein Pflichtfeld?) Mit etwas Geschick findet man hier einen Mittelweg. Dank der Werkzeuge im ESB ist das Erstellen von Adaptern meistens einfacher, als wenn man sich alles selbst zusammensuchen muss.
Die Verlagerung der Adapter aus den beteiligten Systemen in die Mitte bietet dazu noch weitere Chancen (die man – zugegebenermaßen – auch mit manuell geschriebenen Adaptern in der Mitte hätte): Release-Termine der gekoppelten Systeme sind nicht mehr zu synchronisieren, da der Adapter zwischen verschiedenen Versionen vermitteln kann. Die Indirektion über den ESB vereinfacht auch Umzüge auf andere Adressen, da sie nur noch an einer zentralen Stelle und nicht in vielen unabhängigen Systemen notwendig ist.
Fazit
Was bleibt noch als "famous last words"? Nicht zu groß starten, lieber klein anfangen, gegebenenfalls auch nicht mit der wichtigsten Stelle im Unternehmen, mit der beim Scheitern direkt die komplette IT lahmgelegt wird. Nicht den Herstellerprospekten glauben, selbst ausprobieren. Gerade Open-Source-Produkte erlauben dies ohne große Beschaffungsbürokratie und Kosten. Bei Vergleichen nicht einfach Features (Endpunkte, Transformatoren etc.) zählen, die sind wegen unterschiedlicher Mächtigkeit oft nicht so einfach vergleichbar.
Viel wichtiger ist es, dass man im Zweifelsfall ohne großen Aufwand eigene Komponenten entwickeln kann, die sich möglichst nahtlos in den ESB einfügen. In einigen Produkten findet man dafür mächtige Wizards, die sogar Eclipse-Plug-ins für den späteren Einsatz mitgenerieren. Und immer die Ruhe bewahren, Integration bleibt schwierig, die Projektpolitik kann einem kein ESB abnehmen.
Dr. Roger Butenuth
hat langjährige Erfahrung in der Entwicklung von Java-Anwendungen. Schwerpunktmäßig beschäftigt er sich mit Parallelität und Infrastrukturthemen wie Mule ESB und ORM. Er arbeitet als Senior Java Consultant bei der codecentric AG.
Literatur
- Gregor Hohpe; Patterns and Best Practices for Enterprise Integration; Addison-Wesley 2003
- Matt Welsh, David Culler, Eric Brewer; SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
- Roger Butenuth; "Enterprise Service Bus mit Mule ESB": Hello World/Bus!
- Kai Wähner; Mittler zwischen den Welten; Freie Integrations-Frameworks auf der Java-Plattform; Artikel auf heise Developer
(ane)
