Mule 2

Servicekomponenten

Universal Message Objects (UMOs) waren das Markenzeichen von Mule 1.x und wurden in Mule 2 vollständig eliminiert, schon aufgrund der API-Änderungen. Als UMOs wurden in Mule 1.x die POJOs bezeichnet, welche die Businesslogik beinalten. UMOs wurden mit Endpoints verknüpft, damit diese auf Events reagieren und sie verarbeiten können bzw. Events an weitere UMOs senden konnten. In der neuen Version spricht man nun von Services. Wie auch in Mule 1.x, sind benutzerdefinierte Services einfache POJOs, die auch das Callable-Interface implementieren können. Auch bei der Auflösung des Einstiegspunkts hat sich gegenüber der ersten Version nichts verändert. Listing 5 zeigt die Konfiguration einer Servicekomponente, die in Spring konfiguriert wird, erkennbar durch <spring-object>.

Listing 5: Servicekomponente aus Spring




JMS Inbound mit Bridging
      

Auch die Bridge-Funktionalität hat sich gegenüber der Mule-1.x-Version vereinfacht, wie Listing 5 zeigt. Statt eine Bridge-Komponente extra zu definieren, reicht nur noch die Angabe eines Inbound Endpoints und Outbound Endpoints. Im Prototyp wird für das Empfangen und das Weiterleiten von JMS-Nachrichten eine Bridge-Komponente verwendet, wie in Listing 5 dargestellt. Das Service registriert sich bei einem Topic und empfängt Serviceanfragen. Die Nachricht wird jedoch nur weitergeleitet, wenn der Service Request der Kategorie Copy angehört.

REST mit Mule

Mit Mule 2 wird auch ein vollständiges REST Package mit ausgeliefert, das die Entwicklung von RESTful Services ermöglicht. Es können sowohl RESTful Services erstellt als auch konsumiert werden. Aktuell bietet das REST Package einen Abdera Connector, einen Jersey und Restlet Transport an.

Migration auf Mule 2

Viele Mule-1.x-User werden sich nun fragen, ob zwingend ein Upgrade auf Mule 2 erfolgen muss oder nicht. Die Umstellung auf Mule 2 trifft vor allem Erweiterungen rund um Mule, speziell Projekte, welche auf MuleForge gehostet sind. Projekte wie Extended XML Modul, SAP Transport, LDAP Transport, etc., müssen aufgrund der API-Änderungen geändert werden. Applikationen, die schwerpunktmäßig die Standardfunktionalität von Mule 1.x verwendet und folglich einen Großteil durch Konfiguration ihrer Funktionalität abgedeckt haben, sind recht komfortabel umzustellen. Die Servicekomponenten (sofern nicht das Callable Interface implementiert wurde) können 1:1 übernommen werden, da sie auch in Mule 2 als POJOs behandelt werden.

Fazit

Durch den neuen Konfigurationsmechanismus wird die Konfiugration von Mule-Anwendungen viel verständlicher, und man geht auch in Richtung DSL based configuration. Die transportspezifischen Einstellungen werden nun klar mit XSD definiert und sind letztendlich auch für den Entwickler sehr hilfreich, da er auf die Funktionalität von XML Tools zurückgreifen kann. Gibt sich ein Entwickler mit der Unterstützung von XML-Editoren nicht zufrieden, so kann auch das von Mule bereitgestellte Eclipse Plug-in verwendet werden. Mit Mule 2 wurde ein vollständig neues Plug-in entwickelt, das dem Entwickler die grafische Modellierung von Mule-Komponenten ermöglicht. Mule kann dabei auch problemlos aus der IDE gestartet werden.

Mule 2 ist auch in der neuen Ausführung eine leichtgewichtige Messaging-Plattform und die nahtlose Integration mit Spring-Anwendungen lässt auch in Zukunft vieles versprechen, da auch Basisfeatures von Spring automatisch in Mule genutzt werden können, wie AOP, Transaktionsmanagement, usw. Die gesamte Dokumentation von Mule 2 ist gerade in Bearbeitung, und die Beispiele auf der Homepage werden schrittweise adaptiert. Der Sourcecode der Beispiele ist jedoch schon auf Mule 2 umgestellt worden und bietet einen guten Startpunkt für die Einführung in die neue Version. Der Prototyp wurde ebenfalls auf die neue Version 2 umgestellt und steht ab sofort unter www.indoqa.com zum Download zur Verfügung. Viel Spaß!

Markus Demolsky ist selbstständiger Software-Engineer und Consultant bei Indoqa. Seine Schwerpunkte liegen bei Softwarearchitektur, Workflow-Management-Systemen und Open-Source-Technologien im Java-EE-Umfeld. Er ist Committer bei MuleForge und arbeitet aktuell mit Dr. Alexander Schatten an einem Buch zum Thema „Software Engineering – Best Practices“.
Kommentare

Schreibe einen Kommentar

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