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.

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.

Kompetenz 29.07.21

Transformation

ARS Kunden stehen vor vielfältigen Transformationsaufgaben und unser Team unterstützt sie hierbei. Ziele sind z.B. wesentlich höhere Flexibilität, Geschwindigkeit oder Agilität.

Service

Cloud Transformation

Mit Cloud Transformation Betriebskosten senken, die Effizienz von IT-Services steigern und Innovationen schneller vorantreiben

Leistung 10.02.22

Technologie Transformation

Wir überführen alte Entwicklungsumgebungen und Legacy-Sourcecode auf eine zukunftsfähige Basis. ► Enterprise DevOps ► Re-Platforming Mainframe & Adabas/Natural-Anwendungen ►CA-TELON Dismissal

Agile Transformation
Kompetenz 20.07.22

Agile Transformation

Teamübergreifende Planung und Strategie durch skalierte Agilität mit Atlassian-Tools - Ihr Einstieg ins erfolgreiche Skalieren agiler Teams.

Service

Digitalisierung und Cloud-Transformation

Wir justieren die Stellschrauben Ihrer individuellen Digitalisierungsinitiative auf Geschwindigkeit, Anpassungsfähigkeit, Sicherheit und Compliance!

Cloud Migration Beratung
Lösung

Txture - Cloud Transformation

Txture ermöglicht die strategische Planung Deiner IT, eine schnelle Cloud-Transformation und die Reduzierung des IT-Risikos in hybriden IT-Umgebungen.

Branche

Omnichannel Retail Transformation

Digitalstrategien im Omnichannel Retail – vom Händler zum Retail Tech-Player: Welche Strategien sollten verfolgt werden, um Kunden auf ihrer Customer Journey nicht zu verlieren?

Headerbild zu Digitale Transformation bei Versicherern
Leistung

Digitale Transformation bei Versicherungen meistern

Digitale Transformation ist der Wandel der Unternehmenswelt durch neue Technologien und das Internet Erfahren Sie, wie Versicherer das meistern können

Service

Agile Transformation & New Work

Das Ziel von New Work & Agile Transformation ist es, schnell und zielgerichtet auf vorhersehbare und unvorhersehbare Ereignisse reagieren zu können.

Service

Process Transformation, Integration & Automation

Mit Process Transformation, Integration & Automation schnell auf Marktveränderungen zu reagieren und die Wettbewerbsfähigkeit nachhaltig zu verbessern.

Kompetenz

Business Innovation & Digital Transformation

Digitalization continues to advance. Innovative providers with new, digital business models are emerging and displacing traditional providers with more analog business models.

Blog 19.09.23

So gelingt die D2C-Transformation mit deinen Mitarbeitern

In dieser Folge von "insights" geht es um das Thema "Wie kannst du deine Mitarbeiter auf der D2C-Reise mitnehmen?" Ein effektives Change Management ist notwendig, um diese Veränderungen erfolgreich umzusetzen. Erfahre in der neuen insights!-Folge, was du dabei alles beachten musst.

Referenz 10.11.22

Helaba – Transformation im Enterprise Umfeld

Erfahren Sie, wie die Helaba ihr Kernbankensystem transformiert hat.

Kompetenz 19.10.22

Digitale Transformation mit Atlassian-Tools

Wir bei catworkx digitalisieren für unsere Kunden Geschäfts- prozesse auf Basis von Atlassian-Tools, wie Jira und Confluence, weil wir von der Flexibilität, Leistungsstärke und Transparenz der Produkte für eine reibungslose Zusammenarbeit von Teams überzeugt sind.

Blog 02.02.23

Computer Aided Cloud Transformation

Was bedeutet Computer aided cloud transformation? Warum ist Enterprise Architecture Management wichtig? Wie gelingt das Asset- und Ressourcenmanagement?

Blog 23.02.23

Geschäftsmodell-Transformation: Erfolgsfaktoren im Commerce

In der heutigen insights!-Folge interviewe ich den General Manager Lighting Solutions & Services, Uwe Graf, von TRILUX. TRILUX hat sich erfolgreich von einem Leuchtenhersteller zu einem Elektronikproduzent transformiert und eine Geschäftsmodellveränderung sowie Vertikalisierung vollzogen. In dieser Folge erfährst du, welche Erfolgsmerkmale es bei einer Geschäftsmodellveränderung im produzierenden Gewerbe gibt und warum die Vertikalisierung des Geschäftsmodells eine entscheidende Komponente dabei ist.

News 01.02.23

Wir bieten Digitale Transformation nun auch im SAP-Ökosystem

TIMETOACT GROUP steigt mit dem Erwerb der WCA Walldorf Consulting und der target Software Solution in die Beratung von cloudbasierten SAP-Lösungen ein

Logo pronova BKK
Referenz

pronova BKK meistert die digitale Transformation

Pronova BKK hatte zum Ziel, eine neue Arbeitsumgebung im Unternehmen einzuführen, um künftig eine schnelle, transparente und effiziente Kommunikation und Zusammenarbeit zu ermöglichen.

Fotografie der Stadt München
Event 16.05.17

IBM Process Transformation Summit 2017

Die IBM lädt vom 19. – 20. September 2017 zum IBM Process Transformation Summit nach München ein. Wolfgang Schmidt, Geschäftsführer der X-INTEGRATE, wird in seinem Vortrag von aktuellen Projekten und der Optimierung von Fertigungsprozessen durch IoT- und Advanced Analytics- Verfahren berichten.

Bleiben Sie mit dem TIMETOACT GROUP Newsletter auf dem Laufenden!