Serie „Integrationsarchitektur“ – Teil 3 JMS Implementierungen

In dieser Blog Serie möchte ich einige der wichtigsten Themen und Fragestellungen rund um Enterprise Integration betrachten. Angefangen bei sehr abstrakten Fragestellungen führe ich zu immer konkreteren Beispielen, die dann mit unterschiedlichen ESB Technologien beispielhaft umgesetzt werden. Im heutigen Artikel stelle ich einige JMS Implementierungen sowie Werkzeuge rund um das Thema Messaging vor.

Zu Teil 1 der Serie
Zu Teil 2 der Serie

Im letzten Artikel haben wir einiges über JMS erfahren. Nun werden wir verschiedene JMS Implementierungen und Tools betrachten. Unser Ziel ist es, mit JMS in Berührung zu kommen und einige Details an unterschiedlichen Implementierungen zu betrachten. Wir werden jedoch keine Implementierung in extremer Tiefe betrachten, vergleichen oder gar eine Bestenliste aufstellen.

Apache ActiveMQ

Beginnen wir mit der JMS Implementierung Apache ActiveMQ. Diese kann unter http://activemq.apache.org/ heruntergeladen werden (Möchten Sie später das Tool „HermesJMS“ ausprobieren, empfehle ich die Version 5.1.0). Dort folgen wir auch der Installationsanleitung für unser bevorzugtes Betriebssystem und starten ActiveMQ. Hat das geklappt, können wir uns prompt unter

http://:8161/admin/

mit den Credentials „admin/admin“ in die Administrationsoberfläche von ActiveMQ einloggen und bekommen folgende Übersicht zu sehen:

Abbildung 1 Administrationsoberfläche von ActiveMQ

Ich empfehle, an dieser Stelle etwas mit der Oberfläche zu spielen. Probieren Sie doch mal folgendes:

• Eine Queue anlegen
• Eine oder mehrere Nachrichten auf die neue Queue stellen
• Die Queue „browsen“ (Nachrichten auf der Queue auflisten)
• Die Nachricht lesen, verschieben und löschen

Wir erhalten hier auch für jede Queue eine Liste aller derzeit aktiven Empfänger („Consumer“) (bei Ihnen wird es vermutlich noch keine Consumer geben):

Abbildung 2 Liste der Consumer einer Queue

