© Ying Feng Johansson, 123RF

Ein Enterprise Service Bus als zentrale “Autobahn” für Daten und Dienste im Unternehmen kümmert sich um die Kommunikation, erledigt aber auch Orchestrierung, Message-Routing oder Event-Analyzing. Dieser Artikel stellt drei freie Produkte anhand einfacher Einsteigerszenarien vor.

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” width=”300″ height=”241″ /> 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.

Apache Servicemix

Apache Servicemix ist eine ESB-Softwarelösung, die bereits in vielen verschiedenen Softwareprodukten und IT-Unternehmen Anwendung findet. Sie basiert auf der Java-Spezifikation Java Business Integration (JBI, [13]). Die definiert eine Standardarchitektur, die sich für Java-Tools ebenso wie für den ESB eignet. Die Architektur sieht Komponenten vor, Integrationsprodukte lassen sich durch Plugins anbinden. Komponenten können dabei Serviceleistungen sowohl anbieten als auch konsumieren. Ein gutes Beispiel dafür ist das Bereitstellen von XSLT-Transformationen.

Apache Servicemix implementiert diese JBI-Spezifikation in der Version 1.0 (JSR 208) und bringt bereits einige Komponenten mit. Zu den wichtigsten zählen:

• »servicemix-bean« : Benutzt POJOs (Plain Old Java Objects)
• »servicemix-eip« : Eine Service-Engine, mit Router-Implementierungen nach EIP (Enterprise Integration Patterns)
• »servicemix-file« : Zugriff aufs Dateisystem
• »servicemix-http« : Zugriff auf SOAP und HTTP-Services
• »servicemix-jms« : Zugriff auf JMS-Implementierungen wie Apache Active MQ

Ein einfaches Beispiel anhand eines automatisierten File-Kopierers zeigt, wie Admins mit Apache Servicemix arbeiten: Der Kopierer soll jede Datei, die in einem Verzeichnis (»/home/servicemix/input« ) erstellt wird, auch im Verzeichnis »/home/servicemix/output« hinterlegen.Zunächst legt der Admin ein neues Verzeichnis für das Projekt an und editiert die Datei »pom.xml« für die Konfiguration von Maven [14], einem Software-Projektmanagementtool aus dem Apache-Projekt. Anschließend erzeugt er mit diesem Befehl die Service Unit:

mvn archetype:create -DarchetypeArtifactId=servicemix-service-unit -DarchetypeGroupId=org.apache.servicemix.tooling -DartifactId=tutorial-file-su

Nun fügt er die Abhängigkeiten von Apache Servicemix in der Datei »pom.xml« hinzu (Listing 3).

<dependencies> <dependency> <groupId>org.apache.servicemix</groupId> <artifactId>servicemix-file</artifactId> <version>${servicemix-version}</version> </dependency>
</dependencies>

Jetzt fehlt noch die Konfiguration der Datei-Endpunkte. Hier benötigt der Admin einen File-Sender (Datei übertragen) und einen File-Poller (Änderungen überwachen). Listing 4 zeigt die dafür nötige Datei »xbean.xml« . Dann muss er alles noch in einer Service Assembly zusammenfassen:

<beans xmlns:file="http://servicemix.apache.org/file/1.0" xmlns:tut="urn:servicemix:tutorial"> <!-- add the sender endpoint here --> <!-- add the poller endpoint here -->
</beans>
<file:sender service="tut:file" endpoint="sender" directory="file:/home/servicemix/output" />
<file:poller service="tut:file" endpoint="poller" file="file:/home/servicemix/input" targetService="tut:file" targetEndpoint="sender"/>

mvn archetype:create -DarchetypeArtifactId=servicemix-service-assembly -DarchetypeGroupId=org.apache.servicemix.tooling -DartifactId=tutorial-sa

In »pom.xml« ändert er noch den Projektnamen und fügt die Abhängigkeiten zur Service Unit hinzu (Listing  5).

<project> [...] <dependencies> <dependency> <groupId>org.apache.servicemix.tutorial</groupId> <artifactId>tutorial-file-su</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> [...]
</project>

Fürs Hot Deployment muss der Admin ins Verzeichnis mit dem Beispielprojekt »tutorial-sa« wechseln und mit »mvn install« das Projekt kompilieren. Dabei erhält er eine Zip-Datei, die er in das Verzeichnis »$SERVICEMIX_HOME/hotdeploy« kopiert. Mehr Details zu Apache Servicemix gibt’s unter [15].

Die Enterprise-Variante von Apache Servicemix hört auf den Namen Fuse ESB und wird von der Firma Fuse Source [16] angeboten. Neben mehr Funktionalität sind in der Enterprise Edition noch der Fuse Message Broker (basiert auf Apache Active MQ), ein Fuse Mediation Router (verwendet Apache Camel [17]) und das Fuse Service Framework (mit Apache CXF) verfügbar. Entwickler nutzen außerdem die Fuse IDE als integrierte Entwicklungsumgebung und die grafische Oberfläche des Fuse HQ, um den ESB zu verwalten und zu überwachen. Wer will, findet bei Fuse Soft auch Support, Schulungen und Trainings.

