Der Open-Source- ESB Mule

Fachthema 
Ritt auf dem Maultier
Der Open-SourceESB Mule
In der letzten JavaSPEKTRUM-Ausgabe [Pleus07] wurde mit
ServiceMix ein JBI-fähiger Open-Source-ESB vorgestellt. In diesem Artikel zeigen wir mit Mule einen anderen, weit verbreiteten Open-Source-ESB, der allerdings nicht auf JBI beruht.
Was ist Mule?
Dirk Jablonski, Guido Schmutz
Ein Enterprise Service Bus (ESB) ist heute ein sehr geläufiges „Buzzword“.
Jeder Hersteller im Integrationsumfeld hat mittlerweile ein Produkt in seinem Portfolio, das diesen Namen trägt. Der ESB gehört zu den bevorzugten
Werkzeugen, wenn es darum geht, Systeme mit heterogenen Schnittstellen basierend auf unterschiedlichen Technologien wie COBOL, CORBA
oder Java EE zu integrieren. Dieser Artikel zeigt, welche Idee hinter dem
ESB steht und wie man mit Mule, einer der führenden Open-Source-ESBImplementierungen, Systeme unternehmensweit integrieren kann.
Was ist ein ESB?
Es gibt bis heute keine allgemeingültige oder anerkannte
EDefinition, was genau ein ESB ist. Gleichzeitig existieren
aber viele unterschiedliche Meinungen darüber, was ein ESB
genau tun soll. Eine Google-Recherche nach den Stichworten
„ESB“ und „Enterprise Service Bus“ fördert beispielsweise eine
Unmenge von Definitionen zutage.
Um ESB-Produkte besser beurteilen zu können, hat Mark
Richards [Rich06] versucht, die wichtigsten Funktionalitäten
eines ESB zu definieren. Er sagt dabei ausdrücklich, dass nicht
jeder ESB diese zwingend implementieren muss. Es kann jedoch bei der Evaluation eines ESB helfen, sich im Klaren zu
sein, welche von diesen Funktionalitäten ein bestimmtes Produkt anbietet. Tabelle 1 zeigt eine Übersicht der Kernfunktionalitäten eines ESB.
Richards hat im Weiteren auch Orchestration und Choreography als mögliche Funktionalitäten eines ESB aufgeführt. Wir
sehen diese Funktionalitäten aber eher als Anforderung an ein
spezifisches BPM-Werkzeug, das z. B. Orchestrierung im Sinne
von BPEL unterstützt, und weniger als Aufgabe des ESB.
Mule definiert ein Set von Komponenten, mit denen auf einfache Art und Weise (oftmals rein deklarativ) unabhängige Applikationen über eine virtualisierte Transportschicht miteinander kommunizieren können. Der schnellste Weg, um zu verstehen, wie Mule arbeitet, führt über die Studie der mitgelieferten Beispielapplikationen und das Lesen der Dokumentation
[Mule]. Die Mule-Webseite bietet einen relativ guten Überblick
über die Konzepte und Entwurfsprinzipien von Mule. Im Prinzip handelt es sich bei Mule um eine Implementierung der in
[Hohpe04] vorgestellten Enterprise Integration Patterns.
Mule-Architekturübersicht
Mule ist, wie von einem modernen Framework erwartet, modular aufgebaut. Die einzelnen Bausteine werden in jeder Komponente des ESB in einer bestimmten Abfolge durchlaufen, die
in Abbildung 1 dargestellt ist.
Bei einer Application kann es sich um eine monolithische Legacy-Applikation handeln, die über einen Wrapper-Service mit
dem Bus verbunden wird. Es kann sich aber auch um sehr feingranulare Einzelservices, Java EE-Applikationen oder eine weitere Mule-Instanz handeln ‑ dies macht die Mächtigkeit des ESBKonzeptes aus. Jede Applikation, die auf die eine oder andere
Art Daten konsumieren oder anbieten kann, lässt sich auf diese
Weise einbinden, sofern ein entsprechender Transport-Provider vorhanden ist oder erstellt werden kann. Da Mule jede physikalische
Kommunikation durch die Virtualisierung via Endpoints kapselt,
haben die Serviceobjekte selbst keinerlei Wissen über diese externen
Applikationen.
Ein Channel ist ein Abstraktionsgebilde, das die Kommunikation zwischen den verschiedenen, distinkten Serviceobjekten
oder Mule-Knoten kapselt und die eigentliche Transporttechnologie durch sogenannte Transport-Provider zur Verfügung stellt.
ESB-Kernfunktionalität
Beschreibung
Service Registry
Eine Registry hilft, den Servicekonsumenten vom Serviceanbieter zu entkoppeln. In der Registry wird die Adresse des Serviceanbieters verwaltet.
Transport Protocol Conversion
Ein ESB sollte es auf einfache Art und Weise möglich machen, Applikationen über verschiedene Protokolle wie HTTP(S), JMS, FTP, SMTP oder TCP miteinander zu integrieren.
Message Transformation
Der ESB stellt Funktionalitäten zum Transformieren von Nachrichten von einem Format in
ein anderes Format zur Verfügung, basierend auf offenen Standards wie XSLT und XPath.
Message Routing
Das Bestimmen des Empfängers einer Nachricht ist eine wichtige Funktionalität eines ESB
und wird als Message Routing bezeichnet.
Message Enhancement
Ein ESB stellt Funktionalitäten zur Verfügung, die erlauben, fehlende Informationen in einer Meldung zu ergänzen, was als Message Enhancement bzw. Message Enrichment bezeichnet wird.
Security
Authentisierung, Autorisierung und Verschlüsselung sollten von einem ESB bereitgestellt
werden, einerseits um den ESB vor falschen, eingehenden Nachrichten zu schützen und
anderseits ausgehende Nachrichten so zu schützen, dass sie den Sicherheitsanforderungen
des Serviceanbieters genügen.
Monitoring und Management
Ein Monitoring und Management der Umgebung ist notwendig, um den ESB zu konfigurieren, aber auch um den Meldungsfluss im ESB zur Laufzeit überwachen zu können.
Tabelle 1: Überblick über die Kernfunktionalitäten eines ESB
48
JavaSPEKTRUM 1/2008

