Datum
24.02.2011
Dieser Beitrag wurde verfasst von:
Wie kann durch Mediation auf der Basis eines Messagingsystems lose Koplung zwischen Anwendungen erzielt werden? Gibt es bei der Umsetzung der Mediation Unterschiede zwischen Open Source und kommerziellen Lösungen
Marktüberblick und Vorstellung des Beispielszenarios
Im vorangegangenen Artikel wurden die beiden Messagingsysteme Apache Active MQ und WebSphere MQ verglichen. Damit die von der Anwendung A in die Queue eingereihte Message von der Anwendung B verstanden werden kann, müssen beide sich auf ein einheitliches logisches und physisches Datenformat einigen. Die enge Kopplung kann im Rahmen einer Pipes and Filter Architektur bei der Kommunikation zwischen den beiden Anwendungen gemildert werden.
Als alternative Mediations Frameworks sind im Open Source Bereich Mule und Apache Synapse zu nennen. Kommerzielle Anbieter betrachten Mediation überwiegend als Teilfunktion ihrer jeweiligen ESBs. Innerhalb der IBM WebSphere Brand existiert beispielsweise aktuell keine rein auf Mediation fokussierte Lösung. Deshalb möchte ich nachfolgend Apache Camel mit dem ESB WebSphere Message Broker vergleichen (nicht zu verwechseln mit dem Active MQ Broker und dem FUSE Message Broker). Dabei werden nur Funktionen verglichen, welche beide Produkte unterstützen.
Apache Camel Mediationen basieren auf der in dem Buch “Enterprise Integration Patterns” ausführlich dargestellten Pipes and Filter Architektur. Der Weg einer Message von der Quellanwendung zur Zielanwendung wird als Route bezeichnet. Eine Route besteht aus der Verbindung mehrerer in Reihe geschalteter Filter. Derzeit unterstützt Apache Camel 31 der 65 Patterns. Mehrere Routen können in einem Kontext gebündelt werden. Der Kontext wiederum stellt ein Java-Objekt da, welches Methoden anbietet um die in ihm enthaltenen Java Routen zu aktivieren.
Nun zum Vergleich der beiden Lösungen, der sich diesmal auf die Bewertung der einzelnen Filter, des Entwicklungsprozesses sowie die Einschätzung der Wartbarkeit beschränkt. Grundlage bildet hierfür die Realisierung eines simplen Szenarios.
Adapter
Beide Lösungen stellen zahlreiche Adapter zur Anbindung verschiedener Nachrichtenformate bereit (WebServices, HTTP, FTP, File, Messagingsysteme, Datenbanken, …). Die einzelnen, innerhalb einer Lösung genutzten Adapter werden in Camel an dem zentralen Einstiegpunkt des Programms definiert. Apache Camel weist diverse Abhängigkeiten zu anderen Projekten auf.
Dies spiegelt sich bei Einbindung der meisten Filter wieder – häufig müssen die Dependencies trotz Unterstützung von Maven manuell aufgelöst werden. Dabei kann es passieren, dass im Laufe des Lebenszyklus Dependencies veralten und nicht mehr aufgelöst werden können, was zu Problemen, bei Migrationen, beziehungsweise Erweiterungen von bestehenden auf Apache Camel basierenden Lösungen führen kann. Einmal definierte Adapter können als Quelle oder Ziel einer Route genutzt werden. Die Einbindung von Adaptern läuft im WebSphere Message Broker grundlegend anders ab.
Aus einer feststehenden Palette können Sie als sogenannte Nodes innerhalb eines Message Flows positioniert und anschließend über eine grafische Oberfläche konfiguriert werden. Abhängigkeiten müssen dabei nicht aufgelöst werden.
Filter
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.
Entwicklungsprozess
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.
Wartbarkeit
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.
Fazit: Apache Camel ist ein Mediationsframework – das bedeutet große Teile der Integrationslösung müssen immernoch eigenständig entwickelt werden
Zusammenfassend kann man sagen, dass Apache Camel als Mediations-Framework gut geeignet ist, allerdings nicht mit einem ESB wie dem WebSphere Message Broker mithalten kann. Apache Camel erleichtert die Anbindung diverser Transportprotokolle enorm und legt eine grundlegende Basisarchitektur für die Realisierung von Integrationslösungen fest. Allerdings müssen die besonders zeitaufwendigen Mediationen weiterhin manuell programmiert werden. Beim WebSphere Message Broker hingegen ist die Basisarchitektur über ein intuitiv verständliches grafisches Tooling gekapselt. Selbst komplexe Mediationen können über komfortable Bedienoberflächen schnell erstellt werden.
Autor
Wolfgang Schmidt