Die neuen Funktionen in Message Queue 4.4 und vorhergehende Versionen in der Message Queue 4.x-Familie sind in folgenden Abschnitten beschrieben:
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:
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:
Sie sind mit JMS 1.1 kompatibel.
Sie unterstützen JNDI-Administrationsobjekte.
Sie verwenden Verbindungen des Typs javax.jms.ConnectionFactory oder javax.jms.XAConnectionFactory.
Für transaktionale Zuordnungen unterstützen sie XA-Schnittstellen als Ressourcenmanager.
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:
Informationen zu Architektur, Unterkomponenten und Funktionen des JMS-Brückendiensts finden Sie unter JMS Bridge Service in Sun GlassFish Message Queue 4.4 Technical Overview.
Informationen über die Konfiguration und Verwaltung von JMS-Brücken in einem Broker finden Sie in Configuring and Managing JMS Bridge Services in Sun GlassFish Message Queue 4.4 Administration Guide.
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:
Informationen zur Architektur und den Funktionen des STOMP-Brückendiensts finden Sie unter STOMP Bridge Service in Sun GlassFish Message Queue 4.4 Technical Overview.
Informationen zur Konfiguration und Verwaltung einer STOMP-Brücke in einem Broker finden Sie in Configuring and Managing STOMP Bridge Services in Sun GlassFish Message Queue 4.4 Administration Guide.
Message Queue 4.4 bietet außerdem die folgenden zusätzlichen Erweiterungen:
Der UMS bietet jetzt Funktionen, die auf HTTP GET basieren:
ssend: sendet eine einfache Textnachricht.
sreceive: empfängt eine einfache Textnachricht.
getBrokerInfo: ruft Informationen über den Broker ab.
getConfiguration: ruft Informationen über die UMS-Konfiguration ab.
debug: aktiviert und deaktiviert die Debug-Protokollierung.
ping: kommuniziert mit dem Broker, um zu bestätigen, dass dieser ausgeführt wird.
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.
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.
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:
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.
Die grundlegende UMS-Architektur wird in der folgenden Abbildung gezeigt:
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.
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.
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:
Informationen zur Konfiguration des UMS finden Sie unter https://mq.dev.java.net/4.3-content/ums/config.html.
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.
UMS wird gegenwärtig auf folgenden Webcontainern unterstützt:
Sun GlassFish Enterprise Server, Version 2.1 und Version 3 Prelude
Tomcat, Version 5.5 und 6.0
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:
AIX v 6.1 oder höher (frühere Versionen von AIX werden über das Unix/Java Only-Bundle unterstützt)
DB2-Unterstützung
IBM XL C/C++ Compiler V9.0
JDK 1.5 oder höher
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.
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.
Die folgende aktualisierte Plattformunterstützung wird für Message Queue 4.3 zertifiziert:
Oracle 11g
Windows Server 2008
Message Queue 4.3 bietet außerdem die folgenden zusätzlichen Erweiterungen:
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).
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. |
Der JMX-API wurden ein neues Attribut und neue Schlüssel für zusammengesetzte Datumsangaben hinzugefügt:
Ein NextMessageID-Attribut wurde der Zielüberwachungs-MBean hinzugefügt, um die JMS-Nachrichten-ID für die nächste an einen Konsumenten zu liefernde Nachricht anzuzeigen.
Ein NextMessageID-Schlüssel für zusammengesetzte Datumsangaben wurde der Überwachungs-MBean für den Konsumentenmanager hinzugefügt, um die JMS-Nachrichten-ID der nächsten an den Konsumenten zu liefernden Nachricht anzuzeigen.
Ein NumMsgsPending-Schlüssel für zusammengesetzte Datumsangaben wurde der Überwachungs-MBean des Konsumentenmanagers hinzugefügt, um die Anzahl von Nachrichten anzuzeigen, die an den Konsumenten gesendet wurden.
Weitere Informationen finden Sie in Kapitel 3, Message Queue MBean Reference in Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.
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).
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.
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.)
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.
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.
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.
Die verteilte Transaktionsfunktionalität wird auf Solaris, Linux und Windows-Plattformen unterstützt. Bislang ist sie jedoch nur für die Solaris-Plattform zertifiziert.
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.
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ätzlich zu den oben beschriebenen Funktionen schließt Message Queue 4.2 folgende Erweiterungen ein:
Metriken für remote produzierte Nachrichten
Message Queue 4.2 beinhaltet eine neue Zielmetrik, die bei der Überwachung von Zielen in einem Broker-Cluster nützlich sein kann. In einem Broker-Cluster setzen sich die Nachrichten, die in einem bestimmten Ziel auf einem bestimmten Broker im Cluster gespeichert sind, aus Nachrichten zusammen, die direkt für dieses Ziel produziert wurden, und aus Nachrichten, die von Remote-Brokern im Cluster am das Ziel gesendet wurden. Bei der Analyse der Nachrichtenweiterleitung und -zustellung in einem Broker-Cluster ist es zuweilen hilfreich zu wissen, wie viele Nachrichten in einem Ziel lokal (lokal produziert) und wie viele remote (remote produziert) sind.
Message Queue 4.2 verfügt über zwei neue Größen für physische Ziele: Num messages remote (Anzahl der Remote-Nachrichten) und Total Message bytes remote (Bytezahl Remote-Nachrichten insgesamt). Die neuen metrischen Größen sind über die Befehle imqcmd list dst und imqcmd query dst (siehe Viewing Physical Destination Information in Sun GlassFish Message Queue 4.4 Administration Guide) sowie über neue JMX-Attribute (siehe Destination Monitor in Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients) verfügbar.
Informationen zu Platzhalter-Produzenten und Platzhalter-Konsumenten
Informationen zur Unterstützung der Verwendung von Platzhalterzeichen in Zielnamen (siehe Mehrere Ziele für einen Herausgeber bzw. Abonnenten) werden über neue Überwachungsdaten bereitgestellt. Beispielsweise kann die Anzahl der mit einem Ziel verbundenen Platzhalter-Produzenten oder -Konsumenten über den Befehl imqcmd query dst abgefragt werden (siehe Viewing Physical Destination Information in Sun GlassFish Message Queue 4.4 Administration Guide) und ist auch über neue JMX-Attribute verfügbar (siehe Destination Monitor in Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients). Platzhalterinformationen stehen auch über die ConsumerManager Monitor- und ProducerManager Monitor-MBeans zur Verfügung.
Unterstützung für das DN-Benutzernamensformat für Client-Authentifizierung
Ab Message Queue 4.2 wird das DN-Benutzernamensformat bei der Client-Verbindungsauthentifizierung anhand eines LDAP-Benutzer-Repositorys unterstützt. Die Unterstützung beinhaltet folgende neue Broker-Eigenschaft (und Wert):
imq.user_repository.ldap.usrformat=dn
Mit dieser Eigenschaft kann der Broker einen Client-Benutzer anhand eines Eintrags in einem LDAP-Benutzer-Repository authentifizieren, indem aus dem DN-Benutzernamensformat der Wert des durch folgende Eigenschaft angegebenen Attributs extrahiert wird:
imq.user_repository.ldap.uidattr
Der Broker verwendet den Wert des oben angegebenen Attributs als Namen des Benutzers bei Zugriffssteuerungsvorgängen.
Wenn beispielsweise gilt: imq.user_repository.ldap.uidattr=udi und wenn ein Benutzername für die Client-Authentifizierung im Format udi=mquser,ou=People,dc=red,dc=sun,dc=com vorliegt, dann wird "mquser" zur Durchführung der Zugriffssteuerung extrahiert.
Erweiterung der JAAS-Authentifizierung
Ab Message Queue 4.2 unterstützt die JAAS-Authentifizierung die Authentifizierung durch IP-Adressen sowie durch Benutzernamen.
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.
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:
Installieren einer hochverfügbaren Datenbank
Installieren der .jar-Datei des JDBC-Treibers
Erstellen des Datenbankschemas für den hochverfügbaren persistenten Datenspeicher
Festlegen der Hochverfügbarkeitseigenschaften für jeden Broker im Cluster
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.
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.
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.
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
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.
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.
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.
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:
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.
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.
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.
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.
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.
Bei der Stilllegung (Inaktivierung) des Brokers wird dieser in einen inaktiven Zustand versetzt, in dem Nachrichten entfernt werden können, bevor der Broker heruntergefahren oder neu gestartet wird. Zu einem Broker, der inaktiviert wird, können keine neuen Verbindungen erstellt werden. Um den Broker zu inaktivieren, geben Sie einen Befehl ähnlich dem folgenden ein.
imqcmd quiesce bkr -b Wolfgang:1756
Um den Broker nach einem bestimmten Intervall herunterzufahren, geben Sie einen Befehl ähnlich dem folgenden ein. (Das Zeitintervall gibt die Anzahl an Sekunden bis zum Herunterfahren des Brokers an.)
imqcmd shutdown bkr -b Hastings:1066 -time 90
Wenn Sie ein Zeitintervall angeben, protokolliert der Broker eine Meldung, die darauf hinweist, wann er heruntergefahren wird. Zum Beispiel:
Broker wird in 29 Sekunden (29996 Millisekunden) heruntergefahren.
Während der Broker auf das Herunterfahren wartet, wird sein Verhalten folgendermaßen beeinflusst.
Administrative JMS-Verbindungen werden weiterhin akzeptiert.
Neue JMS-Verbindungen werden nicht akzeptiert.
Bestehende JMS-Verbindungen werden weiterhin funktionieren.
Der Broker kann nicht die Funktionen für einen anderen Broker in einem erweiterten Broker-Cluster übernehmen.
Das Dienstprogramm imqcmd wird nicht gesperrt, es wird die Anforderung zum Herunterfahren des Brokers senden und umgehend zurückgeben.
Um eine Verbindung zu löschen, geben Sie einen Befehl ähnlich dem folgenden ein.
imqcmd destroy cxn -n 2691475382197166336
Verwenden Sie den Befehl imqcmd list cxn oder imqcmd query cxn, um die Verbindungs-ID abzurufen.
Zur Angabe einer Systemeigenschaft über den Befehl imqcmd verwenden Sie die neue –D-Option. Dies ist nützlich, um die Werkseinstellungen der JMS-Verbindung oder verbindungsbezogene Java-Systemeigenschaften außer Kraft zu setzen. Beispiel:
imqcmd list svc -secure -DimqSSLIsHostTrusted=true imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore -Djavax.net.ssl.trustStorePassword=mytrustword
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.
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. |
In Message Queue 4.0 wird nun Apache Derby Version 10.1.1 als JDBC-basierter Datenspeicheranbieter unterstützt.
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.
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.
JMS_SUN_DMQ_PRODUCING_BROKER zeigt dem Broker an, wo die Nachricht generiert wurde.
JMS_SUN_DMQ_DEAD_BROKER zeigt dem Broker an, wer die Nachricht als nicht zugestellt gekennzeichnet hat.
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