Serie „Integrationsarchitektur“ – Teil 4 Umsetzung mit Mule

In dieser Blog Serie möchte ich einige der wichtigsten Themen und Fragestellungen rund um Enterprise Integration betrachten. Angefangen bei sehr abstrakten Fragestellungen führe ich zu immer konkreteren Beispielen, die dann mit unterschiedlichen ESB Technologien beispielhaft umgesetzt werden. Im heutigen Artikel werden wir die Architektur mit dem Mule ESB umsetzen.

Zu Teil 1 der Serie
Zu Teil 2 der Serie
Zu Teil 3 der Serie

Im letzten Artikel haben wir einige JMS Implementierungen und Tools kennengelernt. Nun werden wir auf Basis des dort vorgestellten Apache ActiveMQ unsere Architektur mit dem Mule ESB in einem kleinen Beispiel umsetzen. Da auch dieser Artikel ein Ende haben soll, werden viele Details nicht sauber oder sinnvoll umgesetzt sein oder bei den Haaren herbeigezogen wirken, hier bitte ich um Nachsicht.

Rufen wir uns zunächst noch mal die Architektur ins Gedächtnis:

Abbildung 1 Referenzarchitektur

Für ein vollständiges Beispiel zwischen zwei Anwendungen werden also drei Mule Komponenten fällig – zwei Transformatoren und ein Vermittler. Im Beispiel stellt eine Anwendung („Exchange Rate DB“) Wechselkurse in einer XML-Datei bereit, die zweite Anwendung („Exchange Portal“) wird diese über ein Web-Frontend per HTTP abrufen. Am Ende soll die Architektur wie folgt aussehen:

Abbildung 2 Architektur des Beispiels

Alle Sourcen sind verfügbar unter https://github.com/codecentric/eai-architecture-sample-mule .

Gemäß dem Konzept „design by contract“ beginnen wir mit dem Contract. Wir verwenden ein einfaches XML Schema mit einem Request und einem Response Element („getExchangeRate“ und „getExchangeRateResponse“). Damit ist klar, welche Nachricht der ExchangeRateDB Adapter (der die Wechselkurse bereitstellt) erwartet und als Antwort zurückgeben wird.

Kommen wir nun zur Implementierung des ExchangeRateDBAdapters und legen ein gleichnamiges Mule-Projekt an. In dessen POM fügen wir die folgende ActiveMQ Dependency hinzu:

org.apache.activemq
activemq-client
5.10.0

Nun fügen wir ein Global Element vom Typ „Active MQ“ sowie einen JMS Connector hinzu und konfigurieren diese wie abgebildet:

Abbildung 3 JMS Konfiguration

Ein kurzes „Log payload“ dahinter, die Queue in ActiveMQ angelegt, Mule gestartet, und schon können wir Nachrichten empfangen und ausgeben. Als Queue-Namen verwenden wir:

de.codecentric.services.cdm.target.ExchangeRateService.v1

Daran lässt sich von außen schon ablesen, welcher Service hier in welcher Version abgewickelt wird, dass hier gemeinsames Datenmodell gesprochen wird („cdm“) und dass ein Adapter angesprochen wird („target“).

Fügen wir nun noch etwas Integrationslogik hinzu, kommen wir zu den folgenden Flows:

Abbildung 4 Flows des Exchange Rate DB Adapters

Wir haben zwei Flows: Der untere liest das XML mit den Wechselkursen aus einer Datei und speichert das Ergebnis in einem Object-Store zwischen, der obere nimmt Anfragen entgegen, extrahiert die Anfrage-Parameter (Quell- und Ziel-Kurs), liest den Wechselkurs aus dem Object-Store und wandelt das Ergebnis in ein Response XML um.

Legen wir nun eine zweite Mule Komponente namens „ExchangeRateServices“ an und fügen die ActiveMQ-Dependency sowie den JMS Connector wie oben hinzu. Da wir bis jetzt noch keine weitere Logik (z.B. Routing, Splitting) benötigen, brauchen wir nicht mehr als einen JMS-Empfänger sowie einen JMS-Sender:

Abbildung 5 Vermittler Implementierung

Als Queues verwenden wir:

Eingehend: de.codecentric.services.cdm.source.ExchangeRateService.v1
Ausgehend: de.codecentric.services.cdm.target.ExchangeRateService.v1

Alles in allem also eine sehr triviale Komponente. Kommen wir nun zur dritten Komponente „ExchangePortalAdapter“. Hier wollen wir über HTTP einen Aufruf mit zwei Parametern „sourceRate“ und „targetRate“ entgegennehmen und über den Bus den dazugehörigen Wechselkurs abfragen. Auch hier ist die Implementierung sehr einfach:

Abbildung 6 Flows des Adapters für das Exchange Rate Portal

Wir erhalten ein Request per HTTP, wandeln dieses in unsere XML-Struktur um und senden diese per Request-Reply via JMS über den Bus an unseren Vermittler. Dieser leitet die Anfrage an die entsprechende Komponente weiter, und die Antwort geht den gleichen Weg zurück. Am Ende extrahieren wir aus der Antwort noch den Wechselkurs und sind fertig.

Der Rückweg, also die Queues, die beim Senden der Antwort verwendet werden, sind übrigens andere als auf dem Hinweg, auch wenn dies kaum auffällt, denn die Nachrichten können ja nicht dieselben Queues verwenden, da sonst ein „Kreislauf“ entstehen würde. Stattdessen wird für jeden Schritt automatisch eine temporäre Queue angelegt, auf der nur diese eine einzige Nachricht abgelegt wird. Das wird sichtbar, wenn wir die Nachricht zwischen dem Portal und dem Vermittler in der ActiveMQ Konsole betrachten:

Abbildung 7 Temporäre Reply-Queue

Tatsächlich wird der Nachricht schon zu Beginn die Information mitgegeben, auf welcher Queue auf eine Antwort gewartet wird. Dies wird unter dem Feld „Reply To“ vermerkt. Wir könnten hier nun eine Reply-Queue selbst vorgeben oder diese Arbeit vollständig Mule und ActiveMQ überlassen.

Auch wenn wir sehr viele Themen nicht berücksichtigt haben, funktioniert dieses Beispiel und zeigt, wie leicht unsere Architektur basierend auf MuleESB und ActiveMQ umgesetzt werden kann. Schon dieses extrem simple Beispiel bietet die in den vorherigen Artikeln beschriebenen Vorteile einer lose gekoppelten Architektur und ein hohes Maß an Flexibilität.

Wie geht es nun weiter? Im nächsten Artikel werden wir die gleiche Architektur in einem ähnlichen Beispiel mit Apache Camel umsetzen.