Versionshinweise zu Sun GlassFish Message Queue 4.4

Neue Funktionen in Message Queue 4.4 und aktuellen Versionen

Die neuen Funktionen in Message Queue 4.4 und vorhergehende Versionen in der Message Queue 4.x-Familie sind in folgenden Abschnitten beschrieben:

Neue Funktionen in Message Queue 4.4

Message Queue 4.4 ist eine Unterversion, die eine Anzahl von Funktionserweiterungen und Fehlerkorrekturen enthält. Dieser Abschnitt enthält eine Beschreibung neuer Funktionen in dieser Version:

JMS-Brückendienst

Da JMS kein Wire-Protokoll zur Kommunikation zwischen Brokern und Clients festlegt, verwendet jeder JMS-Provider (einschließlich Message Queue) ein eigenes, proprietäres Protokoll. Dies verhindert die Interoperabilität zwischen JMS-Providern.

Der JMS-Brückendienst in Message Queue 4.4 schließt diese Lücke, indem er einem Message Queue-Broker ermöglicht, seine Ziele den Zielen externer JMS-Provider zuzuordnen. Dadurch kann der Message Queue-Broker mit Clients des externen JMS-Providers kommunizieren.

Der JMS-Brückendienst unterstützt die Zuordnung von Zielen in externen JMS-Providern, die folgende Voraussetzungen erfüllen:

Viele Open Source- und kommerzielle JMS-Provider erfüllen diese Voraussetzungen. Dadurch wird der JMS-Brückendienst zu einer wirkungsvollen Möglichkeit zur Integration von Message Queue in eine vorhandene Messaging-Umgebung, in der andere JMS-Provider verwendet werden.

Weitere Informationen zum JMS-Brückendienst finden Sie unter:

STOMP-Brückendienst

Wie bereits erwähnt legt JMS kein Wire-Protokoll zur Kommunikation zwischen Brokern und Clients fest. Das Open Source-Projekt STOMP (Streaming Text Oriented Messaging Protocol) unter http://stomp.codehaus.org definiert ein einfaches Wire-Protokoll, das in beliebiger Sprache geschriebene Clients zur Kommunikation mit beliebigen Messaging-Providern, die das STOMP-Protokoll unterstützten, nutzen können.

Message Queue 4.4 bietet diese Unterstützung mithilfe des STOMP-Brückendiensts. Der Dienst ermöglicht einem Message Queue-Broker die Kommunikation mit STOMP-Clients.

Weitere Informationen über den STOMP-Brückendienst finden Sie in folgenden Dokumenten:

Zusätzliche Erweiterungen

Message Queue 4.4 bietet außerdem die folgenden zusätzlichen Erweiterungen:

Neue Universal Message Service-Funktionen (UMS)

Der UMS bietet jetzt Funktionen, die auf HTTP GET basieren:

Eine Übersicht über UMS erhalten Sie in Universal Message Service (UMS). Die Dokumentation zur UMS-API finden Sie unter https://mq.dev.java.net/4.3-content/ums/protocol.html. Programmierbeispiele in mehreren Sprachen finden Sie unter https://mq.dev.java.net/4.3-content/ums/examples/README.html.

Unterstützung für IPS-Pakete

Message Queue wird nun mit dem quelloffenen Image Packaging System (IPS), das auch als pkg(5)-System bezeichnet wird, verpackt und zur Verteilung bereitgestellt. Diese Verpackungsmethode ermöglicht die Integration von Message Queue in Sun GlassFish Enterprise Server 2.1.1.

Neue Funktionen in Message Queue 4.3

Message Queue 4.3 war eine Unterversion, die eine Reihe von Funktionserweiterungen und Fehlerkorrekturen enthielt. Dieser Abschnitt enthält eine Beschreibung neuer Funktionen in dieser Version:

Universal Message Service (UMS)

