Drei freie Enterprise-Service-Bus-Projekte im Vergleich

Admins, die vor der Aufgabe stehen, die IT-Landschaft ihres Unternehmens auf die Themen Service-Orientierung und Enterprise Service Bus zu trimmen, brauchen nicht gleich zu kostspieligen, proprietären Produkten mit garantiertem Vendor-Lock-in zu greifen. Dieser Artikel hilft das komplexe Thema zu verstehen und präsentiert drei leistungsfähige Open-Source-Tools anhand einfacher Beispiele, die die unterschiedlichen Ansätze deutlich machen.

Ein kleines oder mittelständische Unternehmen muss seinen Fokus nicht mal in der IT haben, um sich mit den Themen Enterprise Service Bus (ESB, [1], Kasten "Was ist ein ESB?") oder Service-orientierte Architekturen (SOA, [2]) konfrontiert zu sehen: Immer öfter winken ein großer Auftrag oder ein dauerhaftes Projekt nur dann, wenn die Firmen-IT mit den vom Auftraggeber vorgegebenen Datenschnittstellen harmoniert – und schon sieht sich der lokale Admin mit einer Fülle von Spezifikationen und Anforderungen konfrontiert, die weit über die bisherige Organisationsform hinausgeht.

Vor allem in der hochgradig vernetzten Automobilindustrie sind derartige Service-Schnittstellen gang und gäbe. Dort muss sich der Zulieferer anmelden und bekommt über klar definierte Formate, meist XML-Strukturen, die Daten geliefert, die er in seinem ERP-System benötigt. Darüber hinaus erwartet der Automobilkonzern selbstverständlich auch, dass der Zulieferer seine Daten wieder im gleichen Format upstream gibt, also per Datenschnittstelle in die Konzern-IT einspeist. Es läge nahe, hier einfach einen Konnektor als Client zu bauen, vielleicht reicht sogar ein simples Perl-Skript. Doch wäre dies an die Clientsoftware gebunden und ließe sich nur mit neuem Entwicklungsaufwand an später neu eingeführte Software anpassen.

Spaghetti-Architekturen

Sollen gar mehrere Systeme mit den vom Kunden angebotenen Diensten kommunizieren, droht außerdem eine Art Spaghetti-Architektur (siehe Abbildung  1). Spätestens dann ist es ratsam, über die Einführung einer Service-orientierten Architektur mit der Integration eines Enterprise Service Bus nachzudenken. Der ergibt auch innerhalb eines Unternehmens bereits bei mittelmäßig komplexen IT-Strukturen Sinn.

Abbildung 1: Sollen fünf Dienste miteinander kommunizieren, entsteht schnell eine solche Spaghetti-Architektur. Im schlimmsten Fall muss die Firmen-IT jeden Konnektor selbst programmieren und warten.

Was ist ein ESB?

Ein Enterprise Service Bus ist die zentrale Komponente einer Service-orientierten Architektur (SOA). Eine SOA-kompatible IT tauscht Informationen in Form von standardisierten Nachrichten zwischen verschiedenen Systemen aus. Der ESB ist der Nachrichtenbus, über den der Austausch stattfindet. Als zentrale Strecke für Daten und Dienste unterstützt er die Integration unterschiedlicher Komponenten in heterogenen Anwendungslandschaften.

Größter Vorteil des ESB ist die Möglichkeit, verschiedenste Systeme anzudocken, im Idealfall ohne oder mit nur geringen Anpassungen an den laufenden Diensten. Das Verwalten der Verbindungen, des Routing und der Konfiguration erledigt der ESB, die IT-Struktur der Firma ist dort in unterschiedlichen Formaten hinterlegt. Abbildung 2 zeigt, wie ein ESB als Zentrale agiert und so viele einzelne Schnittstellen zwischen den Diensten unnötig macht.

Abbildung 2: In einer IT-Landschaft mit einem ESB bedarf es nur eines Konnektors pro Service, was Administrations- und Integrationsaufwände deutlich verringert.

Die Einführung eines ESB ist jedoch eine durchaus kostspielige und weitreichende Entscheidung. Selbst kleinere Setups erfordern einen mittleren fünfstelligen Betrag, wobei sich die Ausgaben gleichermaßen auf das umfangreiche Consulting und die darauf folgende Programmierung aufteilen. Die ESB-Hersteller verkünden unisono, dass sich die Investition lohne, weil so ein System später deutlich einfacher zu warten und zu erweitern sei. Dennoch muss sich jeder IT-Leiter oder Admin bewusst sein, dass die Wahl des ESB eine langfristige Festlegung auf ein Produkt darstellt, aus der das Unternehmen nicht oder nur mit hohem Aufwand wieder herauskommt.

Allein die Tatsache, dass erhebliche Teile der Geschäftsprozesse in Form von Konfigurationsdateien auf dem ESB hinterlegt sind, zeigt die Bedeutung dieser Entscheidung für den künftigen IT-Betrieb und lässt die Aufwände bei einem Wechsel der ESB-Software erahnen.

Angesichts der zu erwartenden Umsätze ist der Markt für ESBs im Aufschwung, auch weil in immer mehr Firmen die Integration verteilter Dienste in heterogene Unternehmensanwendungen an Relevanz gewinnt. Da tummeln sich Hersteller proprietärer Produkte wie IBM Websphere [3], Microsoft Biztalk [4], Oracle Integration Adapters [5] oder Red Hat Jboss Enterprise SOA Platform [6] neben freien Produkten wie Mule ESB [7], Apache Servicemix [8] und Talend ESB [9] (ehemals Sopera, [10]).

