Camel, FUSE, Mule, ServiceMix & Talend ESB im Vergleich
Von: Thomas Bayer
Datum: 3. Jan. 2016
Aktualisiert: 20. Nov. 2017
In diesem ersten Teil geht es um die Frage, was ist ein Enterprise Service Bus und wie unterscheiden sich die Integration Frameworks. Die einzelnen Produkte werden zunächst kurz vorgestellt und jeweils in eigenen Artikeln im Detail beschrieben.
1 Was ist ein Enterprise Service Bus?
Bei der Entscheidungsfindung bei meinen Workshops tauchen immer wieder die folgenden Fragen auf:
- Ist ein ESB die Richtige Lösung?
- Welche Alternativen zum ESB gibt es?
- Was ist ein ESB?
Beginnen möchte ich mit der letzten Frage. Der Begriff ESB wird je nach Hintergrund des Hersteller für ganz unterschiedliche Konzepte und Produkte verwendet. Zum einen als Vermittler zwischen Web Services in einer Service orientierten Architektur und zum anderen als Integrationslösung die zwischen den unterschiedlichsten Formaten und Protokollen vermittelt.
1.1 ESB in einer SOA
In einer SOA übernimmt der ESB die Funktionen Routing, Monitoring, Transformation und Security. Da in einer SOA für alle Nachrichten das XML Format verwendet wird, beschränkt sich die Transformation auf die Umwandlung von XML im Format A nach XML im Format B. Wird ein normiertes Enterprise Data Model eingesetzt, so spielt die Integration eine noch untergeordnetere Rolle. Adaptoren bzw. Konnektoren werden nicht benötigt, da alle Dienste SOAP basierte Web Services sind.
Typische Vertreter eines ESB in einer SOA ist der WSO2 ESB und der Oracle Service Bus.
1.2 ESB als Integrationslösung
Der Begriff ESB wird auch für Integrationsserver verwendet, die als Mittler zwischen den unterschiedlichsten Anwendungs- und IT-Welten eingesetzt werden. Neben XML wird meist eine Vielzahl von Formaten wie JSON, HL7 und CSV unterstützt. Konnektoren gibt es in großer Anzahl für die unterschiedlichsten Protokolle wie HTTP, FTP, Web Services oder TCP.
Neben der Integration bietet ein ESB meist Quality of Service Merkmale wie die zuverlässige Zustellung von Nachrichten sowie eine Laufzeitumgebung mit Unterstützung für Monitoring und Betrieb. Ein typischer Vertreter des ESB als Integrationslösung ist der Mule.
1.3 Ist der Bus ein Auslaufmodell?
Das Buzzword Enterprise Service Bus hat seinen Dienst getan, ist verschlissen und wurde abgelegt. Eine Integration ausschließlich über XML Pipelines und die Produkte der Jahre 2005 bis 2012 werden oft mit dem Begriff ESB verbunden. Alle Produkte im Vergleich außer dem WSO2 ESB distanzieren sich heute vom Enterprise Service Bus und haben das Kürzel ESB aus ihrem Namen und den Produktbeschreibungen verdrängt. Mule ESB heißt jetzt Anypoint und Talend ESB wurde in Talend Integration umbenannt. Wer genau hinsieht findet aber noch hin und wieder den Begriff ESB in der Oberfläche oder im Code.
Die klassischen ESBs haben XML als kanonisches Datenformat verwendet und Transformationen, Filter und Routing ausschließlich mit XML Nachrichten durchgeführt. Alle hier vorgestellten Produkte haben sich inzwischen weiter entwickelt und XML ist nur noch ein Format von vielen. Nachrichten können in jeden beliebigen Format durch die neuen ESBs fließen und Transformation und Filtering ist auch mit JSON, Java Objekten und Textnachrichten möglich. Der Entwickler wird nicht mehr gezwungen alles auf XML zu „mappen“. Alle Produkte können ohne XML als Zwischenformat mit JSON, YAML oder Java Objekten arbeiten.
1.4 Java Business Integration, der gescheiterte Traum einer Standardisierung
JBI sollte ähnlich der Enterprise Java Beans die Welt der Enterprise Application Integration standardisieren. Vor mehr als einem Jahrzehnt gab es mit dem Open ESB von Sun und dem alten ServiceMix JBI konforme Server. Bei JBI gibt es standardisierte Formate für Konnektoren (Business Connector) und Integrationsanwendungen (Service Assemblies) in Form von JAR-Archiven (gezippte Java Archive). Die Beschreibung der Komponenten erfolgte mittels Deployment Descriptoren. An sich ist ein standardisiertes Format für austauschbare Konnektoren und Komponenten eine gut Sache. JBI ist aber über-engineered und komplex. Das Erstellen der Descriptoren passte bald nicht mehr in die Zeit und die Entwickler wechselten zu produktiveren Lösungen wie Apache Camel oder Mule.
Der frühe Service Mix basierte noch bis zur Version 3 auf JBI. Heute verwendet nur noch der Petals ESB den Standard JBI.
Seither kenne ich keine Initiativen, die versuchen, die Welt der Integration zu standardisieren, obwohl das sicher nützlich wäre. Vor dem Einsatz eines JBI konformen ESB rate ich aufgrund der Komplexität und der mangelnden Verbreitung dringend ab.
Eine Alternative zum „schwergewichtigen“ ESB sind leichtgewichtige Integration Frameworks, die sich ganz auf die Aufgabe der Integration konzentrieren.
2 Integration Framework
Ein Integration Framework ist im Gegensatz zu einem ESB leichtgewichtiger und wird meist in der Form einer Bibliothek eingebunden. Eine Laufzeitumgebung und eine Infrastruktur für die zuverlässige Zustellung von Nachrichten ist nicht Bestandteil eines Integrationsframeworks. Mit anderen Komponenten ergänzt können Integrationsframeworks die gleiche Funktionalität bereitstellen wie vollständige ESB Produkte. Bei diesem „Best of Breed“ Ansatz, kombiniert man die jeweils besten bzw. geeignetsten Projekte zu einer Lösung. Beispielsweise das Integrationsframework Apache Camel mit dem Message Broker ActiveMQ und der Laufzeitumgebung Spring Boot in der Java VM. Es gibt auch einen Vorteil für die Anbieter, diese können sich auf eine Aufgabe konzentrieren und diese mit all ihren Mitteln umsetzen. Auf der anderen Seite bietet ein ESB den Vorteil, dass der Anwender ein in sich abgestimmtes Produkt bekommt das alle notwendigen Komponenten enthält.
Apache Camel ist ein typischer Vertreter der Integration Frameworks. Aber auch im Mule ESB ist eine Bibliothek für die Integration enthalten, die man ohne die Laufzeitumgebung in eigene Projekte einbinden kann.
3 Die Kandidaten
Wer nach Open Source Integration sucht findet schnell ein Duzend Projekte, die teils recht ähnliche Produktbeschreibungen aufweisen. Zur groben Unterscheidung dienen die folgenden Kurzbeschreibungen, die den Projekten sicher nicht gerecht werden können. Die nächsten Teile dieser Reihe beschreiben dann jeweils ein Projekt im Detail.
3.1 Apache Camel
Apache Camel ist ein leichtgewichtiges Framework, mit Unterstützung für die Enterprise Integration Patterns. Routen für die Integration können mit Java, Scala oder XML erstellt werden. Camel ist die Basis für die umfangreicheren Projekte JBoss FUSE, Talend ESB und ServiceMix.
3.2 Apache ServiceMix
ServiceMix ist ein ausgewachsener ESB mit Message Broker, Transaktionsmonitor und Konsole für den Betrieb von Camel Routen. Der Schwerpunkt des ServiceMix liegt auf einem zuverlässigen Betrieb, für den eine OSGi konformen Laufzeitumgebung verwendet wird, auf der alle Bausteine des ServiceMix ausgeführt werden.
3.3 JBoss Fuse
JBoss hat Fuse mit dem Einkauf der Firma FuseSource erworben. Fuse ist eine auf OSGi basierende Laufzeitumgebung für Camel, welche die Konzepte des ServiceMix um das einer fabrik erweitert. Das JBoss Developer Studio unterstützt Fuse über eine Erweiterung und enthält einen graphischen Editor für Camel Routen.
3.4 Spring Integration
Warum nicht Integrationsanwendungen mit Spring zusammenstecken? Spring Integration ist direkt vom Hersteller Pivotal und basiert auf deren populären Spring Framework.
3.5 Talend ESB bzw. Integration
Der Talend ESB basiert wie ServiceMix und JBoss Fuse auf der Apache OSGi Laufzeitumgebung Karaf und verwendet Camel Routen für die Integration. Ein Highlight des Talend ist der graphische Editor für Camel Routen.
3.6 Mule ESB
Highlight des Mule ESB ist der komfortable und leistungsfähige Editor mit dem Integrationsabläufe graphisch erstellt werden können. Für Mule gibt es eine Reihe von Business Konnektoren, welche die Anbindung an SAP, Salesforce, Alfresco, ... erleichtern.
3.7 Petals ESB
Petals ESB ist ein echter Pariser der vom OW2 Middleware Consortium in Frankreich entwickelt wird. Er implementiert die nicht besonders populäre Java Business Integration Spezifikation.
3.8 Switchyard
Das dritte Integrationsprojekt der JBoss Marke ist ein leichgewichtiges und Komponenten basiertes Framework, welches sich Konzepte und Best Practices der SOA zu Nutze macht. Über einen graphischen Editor können Services per Drag- und Drop verbunden werden. Ob die Services mit Camel, Java EE oder einer BPM Engine realisiert sind, spielt dabei keine Rolle.
3.9 UltraESB
Der UltraESB zeichnet sich durch seine Geschwindigkeit aus, die er durch das Vermeiden von Kopien erzielt.
3.10 WSO2 ESB
Über eine Web Oberfläche können beim WSO2 Services erstellt und Stellvertreter für Services sogenannte Proxys eingerichtet werden. Die Unterstützung für Web Services ist gut und umfasst sogar Web Services Security. Für die Konfiguration und für Laufzeitinformationen gibt es eine Registry.
4. Friedhof der ESBs
Neben den oben aufgeführten ESBs gibt es noch Projekte, die inzwischen nicht mehr gepflegt werden.
4.1. JBoss ESB
Der JBoss ESB war ein klassischer ESB mit XML als normiertem Datenformat und integrierten Message Broker für die Zuverlässigkeit. Innovativ war die Verwendung von JavaBeans für die Implementierung von Integrationsschritten. Der JBoss ESB wird heute nicht mehr aktiv weiterentwickelt. Aktiv entwickelt werden von JBoss Fuse und Switchyard.
4.2. openadaptor™
openadaptor™ ist ein Warenzeichen der Commerzbank. Für das EAI Werkzeug gibt es seit 2011 keine Updates mehr.
4.3 OpenESB
Der OpenESB wurde ursprünglich von Sun Microsystems and Seebeyond entwickelt. Danach wurde OpenESB von einer Open Source Community weiter entwickelt. In den letzten Jahren gab es kaum noch Erweiterungen und neue Versionen. Die Unterstützung für BPEL und SCA über graphische Editoren auf der Basis von Netbeans ist im OpenESB recht ansprechend umgesetzt. OpenESB basiert auf dem veralteten JBI Standard und SOA Technologien wie BPEL und Web Services.
4.3. Apache Synapse Enterprise Service Bus
Synapse ist ein ESB oder besser ein Proxy auf der Basis des Web Services Framework Apache Axis2. Die letzte Änderung auf der Synapse Seite ist von 2012.
Vorstellung der Integrationsprodukte
Mehr Details zu den einzelnen Projekten gibt es in den jeweiligen Artikeln dieser Reihe.