Mediation mittels Transformation und Routing

Zwei sehr häufig innerhalb der Entwicklung einer Integrationslösung genutzte Patterns sind der Message Router sowie der Message Translator.

Message Translator

Insgesamt stellt der WebSphere Message Broker 5 Nodes zur Verfügung um Transformationen zu implementieren. Der ESQL Node eignet sich hervorragend für XML Manipulationen. Ebenso können Transformationen mittels Java Code oder PHP Code realisiert werden. Auch die Nutzung von XSL wird unterstützt. Mittels Mapping, können grafisch Transformationen erklickt werden.

Dazu muss zuvor die logische und physische Struktur einer Message mithilfe eines Messagesets definiert werden. Die logische Struktur kann auf Basis einer Beispiel XML Datei als XSD generiert werden.

Anschließend können für jedes Element der XSD Datei unterschiedliche physische Repräsentationen definiert werden.

Apache Camel bietet mit der Java Processor Klasse lediglich eine Teilmenge der Funktionalität der WebSphere Message Broker Nodes an und ist am ehesten mit dem Java Compute Node vergleichbar. Sie bietet eine Schnittstelle an um den Inhalt einer Message zu lesen, manipulieren und anschließend weiterzuleiten. Die Transformation muss selbst in Java implementiert werden. Das mag bei relativ übersichtlichen XML Dokumenten noch möglich sein – wird allerdings sehr schnell unpraktikabel.

Beinhaltet die XML Datei mit Auftragsinformationen eine oder mehrere Artikel mit unterschiedlicher ID, muss die Anzahl der Einträge beispielsweise zur Laufzeit dynamisch mittels XPath Ausdrücken ermittelt werden und mittels Kontrollstrukturen alle gefundenen Elemente nacheinander ausgelesen werden. Der WebSphere Message Broker bietet wesentlich mehr Tooling um mit solchen Freiheitsgraden der XML Dateien effektiv umgehen zu können.

Message Router

Apache Camel und der IBM WebSphere Message Broker unterstützen beide das Message Router Pattern. Für XML Dateien bieten beide die Auswertung von XML-Elementinhalten mittels XPath an. Darüber hinaus können anhand der definierten logischen und physischen Datenstruktur im WebSphere Message Broker binär codierte Flatfile Dateien ebenfalls inhaltsbasiert geroutet werden. Durch Anreicherung einer binären Datei mit XML Metainformationen, ist dies prinzipiell auch in Apache Camel möglich, erfordert allerdings die Erweiterung einer bestehenden Route um weitere Zwischenschritte.

Die Basisarchitektur der beiden Lösungen weisen große Ähnlichkeiten auf. Was bei dem WebSphere Message Broker „Message Flow“ heißt, kommt der „Route“ in Apache Camel sehr nahe.

Ein „Message Flow“ besteht aus Input- , Verarbeitungs- und Output-Nodes. Ein Node kann als Gegenstück zu den Filtern in Apache Camel gesehen werden. Vereinzelt kann man sogar den Filtern, Nodes gegenüberstellen – Wie zum Beispiel dem Processor-Filter in Apache Camel dem Java Compute Node im WebSphere Message Broker. Trotzdem weichen die Entwicklungsprozesse stark voneinander ab. Apache Camel erfordert umfangreiches Know How zu Spring, Apache Maven und Java. Transformationen müssen wie bereits oben erklärt selbst implementiert werden, Routen mittels XML oder der Java-DSL formuliert und Abhängigkeiten bei Einbindung neuer Filter manuell aufgelöst werden.

Im WebSphere Message Broker erfolgt die Entwicklung größtenteils toolgestützt in dem die Nodes vereinzelt auf einer Sammelfläche platziert werden und danach die Properties über eine grafische Obefläche für diese Nodes gesetzt werden. Anschließend können Verbindungen zwischen den Nodes gezeichnet werden, die die Ausführrichtung des Messageflows kennzeichnen. Bei Manipulationsknoten besteht die Möglichkeit mittels Doppelklick auf den Node nähere Informationen zu den Transformationen einzuholen. Generell basieren diese beim WebSphere Message Broker auf einem Parser, der zwischen logischer und physischer Datenstruktur unterscheidet. Einer logischen Struktur können mehrere physische Datenstrukturen zugewiesen werden.

Dabei wird jedem Element in der logischen Struktur eine Darstellung je physischer Struktur zugeordnet. Dadurch kann die physische Struktur einer Nachricht verändert werden, indem lediglich ein anderes physisches Format für die Message gesetzt wird. Sollen nur ein Teil der Elemente in das andere physische Format übernommen werden, muss eine neue logische Struktur erstellt werden und deren zugehörige physische Struktur. Anschließend sind Transformationen zwischen den logische Datenformaten via Compute (ESQL), JavaCompute (Java) oder Mapping (grafisch) Node möglich.

Bei der Erstellung der physischen und logischen Datenformate unterstützen Wizards beziehungsweise grafische Oberflächen.

Neben dem Entwicklungsprozess, zeigt sich auch im Zuge anfallender Wartungstätigkeiten, dass die toolgestützte Entwicklung Vorteile aufweist.

Durch die Visualisierung der Schrittfolge von Flows, sind diese nahezu intuitiv verständlich. Zudem ist durch Doppelklick auf jeden Node schnell der Zugriff auf diesem Node zugeordneten Quellcode möglich. Die Flowdarstellungen bieten weiterhin einen soliden Ansatzpunkt für die Dokumentation der Integrationslösung. Diese können zu bestehenden Flows automatisiert generiert werden. Die Möglichkeit der Wartung von Apache Camel hängt überwiegend von der Sorgfältigkeit des Entwicklers der Integrationslösung ab. Je besser Java-Klassen in verschiedenen Paketen organisiert sind und der Quellcode kommentiert ist, desto leichter wird die Wartung des Quellcodes fallen. Weiterhin wird es bei Nutzung von Apache Camel im Rahmen komplexer Routen schwer fallen, den Überblick über den Verlauf von Routen zu behalten.

Die Java-DSL stößt hier schnell an ihre Grenzen.