Hinter jedem Consumer verbirgt sich wiederum eine Connection, die zu einer Remote Adresse führt (z.B. tcp://10.0.1.27:39047). Über diese Verbindung lässt sich feststellen, welche Server Nachrichten von einer Queue verarbeiten. Dies ist hilfreich, wenn Nachrichten verschwinden, z.B. durch Zombie-Prozesse, oder weil sich zusätzlich zum normalen Empfänger ein Entwickler über seine lokale Entwicklungsumgebung als Empfänger registriert hat.

Dieses Vorgehen wiederum ist besonders beim Debugging sehr hilfreich. Tritt ein Problem auf, lässt sich dieses natürlich am besten in einer lokalen Entwicklungsumgebung behandeln. Da uns JMS die Möglichkeit bietet, Nachrichten zwischen den Kommunikationspartnern abzugreifen, können wir die Nachricht, die einen Fehler verursacht, ganz einfach in unsere lokale Umgebung „abzweigen“ und debuggen. Wir können diese Nachricht auch mehrfach hintereinander in die Queue einfügen, ohne dass vorgelagerte Komponenten beteiligt sind:

Abbildung 3 Debugging mit Messaging

Wir können Debuggen und Testen, ohne dass der Trigger ausgelöst werden muss, und ohne dass Anwendung A oder B beteiligt sind. Dies ist z.B. hilfreich, wenn Nachrichten von Anwendung A nur exakt einmal oder nur mit erhöhtem Aufwand bereitgestellt werden können – z.B. weil ein Duplikate-Filter aktiv ist, der entsprechende Entwickler Urlaub hat, im Meeting steckt, die Daten nur einmal täglich geliefert werden usw.

Hermes JMS

Manchmal benötigen wir mehr Flexibilität im Umgang mit den Queues und Topics, als es die Web-Gui von ActiveMQ anbietet. Deswegen betrachten wir nun das Tool „Hermes JMS“. Hermes ist eines der bekanntesten Tools zur Arbeit mit JMS und wird sehr häufig genutzt, um SoapUI-Projekte mit einer JMS-Anbindung zu versehen.

Achtung! Mit den neueren Versionen von ActiveMQ ist Hermes ggf. noch nicht kompatibel. Auf jeden Fall funktioniert es mit der Version 5.1.0.

Für Hermes gibt es unter http://www.hermesjms.com/confluence/display/HJMS/Installing einen Installer zum Download und eine Installationsanleitung. Nach dem Start müssen folgende Schritte durchgeführt werden (Es gibt auf hermesjms.com hilfreiche Dokumentation):

• Provider für ActiveMQ hinzufügen
• JMX in ActiveMQ aktivieren (conf/activemq.xml createConnector auf „true“)

Sobald wir uns mit dem Server verbinden konnten, sehen wir auf der linken Seite eine Liste aller Queues und Topics. Klicken wir eine Queue doppelt an, so öffnet sich rechts eine Liste mit allen Nachrichten, die derzeit auf dieser Queue liegen sowie ein Vorschau-Bereich:

Abbildung 4 Queue Browsen mit HermesJMS

Wir können also sehen, welche Nachrichten derzeit auf die Verarbeitung warten. Zudem ist es möglich, alle Nachrichten in der Queue nach Stichworten zu durchsuchen. Über ein Context-Menü können wir Nachrichten nun außerdem kopieren, einfügen (=neu senden), löschen oder exportieren. Wir sehen außerdem Informationen, wie z.B.

• Wann wird eine Nachricht ungültig (Expiration)?
• An welche Queue wird eine Antwort gesendet (bei Request-Reply Szenarien)?
• Wer hat die Nachricht auf die Queue gestellt?

Über eine separate Ansicht können wir uns Status-Informationen zu jeder Queue anzeigen lassen, wie z.B. Speicherlimits, Anzahl von Nachrichten, Speicherverbrauch, Anzahl Consumer und Producer:

Abbildung 5 Properties einer Queue mit HermesJMS

Auch wenn HermesJMS ein etwas unhandliches Tool ist, bietet es doch alle Möglichkeiten, die wir für die Arbeit mit JMS benötigen.

TIBCO EMS

Als zweite Implementierung möchte ich heute den kommerziellen TIBCO EMS (Enterprise Message Service) vorstellen. Dieser lässt sich als 90-Tage Testversion und nach kostenloser Registrierung unter https://tap.tibco.com/storefront/index.ep downloaden. Nach der Installation muss der Service noch gestartet werden.

Die Konfiguration erfolgt zunächst über das Tool „tibemsadmin“ (im bin-Verzeichnis). Mit

connect tcp://localhost:7222

und den Credentials „admin / <>“ kann es losgehen. „help“ zeigt die wichtigsten Kommandos.

Abbildung 6 TIBCO EMS Administration

Die folgenden Befehle können leicht ausprobiert werden:

• create queue/topic codecentric.test
• create user tobias
• show queues/topics/users

TIBCO EMS kennt zusätzlich zu Queues und Topics noch sogenannte „Bridges“. Eine Bridge besitzt stets eine Quelle und ein Ziel (Jeweils Queue oder Topic). Hiermit lässt sich folgendes innerhalb des Transports umsetzen:

Abbildung 7 Bridges bei TIBCO EMS

Durch die Bridges zwischen einem Topic und mehreren Queues ist es nun möglich, eine Nachricht an viele verschiedene Empfänger zu senden, ohne dass diese zum Zeitpunkt des Sendens als Empfänger auf dem Topic registriert sein müssen. Die Nachrichten verbleiben einfach in der Queue des Empfängers.

TIBCO EMS lässt sich auch mit HermesJMS verwalten, bringt jedoch auch ein eigenes kostenloses Tool namens „GEMS“ (Graphical EMS) mit, welches separat bezogen werden muss. Es ist enorm umfangreich und bietet ähnliche Funktionen wie Hermes, ist jedoch eindeutig auf den TIBCO EMS zugeschnitten.

Wie geht es nun weiter? Im nächsten Artikel setzen wir unsere Architektur mit Messaging in einem ersten Wurf basierend auf dem Open Source ESB „MuleESB“ beispielhaft um.