Key Visual - Manage Your Business Integration
 

Feb

24

Mediation mittels Transformation und Routing

By Frank Erbsen on Th, Feb/24/2011

Wie kann durch Mediation auf der Basis eines Messagingsystems lose Kopplung 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.

Abbildung 1: Darstellung des Basisszenarios

Abbildung 1 - Darstellung des Basisszenarios

Den Einstiegspunkt in die Mediation bildet die Queue InputQueue. Hier wird eine Nachricht im XML Format platziert. Diese enthält Informationen zu einem Kunden oder zu einem Kundenauftrag.

Abbildung 2: Beispielinhalte für XML Datei mit Kunden- oder Auftragsinformationen

Abbildung 2 - Beispielinhalte für XML Datei mit Kunden- oder Auftragsinformationen

XML Dateien mit Kundeninformationen werden an einen Translator gesendet, welcher das Format der Message in ein fixed length format ändert. Anschließend wird die Message in die Queue CustomerQueue geputtet.

Abbildung 3: Inhalt der Kundeninformationsmessage nach Manipulation durch Translator

Abbildung 3 - Inhalt der Kundeninformationsmessage nach Manipulation durch Translator

XML Dateien mit Auftragsinformationen werden an einen Content Enricher gesendet, wo sie um das aktuelle Datum sowie Uhrzeit ergänzt werden. Anschließend wird die Message in die Queue OrderQueue geputtet.

Abbildung 4: Inhalt der Auftragsinformationsmessage nach Anreicherung durch Content Enricher
Abbildung 4 - Inhalt der Auftragsinformationsmessage nach Anreicherung durch Content Enricher

Abbildung 5: Gegenüberstellung der Flow Darstellungen

Abbildung 5 - Gegenüberstellung der Flow Darstellungen

Abbildung 6: Gegenüberstellung der Transformationslösung – Auftragsinformationen

Abbildung 6 - Gegenüberstellung der Transformationslösung – Auftragsinformationen



Abbildung 7: Gegenüberstellung der Transformationslösung - Kundeninformation

Abbildung 7 - Gegenüberstellung der Transformationslösung - Kundeninformation

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.

Abbildung 8: WebSphere Message Broker Transformations Nodes

Abbildung 8 - WebSphere Message Broker Transformations Nodes

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.

Abbildung 9: Aus der XML Datei mit Kundeninformationen automatisch generierte XSD Datei

Abbildung 9 - Aus der XML Datei mit Kundeninformationen automatisch generierte XSD Datei

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

Abbildung 10: Eigenschaften der Flatfile Definition des XML Elementes „surname“

Abbildung 10 - Eigenschaften der Flatfile Definition des XML Elementes „surname“

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.

Abbildung 11: Grenzen der Java Processor Klasse

Abbildung 11 - Grenzen der Java Processor Klasse

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.

Abbildung 12: Wizard im WebSphere Message Broker zur Erstellung von XPath Ausdrücken als Grundlage des Content Based Routings

Abbildung 12 - Wizard im WebSphere Message Broker zur Erstellung von XPath Ausdrücken als Grundlage des Content Based Routings

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.


Margin
Blog-Autor
Frank Erbsen
Frank Erbsen
Software Engineer
+49 221 97343-47
Margin
Informationen
1. Integration auf Basis von Opensource


2. Qualität der Messagingsysteme

3. Mediation mittels Transformation und Routing

4. SOA durch Einsatz von ESB

7.0.1  7.0.2  8.0  Absatzmarkt  Active MQ  Active  Administration  Agile Lösungen  Agility  AMS  Analyst  Analytics  Anbindung  Anforderungen  Anwenderkonfernz  Apache  Application Server  API Management  API  AS2  ASP  Automatisierung  b2b  B2B Integration  Basic  Big Data  Blogreihe  Bluemix  Blueworks  BPM  Broker  BRMS  Bus  Business Process Management  Business Rules  Buzzword  Camel  Cast Iron  Cloud API  Cloud Computing  Cloud Integration  Cloud  Commerce  Compliance  Conference  Connect:Direct  CPLEX  CXF  DataPower  Decision Server Insights  Deployer  Deployment  Development  DFDL  Digitalisierte Prozesse  Digitalisierung  Domino  DSI  e-Fachverfahren  ersteinrichtung  Edi  Edition  Einführung  Einsatz  Entscheidung  Entwicklung  ESB  Excel  Fahrplanoptimierung  Features  Federated Connectivity  File Transfer  Filetransfer  Finance  FTE  gentran  gis  Geschäftsprozesse  Go Live  Google  Governance  Hardware ESB  Hosting  Hybrid-Cloud  Hybrid Cloud  Hybrid  IBM Blueworks  IBM BPM  IBM Integration Bus  IBM InterConnect  IBM  ILOG DOC  ILOG LNP  ILOG Transportation Analyst  ILOG  Impact  Infrastruktur  Installation  Integration as a Service  Integration Bus  Integration  Integrator  Interoperabilität  IT-Business-Alignment  Konfiguration  Linear  LNP  Logistik  monitoring  M2M  Manage File Transfer  Management  Marktplatz  Mathematik  Mediation  Message Broker  Messages  Messagesight  Messaging  MFT  Migration  Modellierung  MQ  MQTT  Multicast  Muster  Nachlese  Neuerungen in V7.0.1  Neuerungen  off-premise  on-premise  ODM  ODME  Öffentliche Verwaltung  Open Source  Operational Decision Management  Optimierung  OPL  OSGi  Outsourcing  PaaS  Pattern Integration  Pattern  Patterns  Performance  Portfolio  Praxis  Private  Process Server  Produktionsplanung  Prozessautomatisierung  Prozessintegration  Prozessmodelierung  Prozessoptimierung  PureSystem  Qualität  Real Time  Regelmanagement  Rollen  Routenplanung  Routing  ROI  SaaS API  SaaS Integration  SaaS  Salesforce  Schwerpunktanalyse  Script  SCM  Security  Service Federation Management  Servicemix  SFM  SI  Slotting  SoapUI  SOA Cloud Symposium  SOA  SPSS  Standard  Standardplattform  Standardtool  Standortoptimierung  Sterling Integrator  Sterling  SugarCRM  Symposium  Template  TIP  TM1  TOSCA  Transportation  Transportoptimierung  Übersicht  Umstieg  Unix  Update  vergleich  Vorteile  worklight  workload  wtc  Wartung  Websphere  Websphere: Rollen  WebService Security  WebSphere Enterprise Service Bus  WebSphere ESB  WebSphere MessageBroker  WebSphere Technical Conference  WebSphere  WESB  Workloads  WODM  XAR