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:

• Mehrere Ziele für einen Herausgeber bzw. Abonnenten

• Schemavalidierung von XML-Payload-Meldungen

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

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

• Unterstützung für MySQL-Datenbank

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.)

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:

• Größe: large, medium, small, ...

• Farbe: red, green, blue, ...

• Form: circle, triangle, square, ...

Die Nachrichtenwarteschlange unterstützt folgende Platzhalterzeichen:

• * steht für ein einzelnes Segment

• ** steht für ein oder mehrere Segmente

• > Steht für eine beliebige Anzahl aufeinander folgender Segmente

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:

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.

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:

• Name der xa_switch_t-Struktur: sun_my_xa_switch

• Name des Ressourcenmanagers: SUN_RM

• Die zu verknüpfende MQ C-API-Bibliothek: mqcrt

• Zeichenfolge xa_close und Format: none

• Zeichenfolge xa_open und Format: durch “;” getrennte Name=Wert-Paare

Folgende Name/Wert-Paare werden unterstützt:

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:

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:

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:

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.