Talend ESB

Sopera ASF ist eine Service-orientierte Integrationsplattform, die die Sopera GmbH für Integrationsprojekte der Deutschen Post AG entwickelt hat. Seit 2008 bietet der Hersteller die Software als Open Source an. Im November 2010 hat Talend die Sopera GmbH übernommen und führt das Produkt unter dem Namen Talend ESB weiter. Der Talend ESB ist modular aufgebaut, die Anwendungen, Prozesse, Daten und SOA-Lösungen anderer Hersteller speist er in die eigene SOA ein. Sowohl Basisstandards, beispielsweise SOAP, WSDL, XML, als auch erweiterte Standards wie UDDI, WS Policy, BPEL kommen zum Einsatz.

Eine andere SOA-Spielart, die sich in Talend ESB findet, ist wieder Apache Camel. Das Framework für Open-Source-Integrationen ermöglicht Enterprise Integration Patterns (EIP), um Mediationsregeln zu vereinbaren. Weil das Framework auf simplen URLs basiert, kann der Admin mit fast beliebigen Transportmodellen arbeiten, beispielsweise HTTP, JMS (Active MQ und weitere JMS-Implementierungen) oder JBI.

Anwender können Talend ESB in Java- und Microsoft-Umgebungen und diese wieder über ein standardisiertes SOA-Framework miteinander vernetzen. Hierbei unterstützt Talend ESB die Java-Standards J2SE, J2EE sowie die Windows Communication Foundation (WCF) des Dotnet-3.0-Framework.

Verteilte Architektur

Talend ESB weist eine verteilte Architektur auf und lässt sich auch in verteilten, räumlich voneinander getrennten Umgebungen einsetzen. Verteilt heißt in diesem Fall aber auch, dass ein zentraler Bus kein zwingendes Merkmal ist. An dessen Stelle laufen die Funktionen in so genannte Service Backbone Libraries.

Das folgende Beispiel zeigt, wie eine SOA-Anwendungen innerhalb von Talend ESB gestaltet ist. Die Talend ESB Standard Edition ist quasi ein Talend Open Studio mit einer eigenen Ansicht, dem Service Builder und entsprechenden ESB-Komponenten. Im Beispiel soll ein Webservice dazu dienen, eine Eingabe einfach wieder auszugeben (Echo). Ein Consumer füttert den Dienst mit Daten, ein Provider stellt den entsprechenden Service bereit. Ein detailliertes Tutorial über die Konfiguration findet sich unter [18].

Um einen Consumer wie in Abbildung 4 zu erstellen, ist zunächst ein neuer Job nötig. Anschließend definiert der Admin über die Komponente »FixedFlowInput« eine simulierte Eingabe und transformiert diese über »tXMLMap« in eine XML-Nachricht. Die gelangt dann zum »tESBConsumer« , der den Webservice-Aufruf an den ESB-Provider durchführt. Hier lässt sich auch die benötigte WSDL-Datei konfigurieren.

Abbildung 4: Die Talend-ESB-Syntax unterscheidet zwischen Consumer und Provider.

Nun bedarf es noch des Providers mit zwei ESB-Provider-Komponenten (Abbildung 5). Eine, die den Request entgegennimmt, und eine, die die Response zurückschickt. Für den Provider ist wieder ein neuer Job nötig, beide Komponenten verbindet ein »tLogRow« , sodass der Datenstrom zwischen ihnen auf der Kommandozeile landet. Der »tESBProviderRequest« muss mit der gleichen WSDL-Datei konfiguriert sein wie der eben erstellte Consumer.

Abbildung 5: Der Consumer füttert den Provider (im Bild) mit Daten, die der Provider als Service bereitstellt.

Abschließend startet der Admin erst den Provider, damit er entsprechende Dienste bereitstellt. Dies erfolgt über den Tab »Starte« , der sich im unteren Bereich der Oberfläche findet. Anschließend erhält der Consumer über denselben Mechanismus den Befehl loszulegen.

Auch in die Enterprise Edition von Talend ESB lassen sich weitere kommerzielle Plugins einbinden. Durch Option Packs kann der Benutzer auch Sopera ESB Dotnet, Sopera BPM, Sopera Application and Data Integration sowie Sopera HQ (Service and System Management) für sich nutzen. Außerdem bedient der Hersteller zusätzliche kommerzielle Laufzeitumgebungen und bietet Support. Die Enterprise-Version unterliegt (statt der EPL bei der Community Edition) einer eigenen Sopera License.

Interessant machen die Enterprise Edition von Talend ESB die verbesserte Zusammenarbeit von Admin-Teams über das Talend Repository und die einheitliche Administrationskonsole für die zentrale Kontrolle von Service-Aktivitäten und die Lokalisierung.

Communities, Support und IDEs

Die Community ist bei allen drei ESB-Anbietern recht gut ausgeprägt, am umfangreichsten ist sie sicherlich bei Mule, wo die Community-Mitglieder viel nützliche Unterstützung in Foren und Mailinglisten anbieten und selbst entwickelte Extensions und I-Beans zur Verfügung stellen. Auch im Git-Repository finden sich zahlreiche Plugins.