Mit Message Queue 4.3 wird ein neuer Universal Messaging Service (UMS) und eine Messaging-API eingeführt, die den Zugriff auf Message Queue über ein beliebiges HTTP-fähiges Gerät ermöglicht. Auf diese Art können fast alle Anwendungen miteinander kommunizieren und von der Zuverlässigkeit und garantierten Zustellung durch JMS-Messaging profitieren. Außerdem bietet UMS eine erweiterte Skalierbarkeit für JMS-Messaging, wodurch die Anzahl der Messaging-Clients internetähnliche Ausmaße erreichen kann.

Architektur

Die grundlegende UMS-Architektur wird in der folgenden Abbildung gezeigt:

Abbildung 1–1 UMS-Architektur

Abbildung, die den UMS als Schnittstelle zwischen Clients ohne JMS und einem JMS-Provider zeigt.

Der UMS, der auf einem Webserver ausgeführt wird, ist sprachneutral und plattformunabhängig. Der UMS dient als Schnittstelle zwischen einer Client-Anwendung ohne JMS und einem JMS-Provider. Er empfängt Meldungen, die mithilfe der UMS-API versendet werden, wandelt sie in JMS-Meldungen um und erzeugt sie am Ziel im JMS-Provider mithilfe des nativen Protokolls des Providers. Ebenso empfängt er Nachrichten von den Zielen im JMS-Provider, wandelt sie in Text oder SOAP-Nachrichten um und sendet sie entsprechend den über die UMS-API angegebenen Anforderungen an Clients ohne JMS.

Die einfache, sprachunabhängige, protokollbasierte UMS-API unterstützt sowohl webbasierte als auch nicht webbasierte Anwendungen und kann mit Skript- und Programmiersprachen verwendet werden. Die API wird in zwei Stilen angeboten: als einfache Messaging-API, die ein Protokoll des Typs Representational State Transfer (REST) verwendet, und als XML-Messaging-API, die das Protokoll in einen SOAP-Nachrichten-Header einbettet. In beiden Fällen erfordert jedoch die API nur eine einfache HTTP-Anforderung zum Senden oder Empfangen einer Nachricht.

Die Einfachheit und Flexibilität der UMS-API bedeutet, dass AJAX, .NET, Python, C, Java und viele andere Anwendungen Textnachrichten und/oder SOAP-Nachrichten (mit Anhang) an JMS-Ziele senden oder von JMS-Zielen empfangen können. Beispielsweise können Python-Anwendungen mit .NET-Anwendungen, das iPhone mit Java-Anwendungen usw. kommunizieren.

Für Message Queue 4.3 unterstützt der UMS nur Message Queue als JMS-Provider.

Weitere Funktionen

Der UMS kann nicht nur wie oben beschrieben als einfache Schnittstelle verwendet werden. Er unterstützt Client-Sitzungen mit und ohne Status. Der UMS behält den Sitzungsstatus für die Client-Anwendung über mehrere Dienstanforderungen hinweg bei, wenn dies vom Client gefordert wird. Der UMS kann eine Container-verwaltete Authentifizierung nutzen und/oder zur Authentifizierung von Clients mithilfe des Message Queue-Brokers konfiguriert werden. Der UMS unterstützt außerdem Transaktionen und ermöglicht Client-Anwendungen das Übernehmen und Zurücksetzen von mehreren Dienstanforderungen als einzelne atomare Einheit.

Da der UMS eine große Anzahl von Clients über eine einzelne Verbindung mit dem Message Queue-Broker unterstützen kann, entlastet er die Verbindungsdienste des Brokers und ermöglicht maximale Skalierbarkeit. Außerdem kann die UMS-Kapazität durch horizontale Skalierung erhöht werden und ermöglicht so ein internetähnliches Messaging-Aufkommen.

Aufgrund der Einfachheit der protokollbasierten UMS-API sind auf der Client-Seite keine Client-Bibliotheken erforderlich. Dadurch kann die API zukünftig für zusätzliche JMS-Funktionen ohne Upgrade der Client-Anwendungen erweitert werden.

