Welche Funktionalitäten bieten Messagesysteme? Wo liegen die Unterschiede zwischen frei verfügbaren und kommerziellen Messagingsystemen?
Neben einigen kommerziellen Anbietern (IBM, TIBCO, Microsoft und Oracle) tummeln sich diverse Open Source Anbieter in dem Messaging Marktsegment (progress, Apache, Rabbit Technologies, Sun). Im Folgenden wird das Produkt Apache Active MQ vorgestellt, welches anschließend mit dem ebenfalls selbstständigen Messagingsystem IBM WebSphere MQ verglichen wird. Apache Active MQ setzt aktuell den Standard JMS 1.1 (Java Message Service) um.
Unter WebSphere MQ kann nicht direkt über die API auf eine Queue zugegriffen werden. Zuvor muss eine Verbindung mit dem Queue Manager sichergestellt werden, welcher diese Queue verwaltet. Die PUT und GET Befehle sind bei beiden Messagingsystemen in verschiedenen Programmiersprachen realisiert. Neben Java, C, C++, .NET werden auch sprachunabhängige Protokolle wie HTTP unterstützt. Apache Active MQ unterstützt wie WebSphere MQ die Persistierung von Messages in einer Datenbank mittels two phase commit um Transaktionssicherheit zu gewährleisten.
Nun zum Vergleich zwischen Apache Active MQ und WebSphere MQ. Bei einfachen Tests lief Active MQ unter Ubuntu und Windows XP einwandfrei. Bei dem Versuch über einen Java Client 1000 Messages in eine Queue zu putten, kam es allerdings immer wieder nach ca. 500 Messages zu einem Fehler. Es wurde eine Exception geworfen, die sich über das Active MQ Forum, die zentrale Anlaufstelle für Apache Active MQ Probleme allerdings als nicht auflösbar erwies.
Zwar gelang es mir durch Nutzung des clientseitigen Failover Mechanismus schließlich, die Exception abzufangen, allerdings gingen nun 3 der 1000 Messages auf dem Weg zur Queue verloren. Aufgrund dieses Fehlers entschied ich mich dann auf dem Umstieg zum FUSE Message Broker – eine um Qualitätssicherung erweiterte Apache Active MQ Version. Interessant war besonders die Gegenüberstellung in den Bereichen Sicherheit, Konfiguration, Wartung und High Availability.
Bei dem FUSE Message Broker können Zugriffsrechte auf Queue Ebene (Leserecht, Schreibrecht, Vollzugriff) an Gruppen beziehungsweise User vergeben werden, die selbst innerhalb der Konfigurationsdatei des so genannten Brokers definiert werden. Um die User, Benutzergruppen und Zugriffsrechte zentral zu verwalten besteht weiterhin die Möglichkeit einer Nutzung von LDAP. Auch in Websphere MQ können Zugriffsrechte feingranular auf Queue-Ebene vergeben werden.
Dabei wird intern die Primärgruppe des Users ermittelt sowie die dieser zugewiesenen Lese- und Schreibrechte. Mitglieder der Primärgruppe mqm haben dabei stets Vollzugriff auf alle MQ Objekte. Die einzelnen User und Gruppen können ebenfalls in einem LDAP Verzeichnis verwaltet werden zu dem eine Netzwerkverbindung besteht. Im Gegensatz zu WebSphere MQ stellt der FUSE Message Broker kein Tooling zur Konfiguration der Sicherheitseinstellungen zur Verfügung.
Anlaufspunkt für alle Brokereinstellungen ist eine zentrale XML Datei, die alle Konfigurationseinstellungen als Klartext beinhaltet. Dies erwies sich bei umfangreicher Anpassung der Sicherheitseinstellungen als weniger elegant, da immer wieder Fehler bei der Änderung auftauchten, deren Ursache häufig erst nach längerer Zeit gefunden werden konnte. Neben der Autorisierung und Authentifizierung besteht die Möglichkeit den Transport der Messages mittels SSL-Zertifikaten abzusichern. Auch hier erfolgte die Einrichtung mittels der Konfiguration innerhalb der XML-Datei.
Große Unterschiede waren im Bereich der Bedienbarkeit anzutreffen. Hier ging es darum festzustellen, wie schnell alltägliche Aufgaben über die jeweiligen grafischen Oberflächen durchführbar sind und welche Möglichkeiten zum proaktiven Verwalten von Queues und Topics zur Verfügung stehen. Topic- und Queue Objekte können standardmäßig im FUSE Message Broker über eine Weboberfläche verwaltet werden. Neben der Erstellung von Queues und Topics, können bestehende Queues und Topics gelöscht und Inhalte der Queues angezeigt werden. Diese Aufgaben können natürlich auch mittels eines Programms erfüllt werden, welche eine der vielfältigen API’s für den Zugriff auf Active MQ Queues nutzt. Insgesamt ist der Funktionsumfang der Webkonsole eher karg. Im Vergleich dazu kann hier WebSphere MQ punkten. Der WebSphere MQ Explorer bildet die erste Anlaufstelle für typische Administrationstätigkeiten. Hier können Neue Objekte wie Queues angelegt, Eigenschaften der Queues abgefragt und in diesen abgelegte Messages aufgelistet werden. Weiterhin besteht die Möglichkeit über den Windows Explorer Queues auf entfernt liegenden Systemen zu warten. Außerdem stellt WebSphere MQ ein wesentlich ausgereifteres Queue Konzept zur Verfügung.
Es existieren 4 verschiedene Queue Typen – Local, Remote, Transmit und Alias Queue. Besonders letztere die lediglich einen Link auf eine andere lokale Queue herstellt, ist ein komfortables Feature, welches die Flexibilität der Messaginginfrastruktur bedeutend erhöhen kann. Weiterhin können den Queues diverse Eigenschaften zugewiesen werden. Es besteht zum Beispiel die Möglichkeit die Messageanzahl in einer Queue und den erlaubten Umfang zu begrenzen. Um frühzeitig über vollaufende Queues informiert zu werden, können Eventmessages beim Überschreiten von festgelegten Schwellwerten erzeugt werden, die wiederum ein Triggering anderer Anwendungen auslösen. Mittels Accounting and Statistics kann zuverlässig die Performance des MQ Messagingsystems gemonitort werden.
Einmal angeschafft, werden Messagingsysteme häufig von mehreren Anwendungen als Integrationsplattform genutzt. Das bringt eine hohe lokale Queue-Anzahl mit sich. Außerdem müssen Verbindungen zu anderen Queue Managern (WebSphere MQ) beziehungsweise Message Brokern (FUSE Message Broker) immer auf dem aktuellen Stand gehalten werden um den Message-Transport über Systemgrenzen hinweg gewährleisten zu können. Von daher möchte ich hier auf nähere Möglichkeiten der automatisierten Konfiguration eingehen. Wie bereits erwähnt gibt es beim FUSE Message Broker eine zentrale XML Konfigurationsdatei.
Die jeweiligen Elemente zur Aktivierung von Sicherheitsfunktionen, Erstellung von Clustern, Konfiguration von Datenbank-Anbindungen u.a. sind dabei eher sparsam dokumentiert und müssen manuell eingefügt werden. Das ist sehr verwunderlich, so bietet XML eigentlich optimale Bedingungen für eine automatisierte Konfiguration. Es wäre zum Beispiel ein Programm denkbar, was als Wizard fungiert und aus den Benutzereingaben selbst die Konfigurationsdatei erzeugt.
Für die automatisierte Erstellung von Queues und Topics existiert derzeitig noch überhaupt kein Tooling. Unter WebSphere MQ ist das ganz anders. Zur automatisierten Erstellung von Queue Managern und der Verwaltung von Benutzerrechten stehen hier Kommandobefehle zur Verfügung, die auch zum Scripting verwendet werden können.
Für die Verwaltung der einem Queue Manager zugeordneten Objekten wie Queues, Topics und Channel existiert eine komplette Skriptsprache (MQSC). Das hat diverse Vorteile – die erstellten Skripte können häufig mit minimalen Änderungen wieder verwendet werden, bei Bedarf können Queues in kurzer Zeit anhand der Definition wieder hergestellt werden und die Skripte bilden eine solide Dokumentationsbasis, da sie nahezu selbsterklärend sind.
Deutlich besser schneidet der FUSE Message Broker im Bereich High Availability ab. Hier war ich zunächst überwältigt von der Vielzahl der Funktionen – von Failover, Load Balancing, Clustering, Broker Network, Disaster Recovery bis Master-Slave Konfigurationen. Dem setzt WebSphere MQ das Cluster-Konzept entgegen. Im Test funktionierten die Features des FUSE Message Brokers einwandfrei. Mittels Failover kann sichergestellt werden, dass Clients bei Ausfall eines Brokers ihre Anfrage automatisch an einen Alternativbroker weiterleiten. Load Balancing ermöglicht eintreffende Messages innerhalb eines Brokernetzwerkes auf verschiedene Queues gleichmäßig zu verteilen.
Clustering bezeichnet in diesem Fall die Möglichkeit Brokerverbindungen zu erstellen, welche zum systemübergreifenden Messagetransport genutzt werden können. Disaster Recovery und Master-Slave ermöglichen, dass bei Ausfall des Standardbrokers, ein mit diesem synchronisierter Alternativbroker, dessen Funktionen übernimmt, außerdem können durch die Nutzung von RAID Systemen die Folgen von Festplattenausfällen eingeschränkt werden. Am interessantesten ist die Auto Discovery Funktion. Bei Aktivierung der Funktion auf den jeweiligen Brokern, können diese von anderen Brokern gefunden werden und dynamisch Verbindungen aufgebaut werden. Dies ist die einzige Funktion die derzeit nicht in WebSphere MQ realisiert werden kann.
Für den Fall einer Disaster Recovery können Multi Instanz Queue Manager genutzt werden. Die restlichen Features – Load Balancing, Clustering und Queue Manager Netzwerke können alle mittels MQ Cluster realisiert werden. Um mehrere Queue Manager miteinander zu verbinden ohne jede P2P Verbindung explizit anzugeben, wird einem oder mehreren Queue Managern die Funktion des Cluster Repositories zugewiesen. Zur Aufnahme eines Queue Managers in den Cluster muss dieser lediglich einen Clustersender- und einen Clusterreceiverchannel zum Queue Manager anlegen, der als Repository fungiert.
Fazit: Active MQ überzeugt im Funktionsumfang und enttäuscht bei der Bedienbarkeit sowie Konfiguration
Zusammenfassend lässt sich sagen, dass der FUSE Message Broker durchaus in seinem Funktionsumfang mit WebSphere MQ mithalten kann. Deutliche Qualitätsunterschiede zeigten sich eher im Bedienkomfort. Die Konfiguration eines Message Brokers erfordert ein hohes Maß an Erfahrung und technischem Know-How, da ein Großteil der Einstellungen nur spärlich dokumentiert ist. Die Verwendung von FUSE Message Broker als Messagingsystem in einem überschaubaren Integrationsszenario ist aus meiner Sicht dennoch denkbar. Kritisch wird es, wenn erhöhte Anforderungen im Bereich Brokerkonfiguration und Wiederherstellung von Brokerzuständen auftreten.
Mag der Administrations- und Wartungsaufwand bei einer kleineren Anzahl von Brokern noch vertretbar sein, wird er aus meiner Sicht ab einer gewissen Brokerzahl zum k.o Kriterium. Dann kann lediglich durch Hintergrundprozesse die in regelmäßigen Zeitabständen Skripte anstoßen, Accounts und Statistics sowie Eventmessages der Überblick über die aktuelle Messaginglandschaft gewährt werden. Hier empfiehlt sich also der Einsatz von Websphere MQ.