Mule 2 - JAXenter

Mule 2

Die Rolle von Spring

Die Integration mit Spring hat bei vielen Mule-1.x-Anwendern eine wesentliche Rolle gespielt, und so haben sich in den letzten Jahren mehrere Möglichkeiten für die Integration von Spring und Mule entwickelt. Dazu zählt die Möglichkeit, den Mule Server aus Spring heraus zu starten, Spring Beans in Mule zu verwenden oder das Empfangen von Spring Bean Events durch Mule. In dem Mule-Artikel [Markus Demolsky: Mule – Open Source ESB, in: Java Magazin 05.2008, S. 80-86
] wurde auf die Verwendung von Spring Beans in Mule eingegangen, d.h. in Spring verwaltete Beans werden in Mule eingebunden. Da Spring sich in vielen Enterprise-Anwendungen als Standard etabliert hat und in der Vergangenheit bei einem Großteil von Mule-Projekten Spring nahezu immer verwendet wurde, hat man bei Mule 2 die Standardkonfiguration nun auf Spring 2.x ausgerichtet. Dadurch ist eine nahtlose Verdrahtung dieser beiden Technologien gegeben, und oben angeführte Anforderungen sind ohne Zusatzimplementierung möglich. Insbesondere können auch weitere relevante Features von Spring verwendet werden:

  • Dependency Injection für das Wiring von komplexen Anwendungen
  • Spring AOP
  • Transaktionsmanagement
  • Ressourcen-Handling
  • Erweiterungen rund um Spring (Modules, OSGi, Security, …)

Der Start von Mule hat sich gegenüber Version 1 auch leicht geändert. Statt des MuleXmlConfiugrationBuilders wird nun der SpringXmlConfiugrationBuilder (im Fall von Spring) verwendet. Hier ist ganz klar ersichtlich, dass mehrere Konfigurationsdateien beim Start eingelesen werden können. Es ist auch empfehlenswert, die Konfigurationsdateien aufzuteilen, um eine klare Trennung zwischen Service Layer und Integration Layer zu haben. Mule- und Spring-Konfigurationen können auch in einem gemeinsamen File vermischt werden, wobei allerdings Vorsicht geboten ist.
Der Mule-Server wird nicht mehr automatisch gestartet, dies muss explizit durch context.start() gemacht werden.

String[] config = new String[]{"application-contex.xml","mule-config.xml"};
MuleContextFactory factory = new DefaultMuleContextFactory();
MuleContext context = factory.createMuleContext(new
                      SpringXmlConfigurationBuilder(config));
context.start();
Mule Context und Registry

Der Mule Manager wurde durch den Mule Context ersetzt und kann als Container gesehen werden, der für den gesamten Lifecycle der darin befindlichen Komponenten zuständig ist. Der Mule Context regelt neben dem Lifecycle-Management auch noch das Transaktionsmanagement oder die Authentifizierung von ein- und ausgehenden Events. Im Mule Context befindet sich wiederum ein Registry Context, der eine Menge an Registries enthalten kann. Das Registry-Konzept ist neu in Mule 2. Ein Registry verwaltet alle ESB-Komponenten, wie etwa Konnektoren, Endpoints, Transformers und Servicekomponenten. Der Mule Context ist so ausgerichtet, dass es zur Laufzeit mehrere Registries geben kann. Ein Registry kann dabei sowohl in der gleichen JVM als auch Remote vorhanden sein. Somit können die Registries auf verteilten Systemen betrieben werden, was auch sehr viele Vorteile für hochverfügbare Systeme mit sich bringt.

Aktuell stellt Mule zwei Implementierungen des Registry zur Verfügung. Das Spring Registry von Mule basiert auf Spring und stellt eine Facade des Spring Application Contexts dar. Das Spring Registry wird beim Initialisieren und Starten des ESB-Servers konfiguriert und kann nachträglich nicht mehr geändert werden. Der Entwickler hat zur Laufzeit nur noch einen Lesezugriff auf dieses Registry.

Dann gibt es noch das Transient Registry, das eine nachträgliche Registrierung von Komponenten nach dem Start ermöglicht, beispielsweise zusätzliche Transformatoren, Konnektoren oder Servicekomponenten. Auf das Transient Registry hat der Entwickler sowohl Lese- als auch Schreibzugriff. Sowohl das Spring Registry als auch das Transient Registry implementieren die abstrakte Klasse AbstractRegistry. Es wäre auch denkbar, ein Registry für den Hivemind-Container zu implementieren.

Das Registry-Konzept stellt bereits Vorarbeiten für den künfigten OSGi Support von Mule dar. Ein schon sehr lange diskutiertes Thema in der Entwicklergemeinde von Mule ist das Hot Deployment von Komponenten zur Laufzeit. OSGi eigent sich dafür hervorragend und wird in einer künftigen Version von Mule vorhanden sein.

Kommentare

Schreibe einen Kommentar

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