Enterprise Middleware mit ActiveMQ

Transkript

1 ITMAGAZINE Enterprise Middleware mit ActiveMQ 17. August Nachrichtenorientierte Middleware ist die Basistechnologie moderner Enterprise-Architekturen, die die Implementierung von Enterprise Integration Patterns sowie den Einsatz anderer Systeme wie Enterprise Service Bus erleichtert. Moderne Geschäftsarchitekturen zeichnen sich häufig dadurch aus, dass verschiedenste IT-Services über mehrere Standorte integriert werden müssen. Dabei müssen einerseits Legacy-Systeme mit neuen integriert, aber auch neue Services modernen Architekturparadigmen folgend flexibel, wiederverwendbar, skalierbar und performant implementiert werden. Um diese Ziele zu erreichen, entstanden Architektur-Strategien wie Service-orientierte (SOA) oder ereignisgetriebene Architektur (EDA), aber auch Technologien wie asynchrone nachrichtenorientierte Middleware (Message Oriented Middleware, kurz MOM) und Enterprise Service Bus (ESB). Typischerweise assoziiert man mit diesen Technologien Namen wie IBM MQ-Series, Tibco oder Sonic. Also durchwegs äusserst hochpreisige Softwarelösungen. Tatsächlich sind in den letzten Jahren aber einige sehr interessante Open-Source-Projekte in diesem Umfeld entstanden, die in einer kleinen Serie betrachtet werden sollen. An erster Stelle steht ein schon relativ alter Bekannter: Apache ActiveMQ. Dieses Projekt implementiert den Java JMS Standard und ist ein JMS-basierter Enterprise Message Broker. Es gehört also in die Kategorie der nachrichtenorientierten Middleware (MOM). Middleware für Nachrichten Was zeichnet eine nachrichtenorientierte Middleware aus? Allgemein gesagt dienen Broker zur Verbesserung der «Connectivity», also dem einfacheren Verbinden von Systemen, die sonst nicht ohne weiteres zusammenarbeiten oder die man gerne entkoppelt betreiben möchte. Auf dieser Ebene werden Message Broker häufig auch von Enterprise-Service-Bus-Systemen unterstützt. Die Aufgabe eines Message Broker ist es, Nachrichten von sendenden Systemen zu empfangen und an die gewünschten Empfänger weiterzuleiten. Das Prinzip gleicht dem eines - oder Instant-Messaging-Servers. Da Message Broker wie ActiveMQ eine Schlüsselfunktion in der IT-Architektur einnehmen, müssen sie sehr zuverlässig arbeiten und viele verschiedene (Architektur-)Szenarien unterstützen. Der Hauptgrund für den Einsatz eines Message Broker ist Reliable Messaging: Dabei muss garantiert werden, dass eine Nachricht, die der Broker übernommen hat, auch zugestellt wird. Ebenso hilft ein Broker bei Load Balancing und Redundanz: Ein System kann eine Nachricht an ein «Zielsystem» senden, hinter dem tatsächlich (vom Broker vermittelt) eine ganze Reihe von gleichartigen Systemen steht, auf welche die Last verteilt wird oder die für ausgefallene Systeme einspringen können. Hat man verschiedene Systeme über MOM verbunden, kann man diese auch leichter überwachen, da Message Broker unter anderem die Möglichkeit bieten, die Last auf verschiedenen Verbindungen anzuzeigen. Ausserdem können sie eine Basistechnologie für andere Middleware wie ESBs oder J2EE-Umgebungen (Geronimo, JBoss, WebLogic) darstellen. SOA: Locker gekoppelt Service-orientierte Architekturen (SOA) sind in aller Munde und werden oft als Architektur-Paradigma für moderne Geschäftsanwendungen gesehen. Häufig werden SOAs mit Webservice-Technologien wie SOAP umgesetzt. Damit hat man zwar Services mit plattformunabhängigen Mechanismen beschrieben, ein wichtiger Punkt von SOAs die lose Kopplung lässt