Fachthema
Transformer können Nachrichten aus unterschiedlichen Quellformaten in unterschiedliche
Zielformate konvertieren. Entgegen dem allgemeinen Konzept, wonach ein ESB mit einem
kanonischen Format arbeitet (sogenannter
Normalized Message Router), definiert Mule
kein Standard-Nachrichtenformat. Transformer
Abb. 1: Mule-End-To-End-Topologie und die Zusammenarbeit der einzelnen Komponenten
können nach dem „Pipes and Filters“-Konzept
miteinander verkettet werden, sodass komplexe
Umwandlungen aus einfachen, gut wieder verEin Message-Receiver liest oder empfängt Daten von einer wendbaren Transformern zusammengesetzt werden können.
Applikation.
Mule bringt von Haus aus einige sehr nützliche mit, z. B. für
Ein Endpoint ist ein Konfigurations-Wrapper, der Connector, XSLT-Transformationen oder für JMS Message zu Objekten.
Endpoint URI, Transformer, Filter und transaktionale InformatiDie Outbound Router publizieren Nachrichten und Ereignisse
onen zu einem Channel-Adapter kombiniert. Endpoints beschrei- an verschiedene Empfänger, basierend auf unterschiedlichen
ben einen Kommunikationskanal zwischen zwei oder mehreren Regeln, die in der Konfiguration der Router definiert werden.
Serviceobjekten oder Applikationen. Das Konzept der Endpoints
Der Message Dispatcher ist zuständig für das Versenden der
ermöglicht es den Objekten und Applikationen, über jedes Proto- Nachrichten und Ereignisse an die unterliegende Transportkoll in einheitlicher Art und Weise zu kommunizieren.
Technologie.
Inbound Router kontrollieren, welche Nachrichten von einem
Ein Transport-Provider ist ein Plug-In, das es Mule-KompoServiceobjekt empfangen werden, das an einem bestimmten nenten erlaubt, Informationen über ein bestimmtes Protokoll
Channel registriert ist. Sie lassen sich zum Filtern und/oder oder Technik zu versenden oder zu empfangen. Mule kennt
zum „Resequencing“ von Nachrichten nutzen, bevor diese Transport-Provider für diverse Protokolle wie JMS, HTTP, TCP,
vom Serviceobjekt empfangen werden. In Mule basieren alle XMPP, SMTP, File, FTP, SOAP, usw.
Router auf dem „Selective Consumer“-Muster, d. h. sie können
mit Filterkriterien ausgestattet werden. Es gibt eine ganze Reihe von Standard-Routern, die verschiedene, häufig genutzte Einfaches Beispiel-Szenario und die Umsetzung mit Mule
Funktionalitäten anbieten, z. B. Aggregatoren.
Ein Connector kapselt die technischen Details, wie eine Nach- Nach soviel Theorie nun zur Praxis: Als Beispiel dient die Verricht physikalisch über einen bestimmten Channel transportiert arbeitung von Bestellvorgängen. Abbildung 2 zeigt die beteilig­
wird. Mit dem Connector ist ein Message-Receiver verbunden, ten Komponenten in der Enterprise-Integration-Patterns-Notader die Daten aus dem gekapselten Transportkanal empfängt.
tion [Hophe04]:
Am wichtigsten sind natürlich auch in einem Integrations- 1) Eine Legacy-Anwendung stellt Bestelldaten eines Zeitprojekt die Komponenten, bei Mule Serviceobjekt oder auch
raums per XML-Datei zur Verfügung.
UMO (Universal Message Object) genannt. Diese sind in Mule 2) Diese werden vom System mit einem File Poller eingelenormalerweise einfache POJOs, welche bestimmten Kriterien
sen, dann in einzelne Datensätze aufgesplittet, in ein stangenügen müssen. So dürfen sie beispielsweise nur eine Methodardisiertes Format gewandelt und so zur weiteren Verarde mit einer zum Nachrichtentyp passenden Signatur besitzen.
beitung in eine JMS-Queue gestellt.
Ist dies nicht der Fall, dann kann der Standard-EntryPointResolver 3) Parallel dazu kommen von einem externen Reseller ebennicht auflösen, welche Methode aufzurufen ist. In solchen Fälfalls Bestellvorgänge, die bereits per Messaging angeliefert
len kann man sich mit einem Wrapper behelfen, welcher das
werden. Diese Daten werden von einer Messaging Bridge
Callable-Interface implementiert. Wird dieses von einem Serentgegen genommen, in das einheitliche Format umgeviceobjekt implementiert, dann wird immer nur die darin defiwandelt und an dieselbe JMS-Queue weitergeleitet.
nierte onCall-Methode aufgerufen, die den Aufruf dann an das 4) Als nächster Schritt wird eine Kreditprüfung für den Beeigentliche Serviceobjekt weiterreichen kann.
steller durchgeführt. Hierzu wird ein Webservice eines ex-
Abb. 2: Beispiel-Szenario: Order Processing
www.javaspektrum.de
49
Fachthema 
ternen Dienstleisters über einen Request/Reply-Aufruf in
Anspruch genommen.
5) Das Ergebnis der Kreditprüfung wird über einen Content Enricher der Bestellung hinzugefügt. Abhängig von
der Kreditprüfung wird die Bestellung über einen contentbased Message Router dann
6) entweder der Order Fulfillment-Anwendung übergeben
7) oder einem Vertriebsmitarbeiter, der die Bestellung manuell prüft und gegebenenfalls mit dem Besteller Kontakt
aufnimmt.
Wie kann dieses Beispiel mit Mule umgesetzt werden? Den
vollständige Code finden Sie auch zum Download [SIGS].
File Poller
Der File Poller ist rasch umgesetzt, da alle notwendigen Bestandteile von Mule bereits zur Verfügung gestellt werden. Es
wird ein Endpoint definiert, welcher ein Verzeichnis auf neue
Dateien überwacht, und diese einliest, sobald sie vorliegen.
Dabei bietet der File-Transport von Mule auch gleich die Möglichkeit, die Datei nach dem Einlesen zu löschen oder in ein
Archiv-Verzeichnis zu verschieben. Das zu überwachende Verzeichnis wird in der Endpoint-URL angegeben.
Wir haben uns in diesem Beispiel dafür entschieden, die Konfiguration der Eigenschaften des Pollers ebenfalls in der URL vorzunehmen. Alternativ ist auch die Konfiguration eines globalen Connectors möglich, der referenziert werden könnte. Wichtig bei der
Definition von Eigenschaften in der Endpoint-URL ist, dass das
verbindende Und-Zeichen als & maskiert wird (s. Listing 1).
Auf welche Dateien der File Poller reagieren soll, wird als Filter für den Eingangs-Router umgesetzt. Ein echtes Serviceobjekt in der Mule-Nomenklatur benötigen wir hierbei nicht, da
es sich um reine Integrationsfunktionalitäten handelt, die keine
eigene Implementierung benötigen. Deshalb verwenden wir
als Implementierungsklasse für das Serviceobjekt eine Bridge­
<transformers>
<transformer name="legacyToInternal"
className="org.mule.transformers.xml.XsltTransformer">
<properties>
<property name="xslFile" value="xslt/legacyToInternal.xslt"/>
</properties>
</transformer>
<transformer name="ObjectToJMSMessage"
className= "org.mule...ObjectToJMSMessage"/>
</transformers>
<connector name="activeMQConnector"
className="org.mule.providers.jms.JmsConnector">
...
</connector>
<mule-descriptor name="filePoller"
implementation="org.mule...BridgeComponent">
<inbound-router>
<endpoint address=
"file:///C:/temp/in?pollingFrequency=1000&amp;moveToDirectory=C:/temp/
done">
<filter pattern="orders*.xml"
className="org.mule...FilenameWildcardFilter"/>
</endpoint>
</inbound-router>
<outbound-router>
<router className=
"org.mule...FilteringXmlMessageSplitter">
<endpoint address="jms://orders" connector="activeMQConnector"
transformers="legacyToInternal ObjectToJMSMessage”/>
<properties>
<property name="splitExpression" value="/orders/order"/>
</properties>
</router>
</outbound-router>
</mule-descriptor>
Listing 1: Konfiguration von File Poller
50
Component.
Diese reicht eine eingehende Nachricht unverändert
vom eingangsseitigen zum ausgangsseitigen Router durch.
Als ausgangsseitigen Router verwenden wir einen Filtering­
XmlMessageSplitter, der die Nachrichten im XML-Format vor dem
Senden mit Hilfe eines gegebenen XPath-Ausdrucks in mehrere einzelne Nachrichten aufteilt. Die Transformationskette ist
so konfiguriert, dass mit legacyToInternal zuerst auf allen ausgehenden Nachrichten eine XSLT-Transformation durchgeführt
wird, die aus dem Format der Altanwendung eine Standardformat für die interne Infrastruktur macht (sogenanntes Canonical Data Model) und dann mit ObjectToJMSMessage die eigentliche
JMS-Nachricht erzeugt wird. Listing 1 zeigt die Konfiguration
für den File Poller.
External Messaging Bridge
Als nächstes implementieren wir die Brücke zwischen dem
externen und dem internen Messaging-System. Sie dient dazu, die Bestellungen, die vom Reseller über eine VPN-Verbindung per ActiveMQ geliefert werden, in das interne QueueingSystem zu transferieren. Auch hier handelt sich um eine reine Integrationsfunktionalität, bei der keine eigene Logik benötigt wird, weshalb wiederum eine BridgeComponent verwendet
wird. Als Transport auf der Eingangsseite konfigurieren wir einen JMS-Konnektor für ActiveMQ, auf der Ausgangsseite senden wir Nachrichten über die interne ActiveMQ-Infrastruktur.
Die Nachrichten werden dabei, wie bereits beim File Poller, mit
einem vorgängig konfigurierten Transformer externalToInteral
erst in das interne Datenformat und dann mittels ObjectToJMSMes­
sage in eine JMS-Nachricht umgewandelt. Listing 2 zeigt die dafür notwendigen Konfigurationselemente.
Credit Checker
Die letzte Verarbeitungseinheit im Beispiel ist die Kreditprüfung im Credit Checker. Diese nimmt eine eingehende Bestellung entgegen, extrahiert aus den Daten die Kundennummer
und ruft damit einen Webservice auf, der die Aufgabe hat, das
Rating des Kunden zu bestimmen. Das zurückgelieferte Rating
der Kreditwürdigkeit wird dann mittels Content Enrichment der
Nachricht hinzugefügt. Auf der Eingangsseite ist der Router
wenig interessant, da er alle eingehenden Nachrichten an das
Serviceobjekt weiterleitet. Dabei wird durch den Transformer
<transformers>
<transformer name="externalToInternal"
className="org.mule...XsltTransformer">
<properties>
<property name="xslFile" value="xslt/externalToInternal.xslt"/>
</properties>
</transformer>
<transformer name="ObjectToJMSMessage"
className=
"org.mule..ObjectToJMSMessage"/>
</transformers>
<mule-descriptor name="externalMessagingBridge"
implementation="org.mule...BridgeComponent">
<inbound-router>
<endpoint address="jms://resellerOrders"
connector="activeMQConnector"/>
</inbound-router>
<outbound-router>
<router className=
"org.mule...OutboundPassThroughRouter">
<endpoint address= "jms://orders"
transformers="externalToInternal ObjectToJMSMessage"/>
</router>
</outbound-router>
</mule-descriptor>
Listing 2: Konfiguration der Messaging Bridge
JavaSPEKTRUM 1/2008

