OpenESB und ServiceMix im Vergleich

Dieser Artikel vergleicht die beiden open source Enterprise Service Bus Produkte in Bezug auf Komponenten, Toolunterstützung und Performance. Der Vergleich soll dem Leser bei der Auswahl des passenden Produktes helfen.

Beide Produkte implementieren die Java Business Integration Spezifikation und bieten auf offenen Standards basierte Integration. Das sind dann aber fast alle Gemeinsamkeiten. Die beiden ESB sind ansonsten recht unterschiedlich. Die jeweiligen Besonderheiten beleuchtet dieser Artikel.

1. OpenESB bzw. Glassfish ESB

Open Enterprise Service Bus oder kurz OpenESB wird unter der Leitung von Sun Microsystems über eine Open Source Community entwickelt. Der OpenESB ist eng mit der Netbeans IDE und dem Glassfish Application Server gekoppelt. Seit kurzem wird der OpenESB auch in der Glassfish ESB Distribution angeboten. Diese enthält die Runtime, Netbeans und die notwendigsten Komponenten. Mit dem Glassfish ESB Download bekommt man alles um mit graphischen Tools Integrationslösungen zu entwickeln, zu installieren und auszuführen. Die Glassfish ESB Distribution ist gut getestet und unserer Erfahrung nach stabiler als die Version, die mit dem Netbeans All Bundle ausgeliefert wird.

1.1. Toolunterstützung

Für den OpenESB gibt es zahlreiche Funktionen für die Entwicklung und Administration, die in die Netbeans IDE integriert wurden. Der Composite Application Service Assembly (CASA) Editor bietet einen Überblick über Integrationsanwendungen, die Service Assemblies genannt werden. In der Ansicht können Service Endpoints konfiguriert und über Drag and Drop verbunden werden. Abbildung 1 zeigt eine Anwendung im CASA Editor.

Abbildung 1: Netbeans Casa Editor

Für die Steuerung des Lifecycles von JBI Komponenten und Service Assemblies gibt es den JBI Manager, der in den Server Manager integriert ist. Der Screenshot in Abbildung 2 zeigt den JBI Manager sowie die installierte Komponenten und Service Assemblies.

Abbildung 2: Netbeans OpenESB JBI Manager

Netbeans unterstützt den Entwickler auch bei der Erstellung von Service Units. Eine Service Unit für den Dateizugriff oder XSLT kann in einem seperaten Projekt erstellt werden. Da der OpenESB sehr intensiv WSDL Beschreibungen verwendet sind die Editoren für WSDL und Schema hilfreich. Abbildung 3 zeigt ein WSDL Dokument in der Baumansicht.

Abbildung 3: Netbeans WSDL Editor

Der Schema Editor dargestellt in Abbildung 4 bietet verschiedene Ansichten zum komfortablen Editieren von XML Schema.

Abbildung 4: Netbeans XML Schema Editor

Zahlreiche Dialoge helfen dem Entwickler bei der Arbeit mit WSDL. Die Funktion für das Validieren von WSDL findet zahlreiche Fehler und Verstösse gegen die Regeln des Basic Profiles der WS-I Organisation. XPath und XSLT sind Schlüsseltechnologien, die in ESB Lösungen oft zum Einsatz kommen. Der XPath Editor ermöglicht einem Entwickler mit nur Grundlegenden XML Kenntnissen selbst komplexe XPath Ausdrücke per Drag und Drop zu erstellen. Wie Abbildung 5 zeigt.

Abbildung 5: Netbeans XPath Editor mit Drag and Drop Unterstützung

Im Hintergrund benutzt Netbeans das Buildtool Ant. Glassfish und OpenESB können über Ant angesprochen werden. Die Entwicklungsumgebung ist damit austauschbar. Wer möchte kann für OpenESB auch mit Eclipse entwickeln.

1.2. Komponenten

