Ein Esel in dritter Generation entdeckt die Wolke

Mule ESB 3.0

Bernhard Löwenstein

Der Mule ESB hat sich in den letzten Jahren zum populärsten quelloffenen Enterprise Service Bus (ESB) entwickelt. Am 15. September 2010 war es nun so weit und MuleSoft erklärte Version 3.0 der Community-Edition für allgemein verfügbar. Zeit also, einen Blick auf die Neuerungen und Änderungen des neuen Release zu werfen!

Demo zum Download

Hier gibt es die Mule-Demo zum Download.

Mit dem Mule ESB steht der Java-Welt ein leichtgewichtiger Open Source ESB zur Verfügung, der dank der Unterstützung unzähliger Technologien und Protokolle die Integration unterschiedlicher Systeme, Dienste und Applikationen stark vereinfacht. Die neue Version ermöglicht dem Entwickler nun auch die einfache Anbindung an die Cloud und dank des neuen Deployment-Modells die Änderung seiner Mule-Applikation bei laufendem Betrieb. Die Geschichte des Mule ESBs begann im April 2003. Nach zweijähriger Entwicklungszeit und Umzug von SourceForge nach CodeHaus wurde im Frühjahr 2005 die Version 1.0 und fast genau drei Jahre später bereits unter der Schirmherrschaft von MuleSource (mittlerweile MuleSoft) die zweite Version veröffentlicht. Zur Wiederholung wollen wir uns im ersten Schritt die grundlegenden Konzepte des ESBs in Erinnerung rufen. Danach werden wir uns die konkrete Umsetzung dieser Konzepte im Mule ESB anschauen. Mit den Neuerungen und Änderungen in der dritten Version geht es nachfolgend im Detail weiter.

Konzepte des ESBs

Der Begriff des ESBs erlangte 2004 dank David A. Chappell breitere Bekanntheit [3]. Jener bezeichnete dabei Messaging, Web Services, Datentransformation und intelligentes Routing als die vier Grundkonzepte der auf Standards basierenden Integrationsplattform. Charakteristisch für den ESB sind die strikte Trennung zwischen Applikations- und Integrationscode sowie die Möglichkeit zur verteilten Integration. Von zentraler Bedeutung für den ESB ist außerdem das Konzept des Endpunkts. Durch geschickte Kombination der aufgezählten Prinzipien lassen sich viele Zeilen des oftmals bei der herkömmlichen Entwicklung erforderlichen Glue Codes einsparen. Anstatt der Programmierung steht in Verbindung mit der ESB-Integration ganz klar die Konfiguration im Vordergrund.

Umsetzung dieser Konzepte beim Mule ESB

Die zentrale Komponente einer jeden Mule-Applikation ist die Konfigurationsdatei mule_config.xml, in der die Services definiert werden. Ein solcher Service nimmt über einen oder mehrere Inbound-Endpunkte Nachrichten beliebigen Formats entgegen. Bei den Endpunkten sind hierbei unzählige Varianten – vom pollenden FTP-Zugriff auf ein bestimmtes Verzeichnis über die SQL-Abfrage einer Datenbank bis hin zum Lauschen an einem konfigurierten Port nach HTTP-Requests – denkbar. Bei Bedarf können die über die Inbound-Endpunkte empfangenen Nachrichten mittels Transformatoren in ein anderes Format umgewandelt werden. Reichen die verfügbaren Transformatoren nicht aus, dann können eigene entwickelt werden. Auch Filter lassen sich zur Steuerung des Datenflusses einsetzen. Danach werden die Nachrichten an die eigentliche Komponente zur Verarbeitung weitergereicht, wobei eine solche auch fehlen kann, und letztendlich gelangen diese zu einem oder mehreren Outbound-Endpunkten. Auch hier werden Unmengen an verschiedenen Technologien und Protokollen unterstützt. Zur Aufbereitung der Nachrichten für die Weiterleitung an die Outbound-Endpunkte lassen sich die verfügbaren sowie die selbstentwickelten Transformatoren nutzen. In den meisten Fällen wird die Verarbeitung der eingegangenen Nachrichten wohl asynchron erfolgen, wobei auch eine synchrone Abarbeitung möglich ist. Selbstverständlich werden auch Transaktionen und die Behandlung von Ausnahmen unterstützt.

Zum Abschluss der Wiederholung wollen wir uns ein Beispiel für eine solche Konfigurationsdatei ansehen. Der Einfachheit halber werden wir auf die Behandlung möglicher Fehler verzichten. Grundsätzlich sollen hierbei zu einer per HTTP übermittelten Bankleitzahl die zugehörigen Bankdaten über ein öffentliches Web Service ermittelt und im XML-Format an den Aufrufer retourniert werden.

Durch den in Listing 1 definierten Bankservice wird vom Mule ESB ein Webserver gestartet, der HTTP-Anfragen am Port 8080 erwartet. Nach dem Empfang eines solchen Requests werden zwei Transformationen durchgeführt. Im ersten Schritt werden die übermittelten HTTP-Parameter – konkret wird bei diesem Beispiel der Parameter blz erwartet – in einem Map-Objekt abgelegt und im zweiten Transformationsschritt wird mittels eines benutzerdefinierten Transformators das erforderliche Datenformat für den Aufruf des Web Service zusammengebastelt. Als Komponente wird hier eine Standardkomponente des Mule ESBs verwendet, und zwar die Echokomponente, die lediglich die Nachricht auf der Standardkonsole ausgibt. Danach erfolgt der Aufruf des öffentlichen Web Service, der zu der übermittelten Bankleitzahl die Bankdaten zurückliefert. Dynamisch generiert der Mule ESB hierfür die Proxy-Klassen. Damit an den Aufrufer kein Java-Objekt, sondern lesbares XML zurückgeliefert wird, muss zum Abschluss nochmals eine Transformation erfolgen.

Mule ESB 3.0

Durch die umfangreichen Änderungen, unter anderem an der Architektur des Mule ESBs, ist das neue Major-Release nicht rückwärtskompatibel mit vorherigen Versionen. Bestehende Mule-Applikationen müssen daher entsprechend migriert werden, um mit der neuen Esel-Software betrieben werden zu können. Marketingmäßig stellt MuleSoft vor allem die neuen Möglichkeiten zur Anbindung an die Cloud und Integration mit derartigen Applikationen in den Vordergrund. Zwei der Buzzwords der letzten Jahre, nämlich Enterprise Service Bus und Cloud Computing, finden also zusammen! So werden nun nach Aussage der kalifornischen Softwareschmiede entsprechende Konnektoren für die populärsten Cloud-, SaaS- und Web-2.0-Anbieter (z. B. für die Amazon Web Services, Twitter und Facebook) bereitgestellt. Auch verspricht MuleSoft, dass die Entwicklung eigener Cloud-Konnektoren einfach vonstattengehen soll. Des Weiteren erhält der Entwickler mit der neuen Version auch native REST-Unterstützung, die ihm das Bereitstellen sowie die Nutzung von RESTful Services ermöglicht. Daten im JSON-Format lassen sich dabei automatisch in Java-Objekte und natürlich auch wieder zurück transformieren. Außerdem können die Applikationsdaten nun mittels AJAX/JavaScript direkt mit den im Browser laufenden Webapplikationen ausgetauscht werden.

Geschrieben von
Bernhard Löwenstein
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.