2 sich jedoch mit diesen Standards noch nicht umsetzen. Der UDDI-Standard wird zwar immer wieder in diesem Kontext erwähnt, hat aber kaum nennenswerte Verbreitung gefunden. Was versteht man nun unter «loser Kopplung»? Verschiedene Services sollen so wenig voneinander wissen wie möglich. Benötigt ein Bestellsystem beispielsweise Informationen über den Lagerbestand eines Artikels, so könnte ein Service existieren, der mit WSDL beschrieben ist, der eben die Abfrage des Lagerbestandes eines bestimmten Artikels erlaubt. Nun ist es aber oft weniger günstig, wenn Clients direkt mit einem bestimmten Server kommunizieren, auf dem dieser Service implementiert ist. Dies wäre eine sehr enge Kopplung und könnte verschiedene Nachteile haben: - Ist der Server down, stehen alle damit verbundenen Clients still. - Bei zu starker Last kann man nicht leicht mehr Server aufstellen. - Sollte es Probleme mit dem Netzwerk oder der Client-Stabilität geben, kann es zu schwierig nachvollziehbaren Kommunikationsproblemen kommen: Ist die Anfrage angekommen? Ist die Antwort angekommen? - Soll der Serverstandort, die Netzwerkadresse oder der Dienstanbieter geändert werden, müssen alle Clients angepasst werden. Ausserdem ist es möglicherweise nicht leicht feststellbar, welche Clients überhaupt den Server verwenden. - Asynchrone Kommunikation, die in vielen Fällen wünschenswert ist, weil sie die Systeme besser entkoppelt, ist über Protokolle wie HTTP nicht leicht möglich. Ebenfalls sind oft Sicherheitsaspekte zu bedenken. Einige dieser Probleme können zwar mit neuen Webservice-Standards wie WS-Reliable Messaging, WS-Policy oder WS-Security gelöst werden. Allerdings muss man feststellen, dass diese Standards komplex sind und es zudem noch kaum brauchbare Implementierungen gibt. MOM kann dafür als Umleitung in der Verbindung zwischen einem Webservice-Client und einem Webservice-Server dienen und die asynchrone Kommunikation sowie zuverlässige Zustellung von Nachrichten (bei Bedarf auch mit Transaktionen über mehrere Nachrichten hinweg) ermöglichen. MOM wie ActiveMQ kann gleichzeitig viele Probleme oftmals einfacher lösen, für die andernfalls die verschiedenen WS-Standards herhalten müssten. Java Messaging Service Der heute vermutlich bedeutendste Messaging-Standard ist JMS (Java Message Service) von Sun. Der Standard war in den letzten Jahren so erfolgreich, dass es mittlerweile APIs für alle wesentlichen Sprachen gibt, beispielsweise auch für C++ oder.net. Die Prinzipien von JMS lassen sich verkürzt wie folgt zusammenfassen: - Es gibt Sender und Empfänger, die übers Netzwerk erreichbar sind.