Auch die mittlerweile in der Open Source Business Alliance aufgegangene Lisog hat in ihrem Cloud Stack [11] dem ESB eine zentrale Rolle zuerkannt, wobei hier auf Produktebene Sopera und Mule gleichberechtigte freie Alternativen sind.

Consultants sind sich jedoch in einem Punkt einig: Eine allgemeine Empfehlung, wer in welcher Situation welches ESB-Produkt verwenden sollte, lässt sich nicht geben. Es kommt immer auf den Einzelfall an, auf die Fähigkeiten der beteiligten Dienste und die Anforderungen des Szenarios. Für die drei im Folgenden vorgestellten Open-Source-Systeme (Mule ESB, Apache Servicemix und Talend ESB) hilft die von den Autoren zusammengestellte Tabelle 1, um herauszufinden, ob eines der drei für ein spezielles Setup in Frage kommt. Der Kasten "ESB-Analysen" zeigt einen Überblick über Meinungen, die Technologie- und Marktforschungsunternehmen in Studien zusammengetragen haben. Die Untersuchungen von Forrester Research, zum Beispiel [12], erweisen sich mit nicht weniger als 109 Kriterien als die umfassendsten.

Tabelle 1: Drei Open-Source-ESB-Anbieter im Überblick

Mule ESB

Mulesofts ESB ist mit mehr als 1,5 Millionen Downloads und über 2500 Unternehmensanwendern die weltweit gefragteste ESB-Anwendung auf Basis von Open-Source-Software. Der Hersteller bietet außerdem einen Enterprise Tomcat Server (Tcat) und Mule I-ON an, eine Cloud-basierte Integrationsplattform als Service. Der Mule ESB ist in Java geschrieben, bereits existierende Systeme mit Komponenten wie JMS, Webservices und HTTP lassen sich vergleichsweise einfach integrieren. Zudem wirbt Mulesoft mit hoher Skalierbarkeit, die es erlaubt, sehr viele Anwendungen miteinander zu verbinden.

Mule ESB eignet sich sowohl für SOA-Szenarien als auch für das Einbetten von Anwendungen in zentrale Plattformen und unterstützt die gängigen Enterprise Integration Patterns. Für die Konfiguration existiert ein eigener XML-Dialekt, der sich stark an die Spring-Konfiguration anlehnt und es beispielsweise auch erlaubt, JDBC-Verbindungen in der Spring-Syntax zu definieren.

Das Beispiel in Listing 1 konfiguriert eine simple Anwendung in Mule ESB. Sie erhält über eine URL einen Namen und gibt diesen String anschließend wieder aus. Der Code setzt zunächst den Namespace für die benötigten Komponenten. Nach einem kurzen Kommentar in »description« (Zeile 12) eröffnet die Anwendung den "Flow". Als Flow bezeichnet Mule einen Ablauf, bei dem Module wie Endpoints oder Komponenten Einsatz finden. In diesen Fluss übernimmt der ESB die Eingaben, die über die URL eintreffen, definiert durch das »inbound-endpoint« -Tag (Zeile  19).

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:cxf="http://www.mulesoft.org/schema/mule/cxf"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans"
xmlns:core="http://www.mulesoft.org/schema/mule/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/cxf http://www.mulesoft.org/schema/mule/cxf/3.1/mule-cxf.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/3.1/mule.xsd ">
 <description> This config builds a JAX-WS service with CXF. We use a "serviceClass" which is a JAX-WS
 interface we've defined. It allows us to ensure that the WSDL is
 only generated for the "echo" method (as opposed to all the other methods on the EchoComponent).
 This keeps our WSDL nice in clean - but it is not required.
 To invoke the Echo service hit the following URL - http://localhost:65082/services/EchoUMO/echo/text/hello
 To view the WSDL for the Echo service go to - http://localhost:65082/services/EchoUMO?wsdl</description>
 <flow name="EchoFlow">
  <core:inbound-endpoint address="http://localhost:65082/services/EchoUMO"
   exchange-pattern="request-response" doc:name="Generic"
   doc:description="Generic endpoint specified by address URI"/>
   <cxf:jaxws-service serviceClass="org.mule.example.echo.Echo"
    doc:name="SOAP"
    doc:description="Make a web service available via CXF"/>
   <component doc:name="Component" doc:description="Invoke a Java component">
    <singleton-object class="org.mule.example.echo.Echo"/>
   </component>
 </flow>
</mule>

Eingaben kommen über den Webservice per Jaxws (Java API for XML Web Services), Mule leitet sie an die selbst geschriebene Echo-Komponente »org.mule.ex- ample.echo.Echo« aus Listing 2 weiter. Und die gibt einfach nur den eingegebenen Namen wieder aus. Das mitgelieferte Mule Studio stellt den entsprechenden Flow noch grafisch (siehe Abbildung 3) dar.

@WebService
public class Echo
{
 @WebResult(name="text")
 public String echo(@WebParam(name="text") String string)
 {
   return string;
  }
}

Abbildung 3: Eine einfache Beispielanwendung im Mule Studio.

User der kostenpflichtigen Enterprise Edition können weitere Integrationstools wie den Native Websphere MQ und Premium JDBC nutzen. Außerdem sind Performance Management und Steuerung über die Mule Management Console möglich. Mit dieser können Admins seit Version 3.2 auch Clustering und Deployment nutzen. Für die Konfliktanalyse arbeitet der Benutzer meist mit einem eigenen Service Flow Analyzer. Dazu gibt's auf Wunsch erweiterten Support, zusätzliche Sicherheitsmechanismen wie SAML und rollenbasierte Zugangskontrolle.