Verwenden von UMS

Um den UMS zu verwenden, stellen Sie ihn in einem Webcontainer bereit, der Servlet 2.4 oder höhere Spezifikationen unterstützt. Starten Sie den Message Queue-Broker, erstellen Sie die gewünschten Ziele und schreiben Sie eine Messaging-Anwendung, die die UMS-API zum Senden oder Empfangen von Nachrichten verwendet.

Die im Rahmen von Message Queue 4.3 bereitgestellte UMS-Datei imqums.war wird, abhängig von der Plattform, an einem der folgenden Speicherorte installiert:

Sie können die .war-Datei bei Bedarf umbenennen.

Tabelle 1–5 Speicherort der Datei imqums.war

Plattform 

Speicherort von imqums.war

Solaris 

/usr/share/lib/imq

Linux 

/opt/sun/mq/share/lib

AIX 

IMQ_HOME/lib

Windows 

IMQ_HOME\lib

Nachdem Sie die Datei imqums.war in einem Webcontainer unter localhost:port bereitgestellt haben, finden Sie die UMS-Dokumentation unter:

http://localhost:port/imqums

Andernfalls steht Ihnen folgende UMS-Dokumentation zur Verfügung:

Unterstützte Webcontainer

UMS wird gegenwärtig auf folgenden Webcontainern unterstützt:

Unterstützung der AIX-Plattform

Message Queue 4.3 bietet Pakete für die AIX-Plattform und ein entsprechendes Installationsprogramm.

Die AIX-Implementierung von Message Queue unterstützt folgende Software:

Installationsanweisungen finden Sie in Kapitel 4, AIX Installation in Sun GlassFish Message Queue 4.4 Installation Guide.

Auf der AIX-Plattform werden Message Queue-Dateien in einem einzigen Message Queue-Ausgangsverzeichnis, IMQ_HOME, installiert. IMQ_HOME gibt das Verzeichnis mqInstallHome/mq an, wobei mqInstallHome dem Ausgangsverzeichnis der Installation entspricht, das Sie bei der Installation des Produkts angeben (standardmäßig home-directory /MessageQueue).

Daraus ergibt sich die gleiche Message Queue-Verzeichnisstruktur wie bei der Windows-Plattform (siehe Abschnitt zu Windows in Anhang A, Platform-Specific Locations of Message Queue Data in Sun GlassFish Message Queue 4.4 Administration Guide).

Die Message Queue-Unterstützung für die AIX-Plattform schließt die Unterstützung der Message Queue C-API ein. Anweisungen zum Erstellen und Kompilieren von C-Anwendungen auf der AIX-Plattform finden Sie unter XREF.

Neues Zip-basiertes Installationsprogramm

Mit Message Queue 4.3 wird ein neues Installationsprogramm eingeführt, das eine Zip-basierte Verteilung im Gegensatz zur Verteilung in Form von nativen Paketen ermöglicht. Das Programm installiert die .zip-Pakete für Message Queue auf der AIX-Plattform.

Das neue Installationsprogramm extrahiert die .zip-Dateien für Message Queue in alle Verzeichnisse, auf die Sie Schreibzugriff besitzen. (Sie benötigen keine root-Berechtigung.) Es ermöglicht außerdem das Registrieren Ihrer Message Queue-Installation bei Sun Connection.

Um die Größe der Download-Bundles zu reduzieren, ist die Java Runtime nicht mehr in der zip-basierten Verteilung enthalten (auf den meisten Sites ist sie bereits vorhanden). Deshalb muss für den Befehl installer ein JDK oder eine JRE angegeben werden, entweder über die Umgebungsvariable JAVA_HOME oder über die Befehlszeile mithilfe der Option -j. Beispiel:

$ installer -j JDK/JRE-Pfad

Dabei entspricht JDK/JRE-Pfad dem Pfad des JDK oder der JRE.

Erweiterte Plattformunterstützung

