Top Ten ESB: Viele ESBs, viele Möglichkeiten

Die betrachteten Kandidaten

Die betrachteten ESB-Systeme sind in ihren Ausprägungen derart heterogen, dass man für einen vernünftigen Vergleich diese in Kategorien einteilen muss. Folgende zehn Produkte dürften den aktuellen Open-Source-ESB-Markt weitgehend abdecken: Apache Camel, Apache ServiceMix/Fuse ESB, Apache Synapse/WSO2, ChainBuilder, JBoss ESB, Mule ESB, OpenESB/ GlassFish, Swordfish, Petals ESB, Sopera ASF .

Die Kategorien

Mit Blick auf die reine ESB-Funktionalität der Produkte, also die Architektur des zentralen Message Bus, sind zwei Entwicklungen besonders augenfällig. Zum einen finden sich ESBs, die auf die JBI-Konvention (JSR 208) setzen wie OpenESB, Sopera oder Petals. Zum anderen finden sich ESBs, die diese Java-Spezifikation nicht oder nur zum Teil implementieren, wie etwa der Mule ESB (Custom-Implementierung). Weiter lassen sich folgende Subkategorien für einen sinnvollen Vergleich der ausgewählten Systeme finden (Tabelle 3):

Tabelle 2: Kategorien zur Einteilung der verschiedenen Open Source ESBs

JBI-Implementierung Custom-Implementierung
Apache ServiceMix/Fuse ESB Apache Camel
ChainBuilder JBoss ESB
OpenESB Mule ESB
Petals ESB Synapse/WSO2
Sopera ASF
Swordfish

Tabelle 3: Subkategorien

Frameworkartig Web-Service-basiert Toolsammlung
Apache Camel Synapse/WSO2 ChainBuilder
Mule ESB
Swordfish
  • Frameworkartige ESBs: Das sind ESBs, die zwar auch im Standalone-Betrieb als reine ESBs eingesetzt werden können, sie eignen sich aber im Besonderen auch als SOA/EAI-Integrationsplattformen, die den Anwender durch ihre frameworkartige Beschaffenheit beim Bau komplett neuer Anwendungssysteme unterstützen.
  • Rein auf Web Services ausgelegte ESB: Diese ESBs sind hauptsächlich auf den Betrieb mit Web Services ausgelegt. Legacy-Systeme, die noch nicht über APIs für Web Services verfügen, lassen sich hier bedeutend schlechter anbinden.
  • Toolsammlungen: Genau genommen sind das keine ESBs. Sie stellen aber Werkzeuge zur Verfügung, um andere ESBs zu konfigurieren. Hier ist natürlich die JBI-Verwandtschaft zu ServiceMix, OpenESB usw. von Vorteil.
Eigenschaften, Besonderheiten – Einsatzszenarios

Nachdem die Produkte nun in ihren Schubladen stecken, gehen wir im nächsten Abschnitt auf die Besonderheiten und – wo sinnvoll – auf die Einsatzszenarios der einzelnen ESBs ein. Natürlich können die vorgestellten Einsatzszenarios nur Leitlinien zur Orientierung bei der Entscheidungsfindung sein. Durch JBI-Konvention und offenen Sourcecode können natürlich auch einige ESBs (Tabelle 2) miteinander verbunden werden, um die Funktionalitäten der verschiedenen ESBs zu kombinieren. Diese Möglichkeiten wurden in den Einsatzszenarios jedoch nicht weiter vertieft, weil sie den Rahmen dieser einführenden Betrachtung gesprengt hätten.

Apache Camel

Camel als Framework implementiert viele der bekannten EIPs und kommt daher vor allem innerhalb anderer ESBs zum Einsatz. Camel selbst stellt keine ESB-Funktionalitäten zur Verfügung, kann aber getrost als DIE EIP-Bibliothek bezeichnet werden.

Apache ServiceMix/Fuse ESB

Beim ServiceMix handelt es sich um einen ESB, der nach den Richtlinien der JBI-Spezifikation implementiert wurde. Dieser ESB ist hochskalierbar und äußerst flexibel – vor allem deshalb, weil er nicht nur als eigenständiges Produkt zu sehen ist, sondern wegen seiner JBI-Basis im Zusammenspiel mit anderen JBI-ESBs verwendet werden kann. In der Praxis wird ServiceMix ohnehin von einigen Open-Source-ESB-Anbietern als Grundgerüst verwendet, um das dann weitere Funktionalitäten gebaut werden.

Wird kommerzieller Support benötigt, so ist der Fuse ESB die Wahl. Hierbei handelt es sich um einen zertifizierten ServiceMix ESB. Gravierende Unterschiede gibt es zwischen ServiceMix und Fuse ESB ansonsten nicht. Generell eignet sich ServiceMix also besonders gut dafür, um in bereits bestehenden Infrastrukturen verwendet zu werden. Ist etwa bereits ein gut funktionierender JMS-Broker implementiert und/oder müssen laufende Lizenzverträge eingehalten werden, dann ist ServiceMix der ESB die Wahl.

ChainBuilder

ChainBuilder ist im Prinzip kein eigenständiger ESB, sondern eher ein Werkzeugkasten, der auf eine Implementierung mit Apache ServiceMix ausgelegt ist. Natürlich muss ChainBuilder nicht zwingend mit ServiceMix betrieben werden, sondern kann auch mit jedem anderen JBI-Container laufen. Mit den mitgelieferten Tools lassen sich die von ChainBuilder bereitgestellten EIPs relativ einfach für einen JBI-Container entwickeln und orchestrieren. Das macht ChainBuilder zur perfekten Ergänzung für ESB-Systeme, die beim grafischen Tooling Defizite aufweisen, wie eben etwa ServiceMix oder Swordfish. Wer sich einmal für ChainBuilder entschieden hat, braucht zumindest innerhalb der JBI-Welt beim Einrichten eines ESB nicht mehr umlernen.

JBoss ESB

Wie der Mule ESB ist auch der Enterprise Service Bus von JBoss eine eigenständige Implementierung, die sich nicht an den JBI-Spezifikationen orientiert. Bei der Orchestrierung der Services setzt JBoss auf ein Framework aus der eigenen umfangreichen Produktfamilie: jBPM. Entwickler werden durch ein auf Eclipse basierendes IDE sowie durch weitere verfügbare Eclipse-Plug-ins unterstützt. Im Vergleich zu den anderen Systemen zeichnet sich der JBoss ESB durch seine starke Ausrichtung auf Human-Centric-lastige Geschäftsprozesse aus, wobei besonders auch langlaufende Prozesse abgebildet werden können. Allerdings: Für den ESB allein wird kein Support angeboten, der ist nur im Paket für die gesamte JBoss-Enterprise-SOA-Plattform enthalten. Der JBoss ESB ist natürlich standalone lauffähig. Unter der Bedingung, sich an die Middleware-Produkte aus dem Hause Red Hat zu binden, ist der JBoss ESB auch als Integrationsplattform für große SOA-Initiativen oder umfangreiche EAIs geeignet.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.