Betrachten wir das Open Source Integrationsframework Apache Camel einmal aus Entwicklungsperspektive näher bei seinem Wüstenritt. Es gibt viele Möglichkeiten eine einfache Punkt-zu-Punkt Anbindung zu gewährleisten und auch die Auswahl an Software ist überwältigend. Im Rahmen eines Kundenprojektes sollte die Anbindung eines RESTful Webservices an eine DB2 Datenbank realisiert werden. Hierfür wurde zum einen eben genanntes Camel verwendet und als Alternative dieselbe Anbindung im WebSphere Message Broker realisiert.
Die Kundensituation
Es sollten REST-Services aufgerufen werden, und die zurückgegebenen JSON-Objekte transformiert und in eine Datenbank geschrieben werden. Die Aufgabe gliederte sich hierbei grob in drei Teile:
- Aufrufen des Webservices, empfangen der JSON-Objekte
- Transformation der JSON-Objekte für die Weiterverarbeitung
- Speichern der Informationen in einem Datenbanksatz
Das Aufrufen der Webservices sollte dabei sowohl automatisch nach einer gewissen Zeit wiederholt als auch manuell angestoßen werden können.
Für die exemplarische Darstellung wurde in diesem Beispiel ein CXF-Webservice auf einem Tomcat Server platziert, welcher Länder anhand eines Ländercodes mit Name, Hauptstadt und Kontinent als JSON Objekt ausgibt.
Realisierung mit Apache Camel 2.10.4
Apache Camel ist ein Integrationsframework. Es können Routen erstellt werden, welche Punkte miteinander verbinden. Diese Routen können in einer Vielzahl verschiedener Domain Specific Languages, wie Java- oder Spring-DSL realisiert werden.
Sie können dann beispielsweise von der Kommandozeile oder aus einem Java-Programm heraus gestartet werden oder als OSGi-Bundle oder Servlet in einem entsprechenden Container abgelegt und verwendet werden.
Für die Implementierung in diesem Falle wurde Spring-XML gewählt, die Route wurde mit Hilfe von Maven gestartet.
Für das Auflösen von Abhängigkeiten wurde Apache Maven verwendet. In der POM.xml wurden alle Abhängigkeiten von Camel Bibliotheken und Logging Bibliotheken aufgelöst. Ein zusätzliches Herunterladen von Camel war dadurch nicht mehr nötig.
Die einzige Abhängigkeit, die nicht direkt aus der Maven Repository aufgelöst werden konnte waren die JDBC-Konnektoren für die DB2 Datenbank. Diese mussten zusätzlich heruntergeladen und in den Build-Path eingebunden werden.
Es wurden insgesamt drei Spring-XML Files, zwei Java-Klassen und zwei Java-Objektspezifikationsdateien angelegt.
Die XML-Dateien wurden der Übersichtlichkeit halber aufgeteilt in die Spezifikationen der Route, der Datenbank und der JSON-Übersetzung.
Die Java Klassen dienten des Zusammenbaus der REST-URL und des Querys für die Datenbank.
Die Route selbst wurde in drei Teile aufgespalten:
– Ein Teil zum Einlesen der Daten
– Ein Teil für das Abholen und die Transformation der Daten vom Webservice
– Ein Teil für das schreiben in die Datenbank
Auf diese Weise lässt sich die Eingabe einfach anpassen, es können verschiedene Entry-Points gesetzt werden ohne die weitere Logik der Route zu beeinflussen.
Gleichermaßen kann der Endpunkt, der auf die Datenbank verweist auf diese Weise auch leichter angepasst werden, sollten die Daten beispielsweise noch an weitere Stellen versendet werden.
Zusätzlich wurde ein Endpunkt angebracht, der den Inhalt der Tabelle nach der Verarbeitung in ein Log ausgibt
Es wurden direkte Endpunkte zur Weiterleitung verwendet, im optimalen Falle würde man hier noch Persistenz, zum Beispiel in Form von ActiveMQ Queues hinzufügen.
Das Anstoßen der Route geschieht automatisch alle 5 Minuten. Alternativ kann allerdings auch eine CSV-Datei mit den gewünschten Ländercodes in ein vorgegebenes Verzeichnis kopiert werden und wird von dort konsumiert und Ausgeführt.
Durch die Modulare Struktur der Camel Routen lässt sich das Programm leicht erweitern und Änderungen wie die Adresse der Datenbank oder des Webservices sind in den jeweiligen Dateien leicht vorgenommen.
Der Code im XML Format ist leicht verständlich und kann durch die XML Kommentar-Notation dokumentiert werden.
Camel ist komplett mit Log4j kompatibel und bietet damit die Möglichkeit, sowohl Logs in einer Konsole als auch in Dateien auszugeben.
Camel kann über eine JMX-Schnittstelle angesprochen werden und stellt auch einige APIs zur Verfügung, welche dann in Java angesprochen werden können um eine entsprechende Monitoring Schnittstelle zu ermöglichen.
Camel besitzt auch seit Version 2.5 eine Webkonsole, welche seit Version 2.8 ebenfalls als Servlet aufgesetzt werden kann. Hier können Endpunkte untersucht und Nachrichten an bestimmte Endpunkte geschickt werden. Die Webkonsole muss allerdings gesondert heruntergeladen werden.
Außerdem ist externes Monitoring über den gewählten Container möglich. Zum Beispiel können Websphere Application Server mit der Camel Route als OSGi Bundle oder Apache Tomcat mit der Camel-Route als Servlet verwendet werden und können dann ihre Monitoring Möglichkeiten zur Verfügung stellen.
Exceptions können mit entsprechenden Knoten aus der Camel Route heraus abgefangen und entsprechend abgehandelt werden. Hierfür stehen bestimmte Knotenpunkte zur Verfügung, von denen Camelrouten für die Fehlerbewältigung abgehen können.
Die Fortsetzung, in der die Realisierung mittels des WebSphere Message Brokers gezeigt wird, folgt in Kürze.