Die folgende aktualisierte Plattformunterstützung wird für Message Queue 4.3 zertifiziert:

Zusätzliche Erweiterungen

Message Queue 4.3 bietet außerdem die folgenden zusätzlichen Erweiterungen:

Neue Verzeichnisstruktur für Windows-Plattform

Die installierte Verzeichnisstruktur für Message Queue auf der Windows-Plattform wurde im Vergleich zu früheren Versionen geändert und an diejenige der AIX-Plattform angepasst. Diese Verzeichnisstruktur wird zukünftig auch für die Solaris- und Linux-Plattformen verwendet. Dies ermöglicht mehrere Installationen auf einem einzelnen Computer und die automatische Aktualisierung von Message Queue über Sun Connection, einem von Sun gehosteten Dienst, mit dem Sie Sun-Hardware und -Software aufzeichnen, organisieren und warten können (siehe Unterstützung des Installationsprogramms für Sun Connection-Registrierung).

Neue Broker-Eigenschaften

Die nachfolgend beschriebenen neuen Eigenschaften sind bei der Konfiguration eines Brokers verfügbar:

Tabelle 1–6 Broker-Weiterleitungs- und Zustellungseigenschaften

Eigenschaft 

Typ 

Standardwert 

Beschreibung 

imq.transaction.producer.maxNumMsgs

Integer 

1000

Die maximale Anzahl von Nachrichten, die der Produzent in einer einzelnen Transaktion verarbeiten kann. Es wird empfohlen, einen Wert unter 5000 festzulegen, um eine Überlastung der Ressourcen zu verhindern. 

imq.transaction.consumer.maxNumMsgs

Integer 

100

Die maximale Anzahl von Nachrichten, die der Konsument in einer einzelnen Transaktion verarbeiten kann. Es wird empfohlen, einen Wert unter 1000 festzulegen, um eine Überlastung der Ressourcen zu verhindern. 

imq.persist.jdbc.connection.limit

Integer 

5

Die maximale Anzahl von Verbindungen zur Datenbank, die geöffnet werden können. 

Verbesserungen der JMX Administration-API

Der JMX-API wurden ein neues Attribut und neue Schlüssel für zusammengesetzte Datumsangaben hinzugefügt:

Weitere Informationen finden Sie in Kapitel 3, Message Queue MBean Reference in Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.

Auflisten dauerhafter Abonnements für Platzhalter-Abonnenten

Der Befehl zum Auflisten dauerhafter Abonnements:

list dur [-d Themenname]

wurde erweitert, sodass die Angabe des Themennamens optional ist. Wenn kein Thema angegeben wird, listet der Befehl die dauerhaften Abonnements für alle Themen auf (auch diejenigen, für die Platzhalter-Namenskonventionen verwendet wurden).

Neue Funktionen in Message Queue 4.2

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

Informationen zu den neuen Funktionen in den Versionen Message Queue 4.1 und 4.0 finden Sie in Neue Funktionen in Message Queue 4.1 bzw. Neue Funktionen in Message Queue 4.0.

Mehrere Ziele für einen Herausgeber bzw. Abonnenten

Ab Message Queue 4.2 kann ein Herausgeber Nachrichten an mehrere Themenziele veröffentlichen und ein Abonnent kann Nachrichten von mehreren Themenzielen konsumieren. Diese Fähigkeit wird erreicht, indem ein Themenzielname mit Platzhalterzeichen verwendet wird, der für mehrere Ziele steht. Durch die Verwendung dieser symbolischen Namen können die Administratoren bei Bedarf zusätzliche Themenziele erstellen, die dem Benennungsschema mit Platzhaltern entsprechen. Die hinzugefügten Ziele werden automatisch bei Veröffentlichungen durch Herausgeber und beim Konsum durch Abonnenten berücksichtigt. (Bei Abonnenten sind Themen mit Platzhalterzeichen üblicher als bei Herausgebern.)


