Im ersten Blog Artikel zum Thema “Auf Kamelen durch die Wüste der Integration” wurde das Open Source Framework Apache Camel betrachtet. In diesem fortsetzenden Beitrag wird das Thema von der WebSphere Message Broker Seite beleuchtet.
1 - Einführung
Der Websphere Message Broker von IBM bietet eine graphische Oberfläche, in der die Integrationsrouten, beim Broker Message Flows genannt, durch graphische Knoten realisiert werden. Die Knoten können individuell konfiguriert werden, zusätzliche Programmierung erfolgt über sogenannte Compute Nodes, die für verschiedene Sprachen zur Verfügung stehen. Der Standard Compute Node nutzt ESQL, eine abgewandelte Form der SQL-Notation, die speziell für den Message Broker angepasst wurde. Des Weiteren stehen allerdings auch beispielsweise für Java oder PHP Knoten zur Verfügung.
Der Message Broker baut auf Websphere MQ auf, daher muss ein entsprechender Queue Manager zur Verfügung stehen, auf dem ein Message Broker eingerichtet wird. Dieser stellt wiederum eine Execution Group zur Verfügung, auf der der Message Flow läuft.
Der Start des Flows kann dann über verschiedene Input Knoten geschehen. Im Beispiel wurde ein MQ Input als Eingangspunkt gewählt. Die Ländercodes wurden hierbei zum Starten des Flows im XML-Format auf einer Queue abgelegt und von dort ausgelesen.
Es wurde XML gewählt, da dies vom Message Broker nativ gelesen werden kann und so leichter auf die Daten zugegriffen werden konnte.
Es musste an zusätzlicher Konfiguration nur der ODBC-Adapter für die DB2 Datenbank angepasst werden. Der Adapter wurde bereits bei der Installation des Message Brokers installiert und konnte nach Ändern einer initialisierungsdatei und einiger Umgebungsvariablen unter Linux direkt verwendet werden.
2 - Programmstruktur
Der Message Flow besteht aus fünf Knoten plus zusätzlichen Knotenpunkten für Logging und Exception Handling.
Zusätzlich wurde je ein ESQL Skript für die Generierung der REST-Aufrufe und der Datenbankqueries verwendet.
3 - Ablauf
Es wird eine XML-Datei auf einer Queue abgelegt, die alle möglichen Ländercodes für den REST-Service enthält.
Ein Compute Node spaltet die einzelnen Ländercodes auf und setzt für jede so entstehende Nachricht den zugehörigen REST-Aufruf im Header der Nachricht.
Von dort wird vom http-Request Knoten die Adresse des REST-Services ausgelesen und selbiger aufgerufen.
Da der Message Broker in neueren Versionen von Haus aus die JSON-Domäne unterstützt musste die Transformation in ein Java-Objekt hier nicht durchgeführt werden und im Datenbankskript konnte direkt über die JSON-Struktur auf die einzelnen Felder zugegriffen werden.
Zum Abschluss wurden die JSON-Objekte nach dem Schreiben in die Datenbank auf eine Out-Queue abgelegt.
4 - Erweiterbarkeit, Modifizierbarkeit
Die Grafische Oberfläche des Message Broker ist sehr überschaubar und neue Knoten zur Erweiterung können durch Drag-and-Drop hinzugefügt werden. Durch Doppelklick können bestehende Knoten konfiguriert werden.
Der ESQL-Code ist normalem SQL-Code sehr ähnlich und damit sehr leicht verständlich.
5 - Logging und Monitoring
Der Message Broker stellt zum einen Trace-Knoten zur Verfügung, über die an bestimmten Punkten in einem Message Flow eine Log-Nachricht mit im Knoten festgelegtem Inhalt erzeugt wird. Diese wird dann wahlweise in ein Log oder eine Datei ausgegeben.
Zudem besitzt jeder Knoten ein Konfigurationstab für Monitoring, welches weitere Funktionalität für bestimmte Events zur Verfügung stellt.
6 - Exception Handling
Um Fehler abzufangen besitzt der Message Broker zum einen an jedem Knoten Ausgänge für Fehlerbehandlung, so dass zu jedem Zeitpunkt des Flows Fehler abgefangen und behandelt werden können.
Diese Terminals können dann weiter mit Knoten verbunden werden und so behandelt werden.
Zusätzlich stehen spezielle Try/Catch- und Throw-Knoten zur Verfügung, mit denen Fehler abgehandelt werden können.
Fazit
Die angegebene Problemstellung ließ sich sowohl mit Apache Camel als auch mit dem Message Broker komfortabel lösen. Beide Programme bieten hierbei eine ähnliche Herangehensweise, auch wenn die Bedienung des Message Brokers sich, dank der grafischen Oberfläche, etwas einfacher und intuitiver gestaltete.
Auch war beim Message Broker weniger Vorkonfiguration von Abhängigkeiten notwendig, was sich vor allem bei größeren Projekten schnell bemerkbar macht. Ebenfalls zeigte sich hier das Monitoring um einiges leichter.
Die Vorzüge von Apache Camel lagen eindeutig auf der Vielfalt der Aufbaumöglichkeiten. Die Camel Route kann sowohl als Standalone Anwendung mit einem kurzen Java-Programm als auch in einem Container verwendet werden. Beim Message Broker wird immer Websphere MQ vorrausgesetzt.
Insgesamt bietet Apache Camel vor allem in kleineren Projekten eine echte Alternative zu lizenzpflichtigen Produkten. In einem größeren Umfang, mit vielen Endpunkten und langen Routen ist allerdings von Camel als Stand-Alone Lösung abzuraten. In diesem Falle lohnt es sich auf kommerzielle Produkte wie Message Broker zurückzugreifen oder zumindest die Routen als OSGi-Bundle in einem Container wie Websphere Application Server oder Apache Servicemix aufzusetzen.
Für den längeren Betrieb stellt sich auch immer die Frage des Supports. Es gibt zwar von Fuse ein Support-Lizenz Modell für Camel, jedoch hat man damit natürlich auch nicht mehr den Vorteil der gesparten Lizenzkosten, die Apache Camel bietet.
Autor
Philipp Schnürer
X-INTEGRATE Software & Consulting GmbHKontakt