Auf Kamelen durch die Wüste der Integration

    Wissensbeitrag - Teil 2

    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
    3 - Ablauf
    4 - Erweiterbarkeit, Modifizierbarkeit
    5 - Logging und Monitoring
    6 - Exception Handling

    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.

    Rechner mit Programmiercode

    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