Hinweis –

Diese Funktion gilt nicht für Warteschlangenziele.


Eine Beschreibung des Formats der symbolischen Themenzielnamen und Verwendungsbeispiele erhalten Sie in Supported Topic Destination Names in Sun GlassFish Message Queue 4.4 Administration Guide.

Schemavalidierung von XML-Payload-Meldungen

Diese in Message Queue 4.2 eingeführte Funktion ermöglicht die Validierung des Inhalts einer Text-XML-Nachricht (keine Objektnachrichten) anhand eines XML-Schemas an der Stelle, an der die Nachricht an den Broker gesendet wird. Der Speicherort des XML-Schemas (XSD) wird als Eigenschaft eines Message Queue-Ziels angegeben. Wenn kein XSD-Speicherort angegeben wurde, wird die DTD-Deklaration innerhalb des XML-Dokuments zur Durchführung der DTD-Validierung verwendet. (XSD-Validierung, die Datentyp und Wertebereichsvalidierung beinhaltet, ist strenger als DTD-Validierung.)

Informationen zur Verwendung dieser Funktion finden Sie in Schemavalidierung von XML-Payload-Meldungen.

C-API-Unterstützung für verteilte Transaktionen

Gemäß dem verteilten Transaktionsmodell von X/Open beruht die Unterstützung für Transaktionen auf einem Manager für verteilte Transaktionen, der die von einer oder mehreren Ressourcenmanagern durchgeführten Vorgänge aufzeichnet und verwaltet. In Message Queue 4.2 unterstützt die Message Queue C-API die XA-Schnittstelle (zwischen einem Manager für verteilte Transaktionen und Message Queue als XA-konformen Ressourcenmanager). Dies ermöglicht Message Queue C-API-Clients, die in einer Umgebung ausgeführt werden, in der verteilte Transaktionen verarbeitet werden (wie beispielsweise BEA Tuxedo), sich an verteilten Transaktionen zu beteiligen.

Diese Unterstützung für verteilte Transaktionen besteht aus folgenden neuen C-AP-Funktionen (und neuen Parametern und Fehlercodes), die zur Implementierung der XA-Schnittstellenspezifikation verwendet werden:

MQGetXAConnection()
MQCreateXASession()

Wenn eine C-Client-Anwendung im Kontext einer verteilten Transaktion verwendet werden soll, muss sie mithilfe von MQGetXAConnection() eine Verbindung herstellen und mithilfe von MQCreateXASession() eine Sitzung für Produktion und Konsum von Nachrichten erstellen. Starten, Übernehmen und Zurücksetzen von verteilten Transaktionen wird durch APIs verwaltet, die vom Manager für verteilte Transaktionen bereitgestellt werden.

Einzelheiten zur Verwendung der verteilten Transaktionsfunktionen finden Sie in Working With Distributed Transactions in Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.

Message Queue 4.2 bietet Programmierungsbeispiele, die auf dem Tuxedo-Transaktionsmanager beruhen. Informationen zur Verwendung dieser Beispielprogramme finden Sie in Distributed Transaction Sample Programs in Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.


Hinweis –

Die verteilte Transaktionsfunktionalität wird auf Solaris, Linux und Windows-Plattformen unterstützt. Bislang ist sie jedoch nur für die Solaris-Plattform zertifiziert.


Unterstützung des Installationsprogramms für Sun Connection-Registrierung

Das Message Queue-Installationsprogramm wurde erweitert und ermöglicht die Registrierung von Message Queue bei Sun Connection, einem von Sun gehosteten Dienst, mit dem Sie Sun-Hardware und -Software aufzeichnen, organisieren und warten können.

