Apache Enterprise Integration
Passend zum Apache Integration Day der W-JAX 2011 präsentieren wir auf JAXenter Artikel, Interviews und Tutorials rund um die Themen Apache Camel, Apache CXF, Apache ServiceMix, Apache ActiveMQ und Apache Karaf.
Alle Infos zum Apache Integration Day gibt´s auf dem W-JAX-Zeitplaner!
Voraussetzungen und Hintergrundinformationen
Es wird vorausgesetzt, dass Sie schon mit ActiveMQ in Berührung gekommen sind. Wenn nicht, empfiehlt sich vor dem Lesen dieses Artikels: Für grundlegende Informationen über JMS ist die Definition in Wikipedia lesenswert [1] und für weitere JMS-Details das Buch unter [2]. Unter dem Link [3] kann man ActiveMQ herunterladen. Für die Installation und einen ersten Start empfiehlt es sich, das richtige „Getting Started“ [4] zu lesen. Danach kann man das Beispiel [5] zum Laufen bringen. Dabei ist es sehr interessant, mittels der Web Console unter http://localhost:8161/admin/queues.jsp den ActiveMQ zu beobachten.In diesem Artikel wird auch die eine oder andere weitergehende Frage angesprochen, die vielleicht eine tiefere Auseinandersetzung mit der Materie erforderlich macht. Dazu empfehlen sich das ActiveMQ Buch [6], die Internetpräsenz von ActiveMQ [3] und Fuse Message Broker [7].
Topics kennen ebenfalls zwei Arten von Clients: Publisher und Subscriber. In diesem Fall ist es jedoch möglich, dass mehrere Subscriber die gleiche Nachricht empfangen.
Im Folgenden gehen wir auf das Queue-Verhalten von ActiveMQ ein. Nach dem KISS-Prinzip hätte eine Queue im Idealfall einen oder mehrere Producer und nur einen Consumer. Oft ist es jedoch erforderlich, entweder aus historischen Gründen oder wegen der Nutzung von ActiveMQ für synchrone Kommunikation, mehrere Consumer einzusetzen. In diesem Fall besteht theoretisch die Gefahr, dass ein Consumer einem anderem die Nachricht wegschnappt. Aus diesem Grund nutzen alle Consumer unterschiedliche Selektoren, um die eigenen Nachrichten herauszufiltern. Mit „Producer“ und „Consumer“ sind in diesem Artikel die Producer- bzw. die Consumer-Anwendung ohne Connection Pool gemeint. In vielen Fällen tritt eine Anwendung sogar in beiden Funktionen auf. Das kann sogar für einen Thread gelten, der ebenfalls gleichzeitig Consumer und Producer sein kann. Hier spricht man über „synchrone Kommunikation“, und in einem solchen Fall werden die oben erwähnten Selektoren genutzt.
Konfiguration und Verbindungsmöglichkeiten
Die Datei activemq.xml ist in den meisten Fällen die einzige Datei, die geändert werden muss, um eine gewünschte Konfiguration zu erzielen. Activemq.xml und alle anderen zu bearbeitenden Dateien befinden sich im /conf-Verzeichnis. Innerhalb des activeMQ.xml befindet sich auch die Transport-Connector-Konfiguration, z. B.:
<transportConnectors><transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/><transportConnector name="ow2" uri="tcp://0.0.0.0:61617"/><transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/></transportConnectors>
Das ist eine typische Konfiguration, die in der Praxis für Standalone ActiveMQ in anspruchsvolleren Systemen vorkommen könnte. Es ist üblich, mehrere Ports für das TCP-Protokoll zu öffnen und einen Port für das STOMP-Protokoll, denn JMS-Clients verbinden sich über TCP-Ports. Um nicht zu viele Clientverbindungen über einen einzelnen Port laufen zu lassen, definiert man standardmäßig mehrere TCP-Ports. Bei ActiveMQ ist openWire das Standardprotokoll für die JMS-Clients. Wenn in einem URI „TCP“ steht, bedeutet das folglich „openWire über TCP“. Ein JMS-Client-Entwickler muss sich keine Gedanken über das openWire-Protokoll machen. Es genügt, wenn activemq-rar.rar bei dem Client deployt ist. Für Clients, geschrieben in C#, C und C++, gibt es Bibliotheken für das openWire-Transport-Protokoll, was die Clientprogrammierung möglich macht, aber nicht unbedingt einfach. Eine gängige Alternative für Non-Java-Clients ist das STOMP-Protokoll, ein sehr einfaches Protokoll, das man sehr gern mithilfe von Telnet für Ping-Tests nutzt [8]. Aus diesen zwei Gründen (Einfachheit, Ping-Tests) ist es empfehlenswert, das STOMP-Protokoll immer zu konfigurieren. Obwohl mit openWire und STOMP grundsätzlich zufriedenstellende Ergebnisse erzielt werden, besteht manchmal Bedarf nach Alternativen. Für anspruchsvolle Entwickler hier ein weiteres Beispiel:
<transportConnectors><transportConnector name="nio" uri="nio://0.0.0.0:61616"/><transportConnector name="udp" uri="udp://0.0.0.0:61617"/><transportConnector name="ssl" uri="ssl://0.0.0.0:61618"/><transportConnector name="http" uri="http://0.0.0.0:61619)"/></transportConnectors>
Der NIO Transport Connector basiert auf dem New-I/O API. Bei sehr vielen Clients oder zu hohem Load für TCP bzw. openWire ist ein Versuch mit NIO eventuell Erfolg versprechend. Eine andere Möglichkeit, die Performance zu verbessern, ist der Einsatz des UDP-Protokolls. Das ist aber nur sinnvoll, wenn Zuverlässigkeit keine so große Rolle spielt. Man erzielt zwar fast immer bessere Ergebnisse, aber in einzelnen Fällen könnten Nachrichten verloren gehen.
Wer höhere Anforderungen bezüglich der Sicherheit hat, kann das SSL-(Secure-Socket-Layer-)Protokoll nutzen. Das SSL-Protokoll basiert genauso wie NIO auf TCP. Es ist lediglich zu beachten, wie üblich eigene private/public Keys bzw. Zertifikate zu generieren und die vorhandenen Standarddateien (*.ts, *.ks *.cert) aus dem /conf-Verzeichnis zu löschen. Während NIO immer zu einer Performanceverbesserung führt, erzeugt SSL aufgrund der ständigen Kodierung/Dekodierung immer eine Performanceverschlechterung. Unter welchen Bedingungen lohnt es sich, HTTP bzw. HTTPS zu verwenden? Nur dann, wenn es sich nicht vermeiden lässt, z. B., wenn eine Firewall sehr restriktiv eingestellt ist und nur das HTTP-Protokoll erlaubt.
ActiveMQ bietet neben STOMP auch das REST- und das Ajax-API. Beide APIs lassen sich mithilfe der schon vorhandenen Webserver (Jetty) nutzen. Jetty startet standardmäßig mit ActiveMQ und es ist nur noch erforderlich, mithilfe der Datei web.xml die Servlets entsprechend zu konfigurieren. Falls Sie über den Einsatz des REST-APIs nachdenken, sollten Sie in Betracht ziehen, dass STOMP mit großer Wahrscheinlichkeit für die gleichen Zwecke besser geeignet ist. Dessen Einfachheit und die einfache ActiveMQ-Implementierung sind starke Argumente für STOMP. Die Verwendung des Ajax-APIs könnte dagegen sehr interessant für die Realtime-Darstellung schnell veränderlicher Daten sein.
