Neue Funktionen in Message Queue 4.1

Message Queue 4.1 war eine Unterversion, die eine Reihe neuer Funktionen, einige Funktionserweiterungen und Fehlerkorrekturen enthielt. In diesem Abschnitt werden die neuen Funktionen in der Version 4.1 beschrieben und weitere Referenzen für Ihre Verwendung angegeben:

• Hochverfügbarkeits-Broker-Cluster

• JAAS-Unterstützung

• Formatänderung für persistenten Datenspeicher

• Broker-Umgebungs-Konfiguration

• Unterstützung für Java ES Monitoring Framework

• Erweiterte Transaktionsverwaltung

• Feste Ports für C-Clientverbindungen

Informationen zu den in Message Queue 4.0 hinzugefügten Funktionen finden Sie unter Neue Funktionen in Message Queue 4.0.

Hochverfügbarkeits-Broker-Cluster

Ab Message Queue 4.1 ist ein neues, erweitertes Broker-Cluster verfügbar. Im Vergleich zu einem konventionellen Broker-Cluster, das nur Nachrichtendienst-Verfügbarkeit bietet (wenn ein Broker ausfällt, ist ein anderer Broker verfügbar, um den Nachrichtendienst bereitzustellen), bietet das erweiterte Broker-Cluster auch Daten-Verfügbarkeit (wenn ein Broker ausfällt, stehen seine persistenten Nachrichten und Statusdaten einem anderen Broker zur Verfügung, der sie verwenden kann, um die Nachrichtenzustellung zu übernehmen).

Die Hochverfügbarkeitsimplementierung ab Message Queue 4.1 verwendet einen gemeinsam genutzten JDBC-basierten Datenspeicher: Anstatt dass jedes Broker-Cluster seinen eigenen persistenten Datenspeicher besitzt, verwenden alle Broker im Cluster dieselbe JDBC-konforme Datenbank. Wenn ein bestimmter Broker ausfällt, übernimmt ein anderer Broker innerhalb des Clusters die Nachrichtenzustellung für den ausgefallenen Broker. Dabei verwendet der Failover-Broker Daten und Statusinformationen aus dem gemeinsam genutzten Datenspeicher. Messaging-Clients des ausgefallenen Brokers stellen eine neue Verbindung zum Failover-Broker her, der ununterbrochenen Nachrichtendienst bietet.

Der freigegebene JDBC-basierte Speicher, der in der Message Queue 4.1-Hochverfügbarkeitsimplementierung verwendet wurde, muss ebenfalls hochverfügbar sein. Wenn Sie keine hochverfügbare Datenbank besitzen oder wenn eine unterbrechungsfreie Nachrichtenzustellung für Sie nicht von hoher Wichtigkeit ist, können Sie weiterhin konventionelle Cluster verwenden, die Dienstverfügbarkeit ohne Datenverfügbarkeit bieten.

Um ein erweitertes Message Queue 4.1-Broker-Cluster zu konfigurieren, geben Sie für jeden Broker im Cluster folgende Broker-Eigenschaften an:

• Eigenschaften für die Clustermitgliedschaft, die angeben, dass der Broker Teil eines erweiterten Broker-Clusters ist, und die ID des Clusters und des Brokers innerhalb des Clusters festlegen

• Eigenschaften für hochverfügbare Datenbanken, die das persistente Datenmodell (JDBC), den Namen des Datenbankherstellers und herstellerspezifische Konfigurationseigenschaften angeben

• Eigenschaften für Fehlererkennung und Failover, die angeben, wie ein Broker-Ausfall ermittelt und mithilfe eines Failover-Brokers behandelt wird

Um die Implementierung mit dem erweiterten Broker-Cluster verwenden zu können, müssen Sie folgende Schritte ausführen:

1. Installieren einer hochverfügbaren Datenbank

2. Installieren der .jar-Datei des JDBC-Treibers

3. Erstellen des Datenbankschemas für den hochverfügbaren persistenten Datenspeicher

4. Festlegen der Hochverfügbarkeitseigenschaften für jeden Broker im Cluster

5. Starten der einzelnen Broker im Cluster

Eine Beschreibung der Konzepte des erweiterten Broker-Clusters und ein Vergleich mit konventionellen Clustern finden Sie in Kapitel 4, Broker Clusters in Sun GlassFish Message Queue 4.4 Technical Overview. Die Vorgehensweise und Referenzinformationen zu erweiterten Broker-Clustern finden Sie in Kapitel 10, Configuring and Managing Broker Clusters in Sun GlassFish Message Queue 4.4 Administration Guide und in Cluster Configuration Properties in Sun GlassFish Message Queue 4.4 Administration Guide.

Wenn Sie eine hochverfügbare Datenbank zusammen mit Message Queue 4.0 verwendet haben und nun zu einem erweiterten Broker-Cluster wechseln möchten, können Sie mit dem Datenbank-Manager-Dienstprogramm (imqdbmgr) die Konvertierung in einen gemeinsam genutzten persistenten Datenspeicher durchführen. Weitere Informationen zu Bekannten Problemen und Einschränkungen finden Sie unter Broker-Cluster.

JAAS-Unterstützung

Neben den dateibasierten und den LDAP-basierten integrierten Authentifizierungsmechanismen wurde in Message Queue 4.1 auch die Unterstützung für den Java Authentication and Authorization Service (JAAS), aufgenommen, sodass Sie einen externen Authentifizierungsmechanismus mit dem Broker verbinden können, um Message Queue-Clients zu authentifizieren.

