test

Versionshinweise zu Sun Java System Message Queue 4.2

Neue Funktionen in Message Queue 4.2 und aktuellen Versionen

Die neuen Funktionen in Message Queue 4.2, 4.2 und 4.0 sind in folgenden Abschnitten beschrieben:

Neue Funktionen in Message Queue 4.2

Sun Java System Message Queue ist ein leistungsfähiger Nachrichtendienst, der ein zuverlässiges, asynchrones Messaging gemäß JMS 1.1 (Java Messaging Specification) bietet. Zusätzlich stellt Message Queue Funktionen bereit, die über die JMS-Spezifikation hinausgehen, um den Anforderungen großer Bereitstellungen im Unternehmensbereich gerecht zu werden.

Message Queue 4.2 ist eine Unterversion, die eine Anzahl von Funktionserweiterungen und Fehlerkorrekturen enthält. In diesem Abschnitt wird die Installation von bzw. die Aufrüstung auf Message Queue 4.2 erläutert und die neuen Funktionen, die in dieser Version enthalten sind, werden beschrieben:

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

Mehrere Ziele für einen Herausgeber bzw. Abonnenten

In Message Queue 4.2 kann ein Herausgeber nun 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.

Das Format des symbolischen Themenzielnamens besteht aus mehreren Segmenten, bei denen Platzhalterzeichen (*, **, >) für ein oder mehrere Namenssegmente stehen können. Beispiel: Angenommen Sie verwenden folgendes Benennungsschema für Themenziele:

Größe verwendet wird.Farbe. Form

Dabei können die Themennamensegmente folgende Werte aufweisen:

Die Nachrichtenwarteschlange unterstützt folgende Platzhalterzeichen:

Sie können daher mehrere Themenziele wie folgt angeben:

large.*.circle steht für: 

large.red.circle
large.green.circle
...

**.square steht für alle Namen, die auf .square enden, z. B.: 


small.green.square
medium.blue.square
...

small.> steht für alle Zielnamen, die mit small. beginnen, z. B.:


small.blue.circle
small.red.square
...

Um diese Funktion für mehrere Ziele zu verwenden, erstellen Sie Themenziele mit einem ähnlichen Benennungsschema wie oben beschrieben. Die Client-Anwendungen können dann Herausgeber oder Konsumenten mithilfe von symbolischen Zielnamen erstellen. Beispiel:

...
String DEST_LOOKUP_NAME = "large.*.circle";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);
...
String DEST_LOOKUP_NAME = "**.square";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

Im ersten Beispiel legt der Broker eine Kopie der Nachricht an einem Ziel ab, das dem symbolischen Namen large.*.circle entspricht. Im zweiten Beispiel wird ein Abonnement erstellt, wenn es mindestens ein Ziel gibt, das mit dem symbolischen Namen **.square übereinstimmt, und der Abonnement erhält Nachrichten aus allen Zielen, die mit diesem symbolischen Namen übereinstimmen. Wenn es keine Ziele gibt, die mit dem symbolischen Namen übereinstimmen, wird der Abonnent erst erstell, wenn ein solches Ziel vorhanden ist.

Wenn ein Administrator zusätzliche Ziele erstellt, die mit einem symbolischen Namen übereinstimmen, veröffentlichen die Platzhalter-Herausgeber, die mit diesem symbolischen Namen erstellt wurden, anschließend unter diesem Ziel, und die Platzhalter-Abonnenten, die mit diesem symbolischen Namen erstellt wurden, empfangen anschließend Nachrichten von diesem Ziel.

Außerdem melden die Message Queue-Verwaltungswerkzeuge, neben der Gesamtzahl an Herausgebern (Produzenten) und Abonnenten (Konsumenten) für ein Themenziel auch die Anzahl der Herausgeber, bei denen es sich um Platzhalter-Herausgeber handelt (einschließlich der zugehörigen symbolischen Zielnamen) und die Anzahl der Abonnenten, bei denen es sich um Platzhalter-Abonnenten handelt (einschließlich der symbolischen Zielnamen), sofern vorhanden.