3 - Zwischen diesen werden Nachrichten (Messages) ausgetauscht. - Eine Message ist ein «atomares» Datenpaket, ist also in sich abgeschlossen. - Message Broker sind für die Zustellung der Nachricht und für verschiedene andere Dienste zuständig. Beispielsweise kann eine sogenannte Multi-Step-Delivery erfolgen. Auch können Nachrichten-Ströme vom Broker gefiltert werden. - Routing und Message-Transformation werden ermöglicht. JMS basiert auf asynchronem Nachrichtenaustausch. Es steht also die asynchrone Zustellung einzelner Nachrichten, nicht Request-Reply-Mechanismen im Vordergrund. Zwar kann man diese auch über JMS abbilden (Reply-to, temporäre Queues), die Grundidee des asynchronen Messaging ist aber eher eine andere. JMS wird daher weniger verwendet, um Clients mit Benutzerinteraktion an Back-end-Systeme anzudocken, als vielmehr, um verschiedenste Backend/Server-Systeme wie beim E-Commerce miteinander kommunizieren zu lassen. Aufbau von JMS Eine JMS-Nachricht besitzt im wesentlichen einen Header mit verschiedenen definierten Feldern wie Message ID oder Priority. Dazu kommen Message Properties, in denen beliebige Key-Value-Datenpaare abgelegt werden können. Dies kann für Meta-Informationen oder überhaupt als Datenspeicher für einfache Nachrichten dienen. Schliesslich gibt es noch den Message Body, in dem die eigentliche Nachricht abgelegt wird. Meist geschieht dies als Text respektive XML, möglich sind aber auch Binärdaten, Java-Objekte und andere unübliche Formate. Der Austausch der Nachrichten erfolgt dabei entweder über eine Queue oder ein Topic. Der Unterschied ist einfach erklärt: Sendet ein Sender an eine Queue, so erhält genau ein Empfänger diese Nachricht. Sendet er hingegen an ein Topic, so können beliebig viele Empfänger diese Nachricht erhalten. Letzterer Fall wird auch als Publish/Subscribe-Mechanismus bezeichnet, bei dem alle die Nachricht erhalten, die ein bestimmtes Topic «abonniert» haben. Dies ist eine sehr elegante Art der Entkoppelung, da der Sender nicht wissen muss, wer eine bestimmte Nachricht empfängt. Auf diese Weise erhält man eine ereignis-getriebene und stark asynchron-entkoppelte Architektur. Auch die Zuverlässigkeit und die Art der Nachrichtenzustellung, beispielsweise für Transaktionen, sind im JMS-Standard beschrieben: - Zustellung muss vom Empfänger bestätigt werden oder «auto-acknowledge». - Zustellung soll transaktional erfolgen. - Nachrichten sollen nur zugestellt werden, wenn der Client online ist.

4 - Nachrichten sollen auch zugestellt werden, wenn der Client offline ist (durable queues). - Der Message Broker soll Nachrichten persistieren. Es darf im Failover-Fall nichts verlorengehen. - Nachrichten haben Prioritäten, Lebenszeiten usw. Ein Message Bus auf JMS-Basis ist also der «One-Stop-Information-Shop» des Unternehmens. Apache ActiveMQ Apache ActiveMQ ist eine sehr stabile und leistungsfähige, gleichzeitig recht einfach zu verwendende Open-Source-Implementierung des JMS-Standards, deren Funktionalität jedoch noch weit über die Kern-JMS-Features hin-ausgeht. Die oben genannten Features werden natürlich unterstützt, daneben bietet ActiveMQ Erweiterungen der Messaging-Funktionalität wie Message Group. Mit diesen können Gruppen von Nachrichten definiert werden, die trotz Load Balancing immer an einen bestimmten Empfänger gesandt werden. Ähnlich arbeiten Composite und Virtual Destinations. Subskriptionen können über Wildcards erfolgen. Man kann sich beispielsweise an eine Gruppe von Topics gleichzeitig anmelden. Auch die Security-Features können sich sehen lassen: Verschiedene Varianten der Authentifizierung und Autorisierung werden angeboten. Autorisierung kann sogar auf Message-Ebene erfolgen. Beide können über Plug-ins erweitert werden. ActiveMQ-Server können auch im Cluster betrieben werden. Das Management erfolgt über den JMX-Standard (Java Management Extension) und beliebige JMX-Clients. Dazu besitzt die neue Version eine einfache Web-Applikation, mit der Topics und Queues überwacht sowie Nachrichten versandt werden können. Der Web-Client ist nicht sehr umfassend, aber man kann wohl davon ausgehen, dass die Funktionalität in Zukunft erweitert wird. Besonders für den Einstieg ist er jedoch sehr hilfreich, weil er in der Standardkonfiguration automatisch startet und hilft, die ersten Messaging-Schritte nachzuvollziehen. ActiveMQ kann mit verschiedensten Systemen integriert werden, beispielsweise mit Komponentenframeworks wie Spring, J2EE-Implementierungen wie Apache Geronimo oder JBoss sowie Enterprise-Service-Bus-Lösungen wie Mule oder Service Mix. Dazu bietet es APIs für eine Vielzahl an Sprachen wie.net, C#, Delphi, Flash, JavaScript, Perl, PHP, Python, Ruby und andere. Auch verschiedene Nicht-JMS-Protokolle werden unterstützt, unter anderem etwa REST, RSS, Atom, XMPP (Jabber Instant Messaging) und Stomp. Die Stomp-Integration ist sehr hilfreich, wenn man Systeme, die noch keinen verwendbaren Konnektor haben, an ActiveMQ andokken möchte. Stomp ist ein einfach zu implementierendes Text-basiertes Protokoll, auf dessen Basis sich auch Konnektoren für Legacy-Systeme aller Art schreiben lassen. Weitere Projekte Im Umfeld von ActiveMQ gibt es eine Vielzahl an kleineren und grösseren Projekten, die sich teilweise auch im Apache-Umfeld befinden wie Camel, CMS und NMS. Die letzteren beiden implementieren APIs für C++ und.net. Besonders interessant ist das recht neue Camel. Camel implementiert die meisten von Gregor Hohpe beschriebenen Enterprise Integration Patterns,