Im Rahmen der Message Queue-Installation können Sie Message Queue bei Sun Connection registrieren lassen. Informationen zur installierten Message Queue, wie beispielsweise Release-Version, Hostname Betriebssystem, Installationsdatum und ähnliche grundlegende Informationen werden sicher an die Sun Connection-Datenbank übertragen. Dere Sun Connection-Inventardienst kann Sie bei der Organisation Ihrer Hard- und Software von Sun unterstützen, während der Aktualisierungsdienst Sie über die aktuellsten Sicherheitsfixes, empfohlene Updates und Funktionserweiterungen informieren kann.

Einzelheiten zum Registrieren von Message Queue bei Sun Connection finden Sie im Sun GlassFish Message Queue 4.4 Installation Guide.

Unterstützung für MySQL-Datenbank

Ab Message Queue 4.2 werden MySQL-Datenbanken als JDBC-basierte Datenspeicher unterstützt. MySQL Cluster Edition kann als JDBC-Datenbank für einen eigenständigen Broker verwendet werden, und MySQL Cluster Edition kann als hochverfügbarer gemeinsam genutzter Datenspeicher verwendet werden, der für ein erweitertes Broker-Cluster benötigt wird. Informationen zur Konfiguration von Message Queue zur Verwendung von MySQL finden Sie in Configuring a JDBC-Based Data Store in Sun GlassFish Message Queue 4.4 Administration Guide und in Enhanced Broker Cluster Properties in Sun GlassFish Message Queue 4.4 Administration Guide.

Zusätzliche Erweiterungen

Zusätzlich zu den oben beschriebenen Funktionen schließt Message Queue 4.2 folgende Erweiterungen ein:

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:

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:

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.


Hinweis –

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


Neue Funktionen in Message Queue 4.0

Message Queue 4.0 war eine Unterversion, die auf die Unterstützung von Application Server 9 PE beschränkt war. Sie beinhaltete einige neue Funktionen sowie einige Funktionserweiterungen und Fehlerbehebungen. Dieser Abschnitt enthält eine Beschreibung neuer Funktionen in dieser Version:


Achtung – Achtung –

Eine der kleinen, jedoch wichtigen Änderungen, die mit Version 4.0 eingeführt wurden, ist die Tatsache, dass die Befehlszeilenoption nun nicht mehr zur Angabe eines Passworts verwendet werden kann. Ab dieser Version müssen Sie alle Passwörter in einer Datei speichern, wie in Veraltete Passwortoption beschrieben, oder Sie bei Aufforderung eingeben.


Unterstützung für die JMX Administration-API

Für die Konfiguration und Überwachung von Message Queue-Brokern wurde in Übereinstimmung mit der JMX-Spezifikation (Java Management Extensions) eine neue API hinzugefügt. Mithilfe dieser API haben Sie die Möglichkeit, Broker-Funktionen programmatisch in einer Java-Client-Anwendung zu konfigurieren und zu überwachen. In früheren Versionen von Message Queue war der Zugriff auf diese Funktionen ausschließlich über die Administrationsdienstprogramme der Befehlszeile oder die Administrationskonsole möglich.

Weitere Informationen finden Sie im Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.

Protokollierung zur Client-Laufzeit

In Message Queue 4.0 wurde Unterstützung für Client-Laufzeitprotokollierung von verbindungs- und sitzungsbezogenen Ereignissen eingeführt.

Weitere Informationen zur Client-Laufzeitprotokollierung und ihrer Konfiguration finden Sie im Java Dev Guide auf Seite 137.

Verbindungsereignisbenachrichtigungs-API

In Message Queue 4.0 wurde eine Ereignisbenachrichtigungs-API eingeführt, mit der die Client-Laufzeit eine Anwendung über Änderungen im Verbindungsstatus informieren kann. Verbindungsereignisbenachrichtigungen ermöglichen es einem Message Queue-Client, das Schließen und erneute Verbinden von Ereignissen zu überwachen und dem Benachrichtigungstyp und Verbindungsstatus entsprechende Aktionen auszuführen. Wenn es beispielsweise zu einem Failover kommt und der Client mit einem anderen Broker erneut verbunden wird, wird in einer Anwendung möglicherweise der Transaktionsstatus bereinigt, um mit einer neuen Transaktion fortzufahren.

