Mediation mittels Transformation und Routing

Wissensbeitrag

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.

Tippen auf Tastatur

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.

Arbeit am Laptop
Wissen

Qualität der Messagingsysteme

Welche Funktionalitäten bieten Messagesysteme? Wo liegen die Unterschiede zwischen frei verfügbaren und kommerziellen Messagingsystemen? Lesen Sie in diesem Artikel mehr.

Puzzleteil zur Visualisierung von Integration
Wissen

Integration auf Basis von Open Source

Was versteht man unter Anwendungsintegration? Was bedeutet lose Kopplung? Welche wesentlichen Komponenten sind Teil einer Open Source basierten Integrationslösung? Dieser Blogartikel beantwortet Ihnen diese Fragen.

Toyota Logo
Referenz

Schnittstellenintegration von SAP und WebSphere MQ

X-INTEGRATE transformiert die Informationsarchitektur von Toyota Informations-Systeme mit SAP und WebSphere MQ.

Anonyme Referenz
Referenz

Partneranbindung im Finanzbereich

SOA, Service Oriented Architectures und BPM, Business Process Management sind in der Finanzbranche heutzutage nicht mehr wegzudenken. X-INTEGRATE implementierte hierfür bei einem Kunden eine Integrationslösung auf Basis von IBM WebSphere MQ.

Interessiertes Publikum sinnbildlich für IBM Think 2019
Event 06.11.18

X-INTEGRATE auf der IBM THINK 2019

Freuen Sie sich außerdem auf zwei spannende Sessions mit IT-Manager und Geschäftsführer der X-INTEGRATE Software & Consulting GmbH Wolfgang Schmidt zu innovativen Business-Integrationstechnologien.

Puzzleteile zur Visualisierung von Integration
Wissen

Einführungsworkshop in Apache Integrationslösungen

Eine Schulung zu dem Thema „Einführung in die Apache Integrationslösungen“ beschäftigt sich intensiv damit, wie Wissen zu den Produkten Apache ActiveMQ, Camel, CXF und ServiceMix möglichst gut aufbereitet und effizient vermittelt werden kann.

Integration von Geschäftsprozessen mittels Open Source
Wissen

Integration von Geschäftsprozessen mit Open Source

Welche Potentiale haben Open Source Ansätze in einer SOA Implementierung – speziell die der Open Source ESBs (Enterprise Service Bus)?

Wissen

Neuerungen in IBM WebSphere MQ Version 7.1 - Teil 2

Wie kann WebSphere MQ noch schneller und zuverlässiger werden, als es jetzt schon ist? Lohnt es sich auf die neue Version von WebSphere MQ zu migrieren? Im zweiten Teil unseres Blogeintrages über die Neuerungen in der neuen Version von WebSphere MQ werden wir diese Fragen beantworten.

Rechner mit Programmiercode
Wissen

Neuerungen in IBM WebSphere MQ Version 7.1 - Teil 1

Auf der IBM WebSphere Technical Conference 2011 wurden die Neuerungen bei der IBM WebSphere MQ Version 7.1 vorgestellt. Unser Blogartikel fasst das Wichtigste für Sie zusammen.

MAN Logo
Referenz

Dynamische und optimierte Auftragseinplanung

MAN Truck & Bus AG setzt auf einen von X-INTEGRATE mathematisch optimierten Auftragsbestand, um seinen Auftragseinplanungsprozess und die Auftragsoptimierung zu verbessern.

Header
Wissen

Best Practices für die Gentran Integration Suite Migration

Was ist bei der Migration von der Gentran Integration Suite zum Sterling B2B Integrator zu beachten? Wie geht man am besten bei der Migration vor? An welcher Stellen könnten Probleme auftreten? All diese Fragen und mehr beantwortet dieser Blogartikel.

Newtonkugeln
Wissen

Aus zwei mach eins – Das „neue“ IBM Integration Bus

Die IBM hat sich jetzt entschieden den Message Broker und den WebSphere ESB zu einem Produkt zusammenzufassen, IBM Integration Bus (IIB). Dieser Artikel beschäftigt sich mit den Vorteilen und den Migrationswegen von WMB und WESB hin zu IIB.

Tippen auf Tastatur
Wissen

Migration WebSphere ESB zu IBM IIB aus Entwicklersicht

Der IBM Integration Bus (IIB) ist eine Weiterentwicklung des WebSphere Message Brokers, der zusätzlich die Funktionen des WebSphere Enterprise Service Bus enthält. Aus Sicht der Entwicklung ergeben sich durch die Migration auf das Produkt IIB einige neue Aspekte.

Wissen

Migration WebSphere ESB Nach IBM Integration Bus

Mit dem Ende des WebSphere ESB (WESB) als Standalone-Integrationsprodukt steht vielen Kunden bald eine Migration auf den IBM App Connect Enterprise (ACE) bevor. In diesem Blogbeitrag werden die beiden Produkte miteinander verglichen und die bei der Migration zu beachtenden Aspekte beschrieben.

Was braucht man zur Cloud-Integration?
Wissen

Was braucht man zur Cloud-Integration?

Ist eine Speziallösung für die Applikationsintegration in Cloud-Situationen immer sinnvoll? Auf der heute zu Ende gegangenen IBM Konferenz “WebSphere Technical Convention 2012” in Berlin wurden diese und noch mehr Fragen gestellt. Dieser Blogeintrag berichtet Genaueres.

Wissen

Message Broker: Kleines Fixpack mit großer Wirkung

Anfang Oktober 2012 wurde Fixpack 1 für WebSphere Message Broker Version 8 veröffentlicht. Der folgende Blogeintrag beschäftigt sich mit einigen der Neuerungen, die andeuten könnten, wohin sich der Message Broker in Zukunft entwickelt.

IBM InterConnect 2015
Wissen

„The new era of hybrid IT“ – IBM InterConnect 2015

„A New Way to Think“ – „A New Way to Work“ – „A New Way Forward“ – das waren die Leitgedanken der diesjährigen IBM Anwenderkonferenz in Las Vegas mit über 20.000 internationalen Teilnehmern. Welche Themen im Detail behandelt wurden, lesen Sie in diesem Artikel.

Wissen

DataPower oder Cast Iron - Amortisationszeit verkürzen

In einem Programm mit der IBM können Sie nun Ihre alte DataPower oder Cast Iron Appliance gegen neue Appliances umtauschen. Wir können unseren Kunden nun faktisch eine “Alt gegen Neu”-Aktion anbieten und den Fortschritt trotz laufender Amortisationszeit ebnen.

Wolke zur Visualisierung der Cloud
Wissen

Impact Nachlese - Mobile, Cloud und Integration

Wie kann Technologie helfen bessere Geschäftsergebnisse zu erzielen? Das war das Motto der diesjährigen Impact Konferenz der IBM in Las Vegas mit ca. 8500 internationalen Teilnehmern. Dieser Blogartikel fasst unsere Eindrücke zusammen.

Person arbeitet am Computer
Wissen

What's new in Message Broker V8?

Liegt der Fokus beim Message Broker V8 auf neuen Features oder die Erweiterung bestehender Features? Bringen diese für Message Broker Entwickler und Administratoren Produktivitätsgewinne mit sich, die eine Migration auf V8 rechtfertigen? Dieser Blogartikel gibt Antwort darauf.