Für den OpenESB sind zahlreiche JBI Komponenten frei verfügbar. Neben üblichen Komponenten für FTP, HTTP, BPEL, etc. finden sich auch Konnektoren für Mainframes wie z.B. für CICS, MQSeries oder IMS, oder ein Adapter für SAP Systeme. Service Engines kann man für Data Integration ETL, Workflows oder Complex Event Processing CEP von der OpenESB Seite beziehen. Einige Komponenten wie z.B. der Quartz Scheduler stellen auch Netbeans Plugins für die Konfiguration zur Verfügung. Gemeinsam ist den meisten Komponenten für den OpenESB, dass sie WSDL für die Beschreibung der Endpunkte verwenden. Oft wird auch die gesamte Konfiguration im WSDL Binding abgelegt. Die Beschreibung der Endpunkte mit WSDL erfordert einige Zeit. Beim ServiceMix wird meist auf eine Beschreibung mit WSDL für Komponenten verzichtet. Dies gilt auch für Komponenten, die mit Endpunkten ausserhalb des Buses kommunizieren. Der Aufwand für die Erstellung der WSDL Beschreibungen für die OpenESB Komponenten wird durch die Toolunterstützung durch Netbeans ausgeglichen. Oft können WSDL Dokumente generiert werden. Die Beschreibung der Endpunkte mit WSDL ist der grösste Unterschied zwischen OpenESB und ServiceMix. Zumindest ist es der Unterschied, der bei der Entwicklung am deutlichsten spürbar ist. Dieser Unterschied ist rein durch die Komponenten bedingt. Der Bus selbst ist durch JBI standartisiert und verhält sich bei beiden gleich.

1.3. Die BPEL Service Engine

Für die Verbindung von Binding Components und Service Engines wird beim OpenESB die Business Process Execution Language, kurz BPEL, verwendet. Viele Komponenten können ohne BPEL nicht miteinander verbunden werden. Möchte man beispielsweise eine File BC, die eine Datei einliest mit einer XSLT SE verbinden, steht man vor dem Problem, dass das In-Only Exchange Pattern der File BC nicht zum In-Out der XSLT SE passt. Mit BPEL lassen sich die Komponenten verbinden, da BPEL sowohl synchrone als auch asynchrone Aufrufe unterstützt. Eine Entscheidung für den OpenESB ist daher immer auch eine Entscheidung für BPEL.

1.4. Laufzeitumgebung

Der Glassfish Application Server ist die standard Laufzeitumgebung für OpenESB. Neben dem Glassfish kann OpenESB in weitere JEE Application Server wie IBM Websphere oder BEA bzw. Oracle Weblogic integriert werden. Über den Application Server werden dann Features wie Clustering oder Transaktionen ermöglicht. Ferner ermöglicht die Java EE Service Engine den Zugriff auf EJB und Web Anwendungen, die auf dem Application Server ausgeführt werden. Für diejenigen, die OpenESB ohne Application Server ausführen möchten gibt es die OpenESB for Java SE Distribution. Für diese Distribution gibt es allerdings nur eine Installationsanleitung für Unix und es ist auch nicht ersichtlich welche OpenESB Version in dieser Distribution enthalten ist. Wer auf den Application Server verzichten möchte ist mit dem ServiceMix wahrscheinlich besser bedient.

1.5. Performance

Durch die Übertragung von Nachrichten im Hauptspeicher und eine effiziente XML Verarbeitung bietet der OpenESB eine gute Performance. Eine einfache Composite Application mit SOAP Adapter und XSLT Transformation konnte in unseren Tests auf einem Dual Core Prozessor unter Windows XP mehr als 25.000 Nachrichten pro Minute verarbeiten. Damit dürfte die Performance hauptsächlich von der Verarbeitungsgeschwindigkeit der Backendsysteme oder von aufwendigen XSLT Transformationen bestimmt werden.

2. Apache ServiceMix

ServiceMix ist die JBI Implementierung der Apache Software Foundation. Für den Transport der Nachrichten auf dem Bus wird der Java Messaging Service kurz JMS verwendet. Die verwendete JMS Implementierung ist Apache ActiveMQ. Wird beim ServiceMix eine Nachricht von einer Komponente zur nächsten über den Bus gesendet, so wird diese jedesmal über die JMS Infrastruktur transportiert. Über eine Java Managment Extensions JMX Console kann man sich die extra dafür erzeugten Message Queues ansehen. Durch die Verwendung von JMS für den Nachrichtentransport bekommt der Bus seine Quality of Service Eigenschaften wie: Message Persistance oder Transaktionsunterstützung. Der ServiceMix kann daher nach einem Absturz der Hardware seine Arbeit da fortsetzen wo er unterbrochen wurde. ServiceMix verwendet für die Konfiguration das Apache XBean Projekt. XBean bietet eine tiefgehende Integration mit dem Spring Framework. Sämtliche Konfiguration erfolgt über das Spring XML Format. Selbst Service Units werden mit XBeans konfiguriert. Bei einigen Komponenten können über XBeans Bausteine ausgetauscht werden. Beispielsweise kann man für die File Komponente einen File-Filter mit Java implementieren und diesen einklinken. Damit kann mit dieser ServiceMix Komponente Java verwendet werden. Das eröffnet dem Entwickler weit mehr Möglichkeiten als eine "normale" Konfiguration.