Fachthema
gleich eine Konvertierung des String-basierten
XML-Formats in ein DOM-Objekt durchgeführt. Dies erspart
bei der Implementierung des Serviceobjekts CreditCheckEnrich­
er den Aufwand und ist zudem wieder verwendbar. Listing 3
zeigt die Konfiguration des Credit Checker.
Ein sehr interessantes Konzept von Mule steckt hinter dem Nested Router. Dieser wird an ein Java-Interface gebunden, für welches
das Serviceobjekt CreditCheckEnricher eine Setter-Methode besitzen
muss. Mule initialisiert diese Referenz zum Startzeitpunkt über
Dependency Injection mit einer „reflective proxy class“, die den
Service repräsentiert. Damit kann das Serviceobjekt nun auf den
externen Dienst zugreifen, indem einfach eine der Methoden des
gebundenen Interfaces aufgerufen wird. Im Fall der Kreditprüfung wird ein Rating für eine bestimmte Kundennummer abgefragt. Der Aufruf ist dabei naturgemäß immer synchron. Sofern
das Interface gleich bleibt, kann rein deklarativ ein anderer Webservice oder sonstige Quellen konfiguriert werden, ohne das Serviceobjekt anpassen zu müssen. Im Serviceobjekt, das in Listing
4 dargestellt ist, wird außer der Abfrage für das Rating nur der
Rückgabewert in die XML-Nachricht eingefügt.
Auf der Ausgangsseite vom Credit Checker ist auf Mule-Art
das „Content Based Router“-Muster implementiert (s. Listing
3). Dabei werden verschiedene Router vom Typ FilteringOut­
boundRouter mit jeweils einem inhaltsbezogenen Filter definiert,
der bestimmt, an welchen Kanal die zu versendende Nachricht
geschickt wird.
XmlToDomDocument
Mule und Spring
Mule bietet über den Component Resolver einen Plug-In-Point,
über den die Instanzierung und Konfiguration des Serviceobjekts an externe Containerframeworks delegiert werden kann.
<transformers>
<transformer name="XmlToDomDocument"
className="org.mule...XmlToDomDocument"/>
<transformer name="DomDocumentToXml"
className="org.mule...DomDocumentToXml"/>
</transformers>
<mule-descriptor name="creditChecker"
implementation=
"com.trivadis.mule.example.components.CreditCheckEnricher">
<inbound-router>
<endpoint address="vm://orders" transformers="XmlToDomDocument"/>
</inbound-router>
<nested-router>
<binding
interface="com.trivadis.mule.example.services.CreditCheck">
<endpoint address=
"wsdl-xfire:http://localhost:4711/services/creditChecker?WSDL&amp;method=
getRating"
remoteSync="true"/>
</binding>
</nested-router>
<outbound-router>
<router
className="org.mule...FilteringOutboundRouter">
<endpoint address="vm://orderFulfillment"
transformers="DomDocumentToXml"/>
<filter expression="/order/customer/creditRating='A'"
className="org.mule...JXPathFilter"/>
</router>
<router className="org.mule...FilteringOutboundRouter">
<endpoint address="vm://salesRep"
transformers="DomDocumentToXml"/>
<filter expression="/order/customer/creditRating='B'"
className="org.mule...JXPathFilter"/>
</router>
</outbound-router>
</mule-descriptor>
Listing 3: Konfiguration des Credit Checker
www.javaspektrum.de
Um eine Komponente aus dem Spring-Container als Serviceobjekt in Mule nutzen zu können, muss der entsprechende
Spring-ComponentResolver in der Mule-Konfiguration definiert werden:
<mule-configuration>
<container-context className=
«org.mule.extras.spring.SpringContainerContext»>
<properties>
<property name=»configFile»
value=»../conf/applicationContext.xml»/>
</properties>
</container-context>
</mule-configuration>
Damit lässt sich die Implementierung des Serviceobjekts in
Spring als Bean wie folgt konfigurieren:
<beans>
<bean id=”creditCheckEnricher” singleton=”false”
class=”com.trivadis.mule.example.components.CreditCheckEnricher”>
</bean>
</beans>
Es ist wichtig, dass der creditCheckEnricher nicht als Singleton deklariert wird. Mule verwaltet einen eigenen Pool für die Serviceobjekte und kontrolliert deren Lebenszyklus. Spring wird lediglich zur Konfiguration und Objekterzeugung herangezogen. Das
Serviceobjekt selbst wird in Mule nun wie folgt deklariert:
<mule-descriptor name=“CreditCheck“
implementation=”creditCheckEnricher”>
<inbound-router>
...
</inbound-router>
</mule-descriptor>
Wichtig ist das Implementation-Attribut. Es definiert die zu nutzende Bean über deren ID. Damit können die Serviceobjekte
sämtliche Vorteile und Funktionalitäten des Spring-Frameworks, wie Dependency Injection, AOP, Datenzugriffsabstraktionen usw. nutzen.
Ausblick auf Mule 2.0
Das nächste Major-Release von Mule wird Version 2.0 sein. Erste Milestone-Releases sind bereits verfügbar [MuleDownload].
Die Änderungen, die mit dieser Version Einzug halten, sind
hauptsächlich mit dem Wechsel auf Spring 2.0 als Grundlage
public class CreditCheckEnricher {
private CreditCheck creditCheck;
public void setCreditCheck(CreditCheck creditCheck) {..}
public Document enrich(Document doc) {
// Get the credit rating via the configured service
String creditRating =
creditCheck.getRating(doc.getElementsByTagName("customer")
.item(0).getAttributes().getNamedItem("id").getNodeValue());
// Enrich the document
Element rating = doc.createElement("creditRating");
Text value = doc.createTextNode(creditRating);
rating.appendChild(value);
doc.getElementsByTagName("customer").item(0).appendChild(rating);
return doc;
}
}
Listing 4: Implementierung des Serviceobjekts CreditCheckEnricher
51
Fachthema 
ESB-Kernfunktionalität
Bewertung
Bemerkung
Service Registry
-
Möglichkeit von globalen Endpoints vorhanden, jedoch zurzeit keine Integration einer UDDI Registry möglich. Bessere Unterstützung ist mit Mule 2.0 und
später mit der Integration von OSGi zu erwarten.
Transport Protokoll
Conversion
++
Große Anzahl von Transport-Providern für diverse Protokolle und Technologien von Mule mitgeliefert. Zusätzliche z.T. „exotische“ Technologien über
[MuleForge] verfügbar.
Message Transformation
++
XSLT-Transformator vorhanden, eigene Transformationen sind einfach zu
erstellen.
Message Routing
++
Große Anzahl von Routern mit Mule verfügbar. Einfach erweiterbar.
Message Enhancement
+
Über NestedRouter kann jedes Serviceobjekt einen Callout machen.
Security
++
Anbindung an Acegi Security Framework, Unterstützung von Verschlüsselung, Unterstützung von WS-Security für XFire und Axis.
Monitoring und Management
+
JMX-Integration vorhanden, kommerzielle Erweiterung mit Mule HQ [MuleHQ] .
Tabelle 2: Bewertung der Abdeckung der Kernfunktionalitäten (++ sehr gut, +gut, - nicht gut unterstützt, -- überhaupt nicht unterstützt)
verbunden [Mule2]. Damit wird die Konfiguration um einiges
einfacher, da nun eine Schema-basierte Konfiguration mit eigenen Mule-spezifischen Namespaces unterstützt wird. Da viele
Schemata auch gleich Standardwerte setzen, vereinfacht sich
die Konfiguration teilweise erheblich, wie das Beispiel des ActiveMQ-Konnektors zeigt:
<jms:activemq-connector name=“activeMQConnector“/>
Literatur und Links
[Hohpe04] G. Hohpe, B. Woolf, Enterprise Integration Patterns,
Addison-Wesley, 2004
[Mule] Mule Homepage, http://mulesource.org
[MuleBPM] Business Process Management with Mule,
http://mule.mulesource.org/download/attachments/4585/
Mule+and+BPM%2C+BPEL+-+Travis+Carlson.pdf?version=1
[MuleDownload] Mule Download,
Eine weitere interessante Erweiterung soll nach Mule 2.0 mit
der Unterstützung von OSGi dazu kommen. Damit werden in
Zukunft Funktionalitäten wie Hot Deployment, Versionierung
und Isolierung der Dienste und Module besser unterstützt. Zur
Zeit wird von Mule auch eine zukünftige Unterstützung des
SCA-Standards (Service Component Architecture) in Erwägung gezogen.
http://mule.mulesource.org/display/MULE/Download#Download-1.4.3
[MuleForge] Mule Forge, http://www.muleforge.org/
[MuleHQ] Mule HQ, http://www.mulesource.com/products/mulehq.php
[MuleSOA] Mule for Service Oriented Architecture,
http://iambeta.com:8000/say/usr/631079199/MuleSource_MuleSOA.pdf
[MuleSource] MuleSource Homepage, http://mulesource.com
[Mule2] R. Mason, Mule 2 and Beyond,
http://www4.java.no/presentations/javazone/2007/slides/5521.pdf
Fazit
Zusammenfassend kann man sagen, dass Mule einen erfreulich ausgereiften Eindruck hinterlässt. Die Implementierung
komplexer Integrationsszenarien geht mit Hilfe der zahlreichen
standardmäßig bereitgestellten Bausteine schnell von der Hand.
Überhaupt kann festgestellt werden, dass Mule einen großen
Teil der Anforderungen, die man an einen ESB stellen kann, bereits gut unterstützt. Tabelle 2 zeigt unsere Bewertung dazu.
Die Funktionalitäten Orchestrierung und Choreography
überlässt Mule spezialisierten Werkzeugen. So kann seit Mule 1.4. das Werkzeug JBoss jBPM direkt eingebunden werden
[MuleBPM]. Andere BPEL Engines wie Oracle BPEL lassen sich
über SOAP Endpoints einbinden. Dies zeigt auch, dass Mule
nicht nur, wie in diesem Artikel gezeigt, für klassische Integrationsaufgaben eingesetzt werden kann, sondern sich sehr wohl
auch als Basis für eine serviceorientierte Architektur (SOA) eignet [MuleSOA].
Mule besitzt eine sehr aktive Community und stellt über die
Firma MuleSource [MuleSource] auch kommerziellen Support
bereit. Außerdem existiert mit MuleForge [MuleForge] eine
Plattform für den Austausch von Mule-Erweiterungen, wie z.
B. einen Connector für SAP oder SalesForce.
Wir empfehlen, Mule bei jedem größeren aber auch kleineren
Integrations-Projekt mindestens in Betracht zu ziehen.
52
[Pleus07] W. Pleus, JBI und Apache ServiceMix als Enterprise
Service Bus, in: JavaSPEKTRUM, 6/2007
[Rich06] M. Richards, The Role of the Enterprise Service Bus,
http://www.infoq.com/presentations/Enterprise-Service-Bus
[SIGS] MuleSample zeigt die vollständige Implementierung des
Beispiels,
http://www.sigs-datacom.de/sd/publications/js/2008/01/index.htm
Dirk Jablonski arbeitet als Consultant mit dem
Schwerpunkt Java-Technologien für die Firma Trivadis.
Er hat in mehreren Integrationsprojekten Erfahrung mit
verschiedensten Technologien gesammelt, bewegt sich
aber bevorzugt in der Java-Welt.
E-Mail: [email protected].
Guido Schmutz arbeitet als Softwarearchitekt für
die Firma Trivadis, mit den Schwerpunkten Java- und
serviceorientierte Architekturen. Er ist Co-Autor der
beiden Bücher „Spring 2.0 im Einsatz“ und „Architecture Blueprint“. Er führt Architektur- und Technologieberatungen durch, ist als Trainer tätig und unterstützt
Java EE- und SOA-Projekte.
E-Mail: [email protected].
JavaSPEKTRUM 1/2008