Schemavalidierung von XML-Payload-Meldungen

Diese neue Funktion in Message Queue 4.2 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.)

Client-Anwendungen, die diese neue Funktion verwenden, sollten die Java SE-Version auf JRE 1.5 oder höher aufrüsten.

Zur Aktivierung der XML-Schemavalidierung legen sie folgende Eigenschaften für das physische Ziel fest:

Tabelle 1–5 Eigenschaften des physischen Ziels für die XML-Schemavalidierung

Eigenschaft 

Typ 

Standardwert 

Beschreibung 

validateXMLSchemaEnabled

Boolesch 

false

Ist XML-Schemavalidierung aktiviert? 

Wenn dieser Wert auf false (falsch) gesetzt oder gar nicht festgelegt wurde, wird die XML-Schemavalidierung nicht für das Ziel aktiviert.

XMLSchemaURIList

String 

Null 

Leerzeichengetrennte Liste der URI-Zeichenfolgen für XML Schema Document (XSD)  

Die URIs verweisen auf den Speicherort einer oder mehrerer XSDs zur Verwendung mit der XML-Schemavalidierung, sofern aktiviert  

Verwenden Sie doppelte Leerzeichen um diesen Wert, wenn mehrere URIs angegeben werden. 

Beispiel: 

“http://foo/flap.xsd http://test.com/test.xsd”

Wenn diese Eigenschaft nicht festgelegt oder NULL ist und die XML_Validierung aktiviert wurde, wird die XML-Validierung mithilfe eines im XML-Dokument angegebenen DTD durchgeführt. 

reloadXMLSchemaOnFailure

Boolesch 

false

Erneutes Laden des XML-Schemas bei Versagen aktiviert? 

Wenn dieser Wert auf false (falsch) gesetzt oder gar nicht festgelegt wurde, wird das Schema nicht erneut geladen, wenn die Validierung fehlschlägt. 

Wenn die XML-Validierung aktiviert ist, versucht die Message Queue-Client-Laufzeit, eine XML-Nachricht anhand der angegebenen XSDs (oder anhand des DTD, wenn kein XSD angegeben wurde) zu validieren, bevor sie an den Broker gesendet wird. Wenn das angegebene Schema nicht gefunden oder die Nachricht nicht validiert werden kann, wird die Nachricht nicht gesendet, und eine Ausnahme wird ausgelöst.

Die XML-Validierungseigenschaften können mit dem Befehl imqcmd create dst bwz. imqcmd update dst zum Zeitpunkt der Zielerstellung bzw. -aktualisierung festgelegt werden. Die XML-Validierungseigenschaften sollten festgelegt werden, wenn ein Ziel inaktiv ist: wenn es also keine Konsumenten und Produzenten aufweist und wenn sich keine Nachrichten in dem Ziel befinden.

Hinweis –

Wenn ein XSD zur Laufzeit nicht zugänglich ist, kann es erforderlich sein, die XMLSchemaURIList zu bearbeiten, während ein Ziel aktiv ist.

Wenn eine der XML-Validierungseigenschaften festgelegt ist, während ein Ziel aktiv ist (beispielsweise, wenn ein Produzent mit dem Ziel verbunden ist), wird die Änderung erst wirksam, wenn der Produzent erneut eine Verbindung zum Broker herstellt. Ebenso gilt: Wenn infolge einer Änderung der Anwendungsanforderungen ein XSD geändert wird, müssen alle Client-Anwendungen, die auf der Grundlage des geänderten XSD XML-Nachrichten erstellen, erneut eine Verbindung zum Broker herstellen.