2.1. Toolunterstützung

ServiceMix ist ein typisches Apache Projekt das über die Kommandozeile bzw. über Maven2 verwaltet wird. Plugins für Maven2 sind auch die einzigen, die mit dem ServiceMix ausgeliefert werden. Wer mit Maven2 nicht vertraut ist wird daher zunächst einige Zeit benötigen. Danach kann man mit Maven2 seine Service Assemblies und die Abhängigkeiten zu Service Units komfortabel verwalten. Ein Tool für die Verwaltung der Komponenten und Service Assemblies ist auch nicht notwendig, da man über das Filesystem durch Löschen oder Kopieren schnell die gewünschte Aktion durchführen kann.

2.2. Komponenten

Die ServiceMix Distribution enthält bereits zahlreiche Binding Komponenten und Service Engines. Folgende Konnektoren werden mitgeliefert:

• File
• FTP
• HTTP
• JMS
• Mail
• SOAP

Service Engines gibt es u. a. für:

Tabelle 1: Service Engines für ServiceMix

Der ServiceMix wird mit mehr JBI Komponenten ausgeliefert als die OpenESB, Netbeans oder Glassfish ESB Distribution. Insgesamt sind aber wesentlich mehr Komponenten für den OpenESB verfügbar als für den ServiceMix. Die JBI Spezifikation verspricht, die Austauschbarkeit von Integrationskomponenten zwischen den einzelnen ESB: In der Praxis funktioniert dies allerdings noch nicht reibungslos, was sich aber in der nächsten Zeit sicher ändern wird.

2.3. Orchestration und Routing

Im Gegensatz zum OpenESB wird beim ServiceMix BPEL nicht für die Orchestration benötigt. ServiceMix wird auch ohne BPEL Engine ausgeliefert. Wer trotzdem BPEL für Orchestration und Routing einsetzen möchte kann z.B. die Apache ODE BPEL Engine als JBI Komponente installieren.
Für das Routing gibt es für den ServiceMix mehrere Alternativen. Die einfachsten sind die Enterprise Integration Patterns, kurz EIP, die in der EIP Service Engine enthalten sind. Eine mächtigere Alternative ist die Camel SE, die das Apache Camel Projekt kapselt. Camel ist selbst ein Open Source Integration Framework. Regeln für das Routing können in Camel mit einer auf Java basierten Domain Specific Language (DSL) oder über eine Spring Konfiguration erstellt werden. Ferner gibt es noch eine SE für das Business Rule Management Drools.

2.4. Laufzeitumgebung

ServiceMix ist recht anspruchslos an seine Umgebung. Während der Entwicklung kann man ServiceMix direkt in einer Java VM ohne Application Server ausführen. Es ist sogar möglich ServiceMix aus einem JUnit Test heraus zu starten oder ServiceMix embedded in anderen Anwendungen zu betreiben. Wer möchte kann ServiceMix auch in Geronimo, JBoss, Tomcat oder andere Server Integrieren.

2.5. Performance

Für die Performance des ServiceMix gilt das Gleiche, weiter oben zum OpenESB aufgeführt wurde. Auch ServiceMix kann 10000de von Nachrichten pro Minute verarbeiten. Selbst wenn die Nachricht über ActiveMQ und die Apache Derby Datenbank persistiert werden, leidet die Performance nicht wesentlich. Falls die Performance beispielweise aufgrund von aufwendigen Transformationen nicht ausreicht, kann ServiceMix im Cluster betrieben werden. Dazu installiert man ServiceMix und die Service Assembly einfach auf mehreren Rechnern. Über Multicast finden sich diese und verteilen nun die Last auf mehrere Rechner.

3. Fazit

Trotz JBI Spezifikation sind OpenESB und ServiceMix recht unterschiedlich. Keiner der beiden ist besser oder schlechter. Wer seine Dienste grundsätzlich mit WSDL beschreiben möchte, gute Toolunterstützung schätzt und für den Betrieb einen Application Server einsetzen möchte, wird sich für den OpenESB entscheiden. Wer dagegen seine XML Schnittstellen flexibel halten möchte; Nachrichten als Dokumente ansieht, die auch erweitbar sind; Maven2 bereits verwendet und auf einen Application Server verzichten möchte wird den ServiceMix vorziehen.

Tabelle 2: OpenESB u. ServiceMix im Direktvergleich