Durch die Akquisition von Sopera durch Talend profitiert der Benutzer von einer sehr starken Anwendergemeinschaft. Mit dem Talend Open Studio hat sich eine sehr lebhafte Community entwickelt, die sich rege über Foren austauscht und selbst entwickelte Komponenten bereitstellt. Bei Apache Servicemix oder Fuse ESB ist zwar eine Community vorhanden, sie ist allerdings deutlich weniger aktiv als bei Mule oder Talend.

Support für ihre Enterprise-Ausgaben bieten alle drei Softwarehersteller. Der Kunde kann zwischen verschiedenen Modellen mit unterschiedlichen Verfügbarkeiten wählen. Unternehmen greifen tendenziell eher zur Enterprise Edition mit ihren Supportgarantien, vor allem bei geschäftskritischen Anwendungen. Dann ist die Firmen-IT im Katastrophenfall nicht auf die Hilfe der Community angewiesen.

Alle drei ESB-Hersteller bieten für ihre Anwendung Entwicklungsunterstützung an. Neben der auf Eclipse aufsetzenden Mule IDE hat Mule Soft noch das neu entwickelte Mule Studio im Portfolio. Damit modelliert der Anwender den Flow grafisch und konfiguriert die Komponenten, beispielsweise eine JDBC-Verbindung. So definiert er in angemessen kurzer Zeit den generellen Flow. Derweil können sich die Entwickler auf den Zusammenbau der nötigen Komponenten konzentrieren.

Nach der Übernahme von Sopera durch Talend existiert in der aktuellen Version 4.2 ein grafisches Tool, mit dem Admins ihre SOA aufbauen können. Der Benutzer findet hier – wie auch schon in den bekannteren Tools Talend Open Studio und Data Profiler – eine grafische Oberfläche, in der er die jeweiligen Komponenten auf eine Art Leinwand zieht, sie miteinander verbindet und konfiguriert.

Wie bei Mule Studio kann er sich so ganz auf die Entwicklung der Java-Komponenten konzentrieren. Auch Fuse bietet mit der Fuse IDE ein Tool, bei dem der Benutzer in einer grafischen Oberfläche die Komponenten auf die Oberfläche zieht, sie verbindet und konfiguriert. Alle drei Lösungen basieren auf Eclipse.

Außer Konkurrenz: IBM, Red Hat, Microsoft

Die proprietäre Konkurrenz bedient sehr unterschiedliche Zielgruppen. Hilfe finden die Anwender stets in Foren, Usergroups, Blogs, Webcasts und Wikis. Microsofts proprietäres Biztalk bietet sich vor allem für Kunden an, die ohnehin schon Komplettlösungen aus Redmond einsetzen, und existiert ausschließlich für Windows-Plattformen. Red Hats Jboss SOA Platform erschafft ein proprietäres API, kommt als Stand-alone-Anwendung ohne Tomcat oder ähnliche Middleware daher und hat Stärken vor allem im wichtigen Bereich des Messaging. Und IBMs Websphere ist eine der teuersten Lösungen, kann solventen Kunden allerdings auch für fast alle Anwendungsfälle Lösungen bieten.

Open-Source-ESBs: Für jeden was dabei

Jede der drei freien ESB-Lösungen hat ihre Vorzüge, und Support für die Enterprise Editionen gibt es bei allen Softwareherstellern. Stets kann der Kunde zwischen Modellen wählen, die in der Regel unterschiedliche Verfügbarkeiten bieten. Für die Community Edition stellen die Hersteller keinen Support zur Verfügung, sondern verweisen da lieber auf die “starke Community”.

Mule ESB hat den Vorteil einer sehr großen Community. Zudem sind mit der Version Mule ESB 3 viele Konnektoren für Cloud-Dienste wie Salesforce, Amazon Web Services oder Twitter bereits vorhanden. Das erleichtert wiederum das Entwickeln von ESB-Lösungen, die auf Cloud-Dienste zugreifen, zumal die Integration Cloud-basierter Dienste mit Legacy-Anwendungen in Zukunft vermehrt Zuspruch finden dürfte.

Talend bietet hingegen eine sehr intuitive IDE, mit der sich ESB-basierte Lösungen entwickeln lassen. Talend hat sein Portfolio um eine ESB-Lösung erweitert und nähert sich ein Stückchen dem führenden Open-Source-Hersteller Mule an. Apache Servicemix und Fuse ESB bringen im Vergleich zu den anderen beiden Anbietern längere Einarbeitungszeiten mit sich und sind deswegen eher für erfahrene Entwickler geeignet.

Doch erweist sich bei ihnen als vorteilhaft, dass sie eine sehr gute Interoperabilität mit anderen relevanten Apache-Projekten wie Active MQ, Camel oder CXF aufweisen. Des Weiteren wurde mit der OSGI (Open Services Gateway initiative, [19]) als Integrationsplattform eine zukunftssichere Basis geschaffen, die auf einem anerkannten Standard aufbaut.