Eine Beschreibung der Informationen, die ein Broker einem JAAS-konformen Authentifizierungsdienst zur Verfügung stellt und eine Erläuterung der Konfiguration des Brokers zur Verwendung eines solchen Diensts finden Sie in Using JAAS-Based Authentication in Sun GlassFish Message Queue 4.4 Administration Guide.

Formatänderung für persistenten Datenspeicher

In Message Queue 4.1 wurde der JDBC-basierten Datenspeicher dahingehend geändert, dass erweiterte Broker-Cluster unterstützt werden. Aus diesem Grund wird das Format des JDBC-basierten Datenspeichers auf Version 410 erhöht. Die Formatversionen 350, 370 und 400 und werden automatisch zu Version 410 migriert.

Beachten Sie, dass das Format des dateibasierten persistenten Datenspeichers auf Version 370 verbleibt, da daran keine Änderungen vorgenommen wurden.

Broker-Umgebungs-Konfiguration

Die Eigenschaft IMQ_DEFAULT_EXT_JARS wurde in die Umgebungskonfigurationsdatei von Message Queue 4.1, imqenv.conf, aufgenommen. Sie können diese Eigenschaft festlegen, um die Pfadnamen externer .jar-Dateien anzugeben, die beim Start des Brokers in CLASSPATH aufgenommen werden sollen. Wenn Sie diese Eigenschaft verwenden, um den Speicherort von externen .jar-Dateien anzugeben, müssen Sie diese Dateien nicht mehr in das Verzeichnis lib/ext kopieren. Externe .jar-Dateien können sich auf JDBC-Treiber oder JAAS-Anmeldemodule beziehen. Die folgende Beispieleigenschaft gibt den Speicherort von JDBC-Treibern an.

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Unterstützung für Java ES Monitoring Framework

In Message Queue 4.1 wurde Unterstützung für das Sun Java Enterprise System (Java ES) Monitoring Framework aufgenommen, mit dem Java ES-Komponenten mithilfe einer üblichen grafischen Oberfläche überwacht werden können. Diese Oberfläche wird durch die webbasierte Sun Java System Monitoring Console implementiert. Administratoren können mit der Konsole Leistungsstatistiken anzeigen, Regeln für die automatische Überwachung erstellen und Alarme bestätigen. Wenn Sie Message Queue gemeinsam mit anderen Java ES-Komponenten ausführen, ist es möglicherweise praktischer, eine einzige Oberfläche zur Verwaltung all dieser Komponenten zu verwenden.

Informationen zur Verwendung des Java ES Monitoring Framework zur Überwachung von Message Queue finden Sie unter XREF.

Erweiterte Transaktionsverwaltung

Zuvor konnte ein Administrator nur für Transaktionen mit dem Status PREPARED ein Rollback ausführen. Das heißt, dass beim nicht ordnungsgemäßen Beenden einer Sitzung, die Teil einer verteilten Transaktion war, für die Transaktion ein Status beibehalten wurde, der nicht durch einen Administrator bereinigt werden konnte. In Message Queue 4.1 können Sie mit dem Befehlsdienstprogramm (imqcmd) Transaktionen bereinigen (durch ein Rollback zurücksetzen), die folgende Statuswerte aufweisen: STARTED, FAILED, INCOMPLETE, COMPLETE und PREPARED.

Um zu ermitteln, ob für eine bestimmte Transaktion ein Rollback durchgeführt werden kann (insbesondere, wenn diese nicht den Status PREPARED aufweist), bietet das Befehlsdienstprogramm zusätzliche Daten als Teil der imqcmd query txn-Ausgabe: Es gibt die ID der Verbindung an, mit der die Transaktion gestartet wurde, sowie den Zeitpunkt, an dem die Transaktion erstellt wurde. Mithilfe dieser Informationen kann ein Administrator ermitteln, ob für die Transaktion ein Rollback durchgeführt werden muss. Im Allgemeinen sollte der Administrator ein zu frühes Rollback für eine Transaktion vermeiden.

Feste Ports für C-Clientverbindungen

In Message Queue 4.1 können C-Clients nun ebenso wie Java-Clients eine Verbindung mit einem festen Broker-Anschluss herstellen und müssen nicht mehr eine Verbindung zu einem Anschluss herstellen, der dynamisch vom Portmapper-Dienst des Brokers zugewiesen wurde. Feste Anschlussverbindungen sind nützlich, wenn Sie versuchen, eine Firewall zu überwinden, oder wenn Sie den Portmapper-Dienst aus einem anderen Grund umgehen müssen.

Zur Konfiguration einer festen Anschlussverbindung müssen Sie sowohl den Broker als auch die Laufzeit des C-Client (beide Enden der Verbindung) konfigurieren. Wenn Sie Ihren Client z. B. über ssljms mit Anschluss1756 verbinden möchten, führen Sie die folgenden Schritte aus.

• Legen Sie auf der Client-Seite folgende Eigenschaften fest:

  MQ_SERVICE_PORT_PROPERTY=1756

  MQ_CONNECTION_TYPE_PROPERTY=SSL

• Legen Sie auf der Broker-Seite die Eigenschaft imq.serviceName.protocolType .port wie folgt fest:

  imq.ssljms.tls.port=1756

Die Verbindungseigenschaft MQ_SERVICE_PORT_PROPERTY wurde durch Backporting auf Message Queue 3.7 Update 2 übertragen.