Informationen zu Verbindungsereignissen und zum Erstellen einer Ereignisüberwachungsfunktion finden Sie im Java Dev Guide auf Seite 96.

Erweiterungen der Broker-Administration

In Message Queue 4.0 wurden ein neuer Unterbefehl und mehrere Befehlsoptionen zum Befehlsdienstprogrammm (imqcmd) hinzugefügt, um es Administratoren zu ermöglichen, einen Broker stillzulegen (zu inaktivieren), einen Broker nach einem angegebenen Zeitraum herunterzufahren, eine Verbindung zu vernichten oder Java-Systemeigenschaften (z. B. Verbindungsbezogene Eigenschaften) festzulegen.

Vollständige Informationen über die Syntax des Befehls imqcmd finden Sie in Kapitel 16, Command Line Reference in Sun GlassFish Message Queue 4.4 Administration Guide.

Anzeigen von Informationen zu einem JDBC-basierten Datenspeicher

In Message Queue 4.0 wurde ein neuer Unterbefehl query zum Datenbank-Manager-Dienstprogramm, imqdbmgr, hinzugefügt. Dieser Unterbefehl wird zum Anzeigen von Informationen zu einem JDBC-basierten Datenspeicher (u. a. Datenbankversion, Datenbankbenutzer und ob die Datenbanktabellen erstellt wurden) verwendet.

Im Folgenden finden Sie ein Beispiel für die Informationen, die über diesen Befehl angezeigt werden.


imqdbmgr query

[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store:
        version=400
        brokerid=Mozart1756
        database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb
        database user=scott
Running in standalone mode.
Database tables have already been created.

JDBC-Anbieter-Unterstüztung

In Message Queue 4.0 wird nun Apache Derby Version 10.1.1 als JDBC-basierter Datenspeicheranbieter unterstützt.

Formatänderungen für persistenten Datenspeicher

Message Queue 4.0 führte Änderungen am JDBC-basierten Datenspeicher zur Optimierung und zur Unterstützung zukünftiger Erweiterungen ein. Aus diesem Grund wurde das Format des JDBC-basierten Datenspeichers auf Version 400 erhöht. Beachten Sie, dass die Version des dateibasierten Datenspeichers Version 370 bleibt, da daran keine Änderungen vorgenommen wurden.

Zusätzliche Nachrichteneigenschaften

Message Queue 4.0 fügte zwei neue Eigenschaften hinzu, die für alle Nachrichten festgelegt werden, die in die Warteschlange für nicht zugestellte Nachrichten eingestellt werden.

SSL-Unterstützung

Ab Message Queue 4.0 ist der Standardwert für die Werkseinstellung der Clientverbindung imqSSLIsHostTrusted auf false gesetzt. Wenn die Anwendung jedoch von dem vorherigen Standardwert true abhängt, müssen Sie die Eigenschaft neu konfigurieren und ausdrücklich auf true setzen.

Möglicherweise vertrauen Sie dem Host, wenn der Broker so konfiguriert ist, dass er selbst signierte Zertifikate verwendet. In diesem Fall sollten Sie zusätzlich zur Angabe, dass die Verbindung einen SSL-basierten Verbindungsdienst verwenden soll (über die imqConnectionType-Eigenschaft), die Eigenschaft imqSSLIsHostTrusted auf "true" setzen.

Um Clientanwendungen sicher auszuführen, wenn der Broker selbst signierte Zertifikate verwendet, verwenden Sie beispielsweise einen ähnlichen Befehl wie den folgenden.

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true ClientAppName

Um das Befehlsdienstprogramm (imqcmd) sicher zu verwenden, wenn der Broker selbstignierte Zertifikate verwendet, müssen Sie einen Befehl wie den folgenden (zur Auflistung der Konnectorservices) verwenden.

imqcmd list svc -secure -DimqSSLIsHostTrusted=true