Wenn die Eigenschaft reloadXMLSchemaOnFailure auf true (wahr) gesetzt wird und die XML-Validierung fehlschlägt, versucht die Message Queue-Client-Laufzeit, das XSD erneut zu laden, bevor der erneute Versuch unternommen wird, eine Nachricht zu validieren. Die Client-Laufzeit löst eine Ausnahme aus, wenn die Validierung mithilfe der neu geladenen SXD fehlschlägt.

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 Message Queue C-API nun die XA-Schnittstelle (zwischen einem Manager für verteilte Transaktionen und Message Queue als XA-konformen Ressourcenmanager), was es Message Queue C-API-Clients, die in einer Umgebung ausgeführt werden, die verteilte Transaktionen verarbeitet (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.

Öffentliche Informationen

Für de X/Open-XA-Schnittstellenspezifikation sind folgende öffentlichen Informationen in Bezug auf den XA-konformen Message Queue-Ressourcenmanager erforderlich:

Folgende Name/Wert-Paare werden unterstützt:

Tabelle 1–6 Name/Wert-Paare des Message Queue-Ressourcenmanagers

Name 

Wert 

Beschreibung 

Standard 

Adresse 

host:port

Der Host:Anschluss des Portmapper-Diensts des Brokers. 

localhost:7676

username 

string 

Der Benutzername für die Herstellung einer Verbindung zum Broker 

guest

Passwort 

string 

Das zum Benutzernamen gehörende Passwort 

guest

conntype 

TCPor SSL 

Der Protokolltyp für die Verbindung mit dem Broker 

TCP

trustedhost 

true/false 

Ob der Broker-Host vertrauenswürdig ist (gilt nur bei conntype=SSL) 

true

certdbpath 

string 

Der vollständige Pfad zu dem Verzeichnis, das das NSS-Zertifikat und die Schlüsseldatenbankdateien enthält 

nicht festgelegt 

clientid 

string 

Nur für dauerhafte JMS-Abonnements erforderlich 

nicht festgelegt 

reconnects 

Integer 

Die Anzahl der erneuten Verbindungsversuche für den Broker (0 bedeutet: keine erneute Verbindung) 

0

Programmierungsbeispiele

Um eine Anwendung zu programmieren, die verteilte Transaktionen verwendet, erstellen Sie einen serverseitigen Dienst, der in der Umgebung des Transaktionsmanagers ausgeführt wird, und einen clientseitigen COde, der die Transaktionsmanager-APIs aufruft. Message Queue 4.2 bietet Programmierungsbeispiele, die auf dem Tuxedo-Transaktionsmanager beruhen. Diese Beispiele befinden sich im Beispielprogrammverzeichnis auf den einzelnen Plattformen im Verzeichnis ./C/tuxedo.

Dieses Verzeichnis beinhaltet eine README-Datei, die erläutert, wie Tuxedo zur Verwendung des Message Queue-Ressourcenmanagers eingerichtet wird und wie die folgenden Beispielprogramme in der Tuxedo-Umgebung erstellt werden können:

Beispielprogramm 

Beschreibung 

jmsserver.c

Implementiert Tuxedo-Dienste, die Nachrichten mithilfe von Message Queue senden und empfangen. 

jmsclient_sender.c

Tuxedo-Client, der den Nachrichtenproduktionsdienst im Programm jmsserver.c verwendet.

jmsclient_receiver.c

Tuxedo-Client, der den Nachrichtenempfangsdienst im Programm jmsserver.c verwendet.

async_jmsserver.c

Implementiert einen Tuxedu-Dienst, der asynchron Nachrichten mithilfe von Message Queue konsumiert. 

jmsclient_async_receiver.c

Tuxedo-Client, der den asynchronen Nachrichtenempfangsdienst im Programm jmsserver.c verwendet.

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

Das Message Queue-Installationsprogramm wurde erweitert und ermöglicht nun 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.

der folgende Bildschirm des Installationsprogramms wurde für die Sun Connection-Registrierung zu Message Queue 4.2 hinzugefügt:

Bildschirm für Sun Connection-Registrierung

Für die Registrierung müssen Sie ein Sun Online-Konto besitzen bzw. erstellen. Wenn Sie noch nicht über ein Konto verfügen, zeigt das Installationsprogramm folgenden Bildschirm zur Erstellung eines Sun Online-Kontos an:

Bildschirm zum Erstellen eines Sun Online-Kontos.

Sie können mithilfe der oben angegebenen Bildschirm Message Queue während der Installation erstellen oder bis zum Abschluss der Installation warten und das Installationsprogramm wie folgt im reinen Registrierungsmodus ausführen:

# installer -r

Für den reinen Registrierungsmodus muss Message Queue 4.2 bereits installiert sein und zeigt nur die Bildschirme des Installationsprogramms an, die sich auf die Registrierung beziehen.

Unterstützung für MySQL-Datenbank

Message Queue 4.2 unterstützt MySQL-Datenbank als JDBC-basierter Datenspeicher. 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 einen Hochverfügbarkeits-Broker-Cluster benötigt wird. Informationen zur Konfiguration von Message Queue für die Verwendung von MySQL finden Sie unter Configuring a JDBC-Based Data Store in Sun Java System Message Queue 4.2 Administration Guide sowie unter High-Availability Cluster Properties in Sun Java System Message Queue 4.2 Administration Guide.

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

In Message Queue 4.1 kamen Hochverfügbarkeits-Broker-Cluster neu hinzu. Im Vergleich zu konventionellen Broker Clustern, die nur Nachrichtendienst-Verfügbarkeit (wenn ein Broker ausfällt, ist ein anderer verfügbar, um den Nachrichtendienst bereitzustellen) bieten, bieten Hochverfügbarkeits-Broker-Cluster auch Daten-Verfügbarkeit (wenn ein Broker ausfällt, stehen seine persistenten Meldungen und Statusdaten einem anderen Broker zur Verfügung, der sie verwenden kann, um die Nachrichtenzustellung zu übernehmen.

Die seit Message Queue 4.1 verfügbare Hochverfügbarkeits-Implementierung verwendet einen freigegebenen 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 Nachrichtenweiterleitung und Zustellung 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 einen Message Queue 4.1-Hochverfügbarkeits-Broker-Cluster zu konfigurieren, geben Sie für jeden Broker im Cluster folgende Broker-Eigenschaften an:

Um die Implementierung mit Hochverfügbarkeits-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 im Zusammenhang mit Hochverfügbarkeits-Broker-Clustern und einen Vergleich mit konventionellen Clustern finden Sie in Kapitel 4, Broker Clusters in Sun Java System Message Queue 4.2 Technical Overview. Die Vorgehensweise und Referenzinformationen zu Hochverfügbarkeits-Broker-Clustern finden Sie in Kapitel 8, Managing Broker Clusters in Sun Java System Message Queue 4.2 Administration Guide und unter Cluster Configuration Properties in Sun Java System Message Queue 4.2 Administration Guide.

Wenn Sie eine hochverfügbare Datenbank zusammen mit Message Queue 4.0 verwendet haben und nun zu einem Hochverfügbarkeits-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 steht und eine Erläuterung der Konfiguration des Brokers zur Verwendung eines solchen Diensts finden Sie unter Using JAAS-Based Authentication in Sun Java System Message Queue 4.2 Administration Guide.

Formatänderung für persistenten Datenspeicher

Message Queue 4.1änderte den JDBC-basierten Datenspeicher dahingehend, dass Hochverfügbarkeits-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 werden automatisch auf die Version 410 erhöht.

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 nun mit dem Befehlsdienstprogramm (imqcmd) Transaktionen bereinigen (in einem 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 stellt die Verbindungs-ID für die Verbindung bereit, welche die Transaktion gestartet hat, und gibt die Uhrzeit an, zu welcher 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 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 Java System Message Queue 4.2 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 zur Syntax des Befehls imqcmd finden Sie in Kapitel 13, Command Line Reference in Sun Java System Message Queue 4.2 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] Verwenden des integrierten Persistenzspeichers:
        Version=400
        Broker-ID=Mozart1756
        Datenbankverbindung url=jdbc:oracle:thin:@Xhome:1521:mqdb
        Datenbankbenutzer=scott
Ausführen im Standalone-Modus.
Datenbanktabellen wurden bereits erstellt.

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 bei Message Queue 4.0 die Version des dateibasierten Datenspeichers weiterhin 370 ist, da keine Änderungen daran 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 Clientanwendungsname

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