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.