Der Open-Source- ESB Mule

Transkript

1 Ritt auf dem Maultier Der Open-Source- ESB 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-ESB- Implementierungen, 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. 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? 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 ESB- Konzeptes 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 Service Registry Transport Protocol Conversion Message Transformation Message Routing Message Enhancement Security Monitoring und Management Beschreibung Eine Registry hilft, den Servicekonsumenten vom Serviceanbieter zu entkoppeln. In der Registry wird die Adresse des Serviceanbieters verwaltet. 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. 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. Das Bestimmen des Empfängers einer Nachricht ist eine wichtige Funktionalität eines ESB und wird als Message Routing bezeichnet. 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. 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. 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

2 Fachthema Abb. 1: Mule-End-To-End-Topologie und die Zusammenarbeit der einzelnen Komponenten Ein Message-Receiver liest oder empfängt Daten von einer Applikation. Ein Endpoint ist ein Konfigurations-Wrapper, der Connector, Endpoint URI, Transformer, Filter und transaktionale Informationen zu einem Channel-Adapter kombiniert. Endpoints beschreiben einen Kommunikationskanal zwischen zwei oder mehreren Serviceobjekten oder Applikationen. Das Konzept der Endpoints ermöglicht es den Objekten und Applikationen, über jedes Protokoll in einheitlicher Art und Weise zu kommunizieren. Inbound Router kontrollieren, welche Nachrichten von einem Serviceobjekt empfangen werden, das an einem bestimmten Channel registriert ist. Sie lassen sich zum Filtern und/oder zum Resequencing von Nachrichten nutzen, bevor diese vom Serviceobjekt empfangen werden. In Mule basieren alle 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 Funktionalitäten anbieten, z. B. Aggregatoren. Ein Connector kapselt die technischen Details, wie eine Nachricht physikalisch über einen bestimmten Channel transportiert wird. Mit dem Connector ist ein Message-Receiver verbunden, der die Daten aus dem gekapselten Transportkanal empfängt. Am wichtigsten sind natürlich auch in einem Integrationsprojekt die Komponenten, bei Mule Serviceobjekt oder auch UMO (Universal Message Object) genannt. Diese sind in Mule normalerweise einfache POJOs, welche bestimmten Kriterien genügen müssen. So dürfen sie beispielsweise nur eine Methode mit einer zum Nachrichtentyp passenden Signatur besitzen. Ist dies nicht der Fall, dann kann der Standard-EntryPointResolver nicht auflösen, welche Methode aufzurufen ist. In solchen Fällen kann man sich mit einem Wrapper behelfen, welcher das Callable-Interface implementiert. Wird dieses von einem Serviceobjekt implementiert, dann wird immer nur die darin definierte oncall-methode aufgerufen, die den Aufruf dann an das eigentliche Serviceobjekt weiterreichen kann. 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 können nach dem Pipes and Filters -Konzept miteinander verkettet werden, sodass komplexe Umwandlungen aus einfachen, gut wieder verwendbaren Transformern zusammengesetzt werden können. Mule bringt von Haus aus einige sehr nützliche mit, z. B. für XSLT-Transformationen oder für JMS Message zu Objekten. Die Outbound Router publizieren Nachrichten und Ereignisse an verschiedene Empfänger, basierend auf unterschiedlichen Regeln, die in der Konfiguration der Router definiert werden. Der Message Dispatcher ist zuständig für das Versenden der Nachrichten und Ereignisse an die unterliegende Transport- Technologie. Ein Transport-Provider ist ein Plug-In, das es Mule-Komponenten erlaubt, Informationen über ein bestimmtes Protokoll oder Technik zu versenden oder zu empfangen. Mule kennt Transport-Provider für diverse Protokolle wie JMS, HTTP, TCP, XMPP, SMTP, File, FTP, SOAP, usw. Einfaches Beispiel-Szenario und die Umsetzung mit Mule Nach soviel Theorie nun zur Praxis: Als Beispiel dient die Verarbeitung von Bestellvorgängen. Abbildung 2 zeigt die beteiligten Komponenten in der Enterprise-Integration-Patterns-Notation [Hophe04]: 1) Eine Legacy-Anwendung stellt Bestelldaten eines Zeitraums per XML-Datei zur Verfügung. 2) Diese werden vom System mit einem File Poller eingelesen, dann in einzelne Datensätze aufgesplittet, in ein standardisiertes Format gewandelt und so zur weiteren Verarbeitung in eine JMS-Queue gestellt. 3) Parallel dazu kommen von einem externen Reseller ebenfalls Bestellvorgänge, die bereits per Messaging angeliefert werden. Diese Daten werden von einer Messaging Bridge entgegen genommen, in das einheitliche Format umgewandelt und an dieselbe JMS-Queue weitergeleitet. 4) Als nächster Schritt wird eine Kreditprüfung für den Besteller durchgeführt. Hierzu wird ein Webservice eines ex- Abb. 2: Beispiel-Szenario: Order Processing 49

3 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 <transformer name="legacytointernal" classname="org.mule.transformers.xml.xslttransformer"> <property name="xslfile" value="xslt/legacytointernal.xslt"/> </transformer> <transformer name="objecttojmsmessage" classname= "org.mule...objecttojmsmessage"/> <connector name="activemqconnector" classname="org.mule.providers.jms.jmsconnector">... </connector> <mule-descriptor name="filepoller" implementation="org.mule...bridgecomponent"> <endpoint address= "file:///c:/temp/in?pollingfrequency=1000&movetodirectory=c:/temp/ done"> <filter pattern="orders*.xml" classname="org.mule...filenamewildcardfilter"/> </endpoint> <router classname= "org.mule...filteringxmlmessagesplitter"> <endpoint address="jms://orders" connector="activemqconnector" transformers="legacytointernal ObjectToJMSMessage /> <property name="splitexpression" value="/orders/order"/> Listing 1: Konfiguration von File Poller 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 Queueing- System 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 ObjectToJMSMessage 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 <transformer name="externaltointernal" classname="org.mule...xslttransformer"> <property name="xslfile" value="xslt/externaltointernal.xslt"/> </transformer> <transformer name="objecttojmsmessage" classname= "org.mule..objecttojmsmessage"/> <mule-descriptor name="externalmessagingbridge" implementation="org.mule...bridgecomponent"> <endpoint address="jms://resellerorders" connector="activemqconnector"/> <router classname= "org.mule...outboundpassthroughrouter"> <endpoint address= "jms://orders" transformers="externaltointernal ObjectToJMSMessage"/> Listing 2: Konfiguration der Messaging Bridge 50

4 Fachthema XmlToDomDocument gleich eine Konvertierung des String-basierten XML-Formats in ein DOM-Objekt durchgeführt. Dies erspart bei der Implementierung des Serviceobjekts CreditCheckEnricher 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 FilteringOutboundRouter mit jeweils einem inhaltsbezogenen Filter definiert, der bestimmt, an welchen Kanal die zu versendende Nachricht geschickt wird. 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. <transformer name="xmltodomdocument" classname="org.mule...xmltodomdocument"/> <transformer name="domdocumenttoxml" classname="org.mule...domdocumenttoxml"/> <mule-descriptor name="creditchecker" implementation= "com.trivadis.mule.example.components.creditcheckenricher"> <endpoint address="vm://orders" transformers="xmltodomdocument"/> <nested-router> <binding interface="com.trivadis.mule.example.services.creditcheck"> <endpoint address= "wsdl-xfire: getrating" </binding> </nested-router> <router remotesync="true"/> classname="org.mule...filteringoutboundrouter"> <endpoint address="vm://orderfulfillment" transformers="domdocumenttoxml"/> <filter expression="/order/customer/creditrating='a'" classname="org.mule...jxpathfilter"/> <router classname="org.mule...filteringoutboundrouter"> <endpoint address="vm://salesrep" transformers="domdocumenttoxml"/> <filter expression="/order/customer/creditrating='b'" classname="org.mule...jxpathfilter"/> Listing 3: Konfiguration des Credit Checker 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»> <property name=»configfile» </container-context> </mule-configuration> value=»../conf/applicationcontext.xml»/> 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 >... 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

5 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 /> 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. 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. Literatur und Links [Hohpe04] G. Hohpe, B. Woolf, Enterprise Integration Patterns, Addison-Wesley, 2004 [Mule] Mule Homepage, [MuleBPM] Business Process Management with Mule, Mule+and+BPM%2C+BPEL+-+Travis+Carlson.pdf?version=1 [MuleDownload] Mule Download, [MuleForge] Mule Forge, [MuleHQ] Mule HQ, [MuleSOA] Mule for Service Oriented Architecture, [MuleSource] MuleSource Homepage, [Mule2] R. Mason, Mule 2 and Beyond, [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, [SIGS] MuleSample zeigt die vollständige Implementierung des Beispiels, 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. dirk.jablonski@trivadis.com. 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. guido.schmutz@trivadis.com. 52