Mule 2 – The Next Generation

Markus Demolsky

Der Open Source ESB Mule von MuleSource zählt sicherlich zu den Top-Integrationstechnologien im Java-Bereich. In letzter Zeit wird es auch immer lauter bei MuleSource und deren Produktpalette: ESB, Galaxy, Saturn oder HQ. Die Schwerpunkte im letzten Jahr lagen ganz klar auf der neuen Version 2 des ESB, dem REST-Paket und dem Governance Tool Mule Galaxy.

Dieser Artikel stellt die wesentlichen Neuerungen und die Änderungen gegenüber Mule 1.x dar. In den ersten beiden Artikeln „Grundlagen eines ESB“ und „Open Source ESB Mule“ [Markus Demolsky: Mule – Open Source ESB, in: Java Magazin 05.2008, S. 80-86
] wurden die Grundkonzepte eines ESB dargestellt und anhand des Open Source ESB Mule demonstriert. Für diesen Zweck wurde ein Prototyp mit Mule 1.x umgesetzt, der auf www.indoqa.com zum Download bereitgestellt wurde (und hoffentlich viele Interessenten gefunden hat). Der Prototyp wurde nun auf Mule 2.0.0 umgestellt und wird auch in diesem Artikel teilweise als Beispiel herangezogen. Der adaptierte Prototyp ist dort ebenfalls zum Download bereitgestellt.

API-Änderungen

Mule 2 ist ein Major Release und nicht rückwärtskompatibel. Grund genug, sich von Altlasten zu lösen und mit den Erfahrungen aus der Vergangenheit eine stabile und solide Ausgangsbasis zu schaffen. Das neue API ist nun viel klarer und verständlicher, auch dank der neuen Namensgebungen von Interfaces und Klassen. Neben einigen Package-Restrukturierungen wurde auch das UMO-Präfix von sämtlichen Interfaces und Objekten entfernt. API-Änderungen werden auch immer genutzt, um architektonische Verbesserungen vorzunehmen. Die Einführung eines Service Registrys, Vorbereitungen auf OSGi oder die klare Trennung zwischen Service und Komponentenmodell zählen dabei zu den Kernverbesserungen der neuen Version. Des Weiteren sieht die neue Architektur von Mule auch vor, in den nächsten Versionen SCA Support anzubieten.

Konfiguration

Am auffälligsten ist die neue Art der Konfiguration bei Mule 2, die wesentlich mehr Auswirkungen auf die darunterliegende Architektur von Mule hatte, als viele glauben. Die Namensgebung und die Art der Konfiguration haben sich gegenüber Mule 1.x nicht drastisch verändert, sodass es für Mule-1.x-User ein Leichtes ist, die neue Konfiguration zu verstehen. Durch die Verwendung von Schemas wird die Konfiguration von Mule-2-Anwendungen viel einfacher, da der Entwickler auf XML-Werkzeuge und deren vollen Funktionsumfang zurückgreifen kann. Schon die Autovervollständigung und die vorzeitige Validierung von Konfigurationsdateien sind dank der Schemas nun möglich. Nicht zuletzt profitiert auch das zur Verfügung gestellte Eclipse Plug-in von der neuen Schemakonfiguration. Jede Mule-Konfiguration beginnt nun mit einem Header, wie in Listing 1 angeführt. In diesem Fall wird Mule als Default Namespace verwendet. In dieser Konfiguration sieht man auch schon die Verwendung mehrere Schemas. Das Core-Schema definiert die Grundlage von Mule und muss immer verwendet werden. Zusätzlich wird in dieser Konfiguration auch der JMS-Transport verwendet, der durch ein eigenes Schema definiert wird.

Listing 1: Header Mule-2-Konfiguration

Auch Router und Filter machen von der neuen Konfiguration Gebrauch, und die meisten Standardrouter und Filter werden durch das Core-Schema beschrieben. In der alten Version gab es einen globalen <router> bzw. <filter> Tag und der eigentliche Router/Filter wurde durch das Attribut className definiert (beliebte Quelle für Tippfehler). Listing 2 zeigt den Unterschied: In der neuen Konfiguration werden Router und Filter durch eigene Elemente definiert.

Listing 2: Mule-1.x-Konfiguration


Mule-2.x-Konfiguration

Geschrieben von
Markus Demolsky
Kommentare

Schreibe einen Kommentar

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