5 unter anderem Pipes und Filter, Content-based Router und Splitter. Mit Hilfe von Camel kann man daher viele in der Integration von Anwendungen häufig vorkommende Muster sehr leicht abbilden und darauf aufbauend Anwendungen entwickeln. Camel arbeitet mit beliebigen JMS-Brokern, ist aber (naturgemäss) sehr gut mit ActiveMQ integriert. Andere ActiveMQ-bezogene Projekte wie Stomp, Lingo oder Jencks, die hier nicht mehr im Detail beschrieben werden können, finden sich teilweise im Codehaus-Projektpool. Zentraler Baustein ActiveMQ ist eine leistungsfähige und stabile JMS-Message-Broker-Implementierung mit «gesunder» Community und einer Vielzahl an grösseren und kleineren «Satelliten-Projekten», die um ActiveMQ kreisen. ActiveMQ kann ein wesentlicher Baustein in einer modernen Enterprise-Architektur darstellen und verträgt sich gut mit vielen anderen Systemen wie ESBs oder J2EE-Containern. Die Lernkurve bei ActiveMQ ist eigentlich nicht sehr hoch, wenn man das Konzept des asynchronen Messaging erst einmal verstanden hat. Allerdings kann die Vielzahl an verwandten Projekten dann doch etwas verwirren. Dies ist allerdings kein Problem von ActiveMQ alleine. Auch kommer-zielle Umgebungen wie Websphere oder Sonic verfügen mittlerweile über eine Unzahl an Komponenten, bei denen es nicht immer einfach ist, den Überblick zu behalten. Es muss jedoch klar sein, dass Systeme wie ActiveMQ im Produktiv-Betrieb Kernkomponenten einer IT-Architektur darstellen und daher sehr gut verstanden werden sollten (Konfiguration, Wartung, Betrieb). Nicht ganz ideal ist die Dokumentation zu ActiveMQ. Das Problem ist allerdings nicht so sehr das fehlende Material als vielmehr die mangelhafte Strukturierung. Im Endeffekt findet man (fast) alles, was man sucht, nur leider ist die Organisation des Materials nicht ideal. Es gibt auch noch kein Buch zu ActiveMQ (sehr wohl aber zu JMS und den Enterprise Integration Patterns). Die Community ist aber lebendig und die Mailingliste im Falle von Detailproblemen immer hilfreich. Stack Active MQ: Die ersten Schritte 1. Active MQ herunterladen und entpacken. 2. Voraussetzungen prüfen: Java-Umgebung muss installiert sein. 3. Kommandozeile öffnen und ins «bin» Verzeichnis wechseln 4../activemq starten (Unix, Mac OS X) ActiveMQ startet dann in einer Standard-Konfiguration, die für erste Experimente mit Sicherheit ausreichend ist. Die neueren

6 Beta-Versionen sowie Snapshots haben auch schon eine einfache Web-Konsole dabei, die unter zu finden ist (siehe Screenshot auf Seite 46). Unter sind ein paar Beispielanwendungen zu finden. Für den operativen Betrieb sollte man natürlich die Konfigurationsmöglichkeiten genauer studieren und entsprechend anpassen. Der Autor Alexander Schatten ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien. Copyright by Swiss IT Media 2017