Versionshinweise zu Sun Java System Message Queue 3.7 UR1

Grundlegendes zu Message Queue 3.7 UR1

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 3.7 UR1 ist ein Maintenance-Release von Message Queue 3.6, der verschiedene Fixes für die Fehlerbeseitigung sowie ein paar kleinere Verbesserungen umfasst. Der vorliegende Abschnitt umfasst die folgenden Informationen:

Neue Funktionen in dieser Version

Message Queue 3.7 UR1 umfasst die folgenden neuen Funktionen:

Die genannten Themen werden in den folgenden Unterabschnitten näher beschrieben.

Kombination der Funktionen von Platform Edition und Enterprise Edition in einer Edition

Zur Rationalisierung unserer Produktlinie werden die Funktionen der Platform Edition und der Enterprise Edition von Sun Java Message Queue kombiniert. Ab Message Queue 3.7 UR1 wird nur eine Edition bereitgestellt, wodurch die Funktionseinschränkungen der eigenständigen Bereitstellung wegfallen. Auf diese Weise soll die Verwendung des Produkts vereinfacht werden.

Die Kombination der verschiedenen Editionen ermöglicht ferner eine bessere Anbindung von Message Queue an das Solaris Enterprise System und bietet die Möglichkeit zur allgemeinen Nutzung der Enterprise Edition-Funktionen, jedoch ohne Anspruch auf Support, Wartung oder Haftung. Wie bei vorherigen Versionen werden weiterhin verschiedene Lizenzierungsoptionen für Support- und Wartungsdienste bereitgestellt. Message Queue wird weiterhin im Paket mit Java Enterprise System und der Application Platform Suite bereitgestellt. Bitte besuchen Sie den Sun-Onlinestore unter http://www.sun.com, oder wenden Sie sich an Ihren Vertriebsbeauftragten, um die optimal auf Ihre Anforderungen abgestimmte Option zu ermitteln. In der nachfolgenden Tabelle werden die Upgrade-Pfade auf die neue Einzel-Edition von Message Queue beschrieben.

Tabelle 1–2 Upgrade-Pfade für Message Queue 3.7 UR1


Vorherige Edition	Upgrade-Pfad	Kommentare
Platform Edition	Sun Java System Message Queue 3.7 UR1	Alle Funktionen (Platform und Enterprise) sind jetzt für 3.7 UR1-Kunden verfügbar. Support-Optionen stehen mit dem Erwerb dieser Lizenz zur Verfügung.
Enterprise Edition	Sun Java System Message Queue 3.7 UR1	Keine Änderungen am Funktionsumfang. Es stehen verschiedene Lizenzierungs- und Support-Optionen zur Verfügung.
Platform Edition-Support-Verträge	Upgrade auf Enterprise Edition-Support-Vertrag.	Vorhandene Support-Verträge für Vorgängerversionen der Platform Edition werden weiterhin erneuert. Für vorherige Versionen der Platform Edition werden keine neuen Verträge abgeschlossen.
Enterprise Edition-Support-Verträge	Keine Änderung.	Vorhandene Verträge werden weiterhin erneuert. Es werden weiterhin neue Verträge abgeschlossen.

In der nachstehenden Tabelle werden die Änderungen in Bezug auf die Bereitstellung für die verschiedenen Message Queue-Produkte beschrieben.

Tabelle 1–3 Änderungen in Bezug auf die Bereitstellung von Message Queue-Produkten


Produkt	Bisherige Bereitstellungsmethode	Neue Bereitstellungsmethode	Kommentare
Open Message Queue	Nicht anwendbar	Produktseite im Sun Download Center	Eigenständiger Download. Nur Community-Support. Keine Support-Verträge verfügbar.
Message Queue Platform Edition	Message Queue-Produktseite im Sun Download Center	Nicht mehr verfügbar	Ab sofort ist nur noch die Edition von Message Queue verfügbar, die Platform- und Enterprise-Funktionen verbindet.
Message Queue Enterprise Edition-Testversion (über Platform Edition)	Message Queue-Produktseite im Sun Download Center	Testlizenz nicht länger erforderlich.	Nicht länger erforderlich.
90-Tage-Testversion der Message Queue Enterprise Edition (über Java Enterprise System-Download oder -CD)	Java Enterprise System Download Center, früher als Version 3 GA (März 2006)	Solaris Enterprise System Download Center	Solaris Enterprise System-Lizenz. Support-Optionen stehen mit der Produktlizenz zur Verfügung. (Eine 90-Tage-Testlizenz ist nicht mehr erforderlich.)
Message Queue Enterprise Edition über SunStore, CD, Einzellizenz, Java Enterprise System-Lizenz, Suite-Lizenz, bereitgestellt über Java Enterprise System	Java Enterprise System oder Suite Download Center, Medien.	Solaris Enterprise System oder Suite Download Center, Medien.	Keine Änderung.

Änderungen an der Schnittstelle für C-API- und C-Client-Runtime

Neue Funktion: MQGetDestinationName()
MQGetDestinationName (const MQDestinationHandle destinationHandle, MQString * destinationName);
Verwenden Sie diese Funktion, um den Namen eines Ziels abzurufen. Der zurückgegebene Wert destinationName ist eine Kopie, die von der aufrufenden Komponente durch Aufruf der Funktion MQFreeString() freigegeben werden muss.

Parameter

destinationHandle

Ein Handle für das Ziel, dessen Namen Sie ermitteln möchten.

destinationName

Der Ausgabeparameter für den Namen.

Diese Funktion ist nützlich, wenn Sie das ReplyTo-Muster verwenden. Sie können mithilfe der Funktion MQGetMessageReplyTo ein Handle für das Ziel abrufen, an das die Nachricht gesendet werden soll. Anschließend können Sie über MQGetDestinationName den Namen dieses Ziels abrufen. Nach Abruf des Zielnamens können Sie die Nachrichtenverarbeitung basierend auf dem Namen durchführen.

Neuer aufgelisteter Wert: MQ_MESSAGE

Der neue MQMessageType, MQ_MESSAGE, erlaubt C-Clients den Austausch von JMS-Nachrichten vom Typ Message mit anderen Message Queue-Clients (sowohl C als auch Java):

typedef enum _MQMessageType {MQ_TEXT_MESSAGE = 0, 
                             MQ_BYTES_MESSAGE = 1,
                             MQ_MESSAGE = 3, 
                             MQ_UNSUPPORTED_MESSAGE = 2} MQMessageType;

Der Typ MQ_MESSAGE identifiziert Nachrichten, die einen Header sowie Eigenschaften, jedoch keinen Nachrichtentext aufweisen. Sie verwenden die Funktion MQCreateMessage (), um eine Nachrichten von diesem Typ zu erstellen.

Eine neue Verbindungseigenschaft, MQ_UPDATE_RELEASE_PROPERTY, welche die Update-Release-Version für die installierte Version von Message Queue angibt. Verwenden Sie die Funktion MQGetMetaData(), um Versionsinformationen abzurufen.

Formatänderungen für die persistente Speicherung

Zur Verbesserung der Leistung wurden zwei Änderungen am Message Queue-Format für die persistente Speicherung vorgenommen. Eine Änderung betrifft den Dateispeicher, die andere den JDBC-Speicher.

Transaktionsinformationen im Dateispeicher

Das Format von Transaktionsstatusinformationen, die im dateibasierten persistenten Speicher von Message Queue gespeichert werden, wurde geändert, um die Datenträger-E/A zu reduzieren und die Leistung von JMS-Transaktionen zu verbessern.
Oracle JDBC-Speicher

In vorherigen Versionen von Message Queue wurde für das mit Oracle verwendete Speicherschema der Datentyp LONG RAW zur Speicherung von Nachrichtendaten eingesetzt. Mit Oracle 8 wurde der Datentyp BLOB eingeführt, der den Typ LONG RAW ablöste. Ab Message Queue 3.7 UR1 findet ein Wechsel auf den Datentyp BLOB statt, um Leistung und Unterstützung zu verbessern.

Da sich diese Änderungen auf die Speicherkompatibilität auswirken, wurde die Speicherversion von 350 in 370 geändert. Message Queue 3.7 UR1 unterstützt eine automatische Konversion des persistenten Speichers von den älteren Versionen 200 und 350 auf 370 - sowohl für JDBC- als auch für dateibasierte Speicher. Beim ersten Start von imqbrokerd wird bei Ermittlung eines älteren Speichers eine Migration auf das neue Format vorgenommen. Der alte Speicher wird hierbei erhalten.

Wenn Sie dieses Upgrade rückgängig machen möchten, können Sie Message Queue 3.7 UR1 deinstallieren und die zuvor ausgeführte Version neu installieren. Da die ältere Kopie des Speichers beibehalten wird, kann der Broker mit der älteren Kopie des Speichers ausgeführt werden.

Hardware- und Software-Anforderungen

Informationen zu den Hardware- und Software-Anforderungen von Message Queue finden Sie im Sun Java Enterprise System Installation Guide.

Arbeiten mit Solaris 10-Zonen

Als Zone wird eine Container-Technologie von Solaris bezeichnet, die separate Umgebungen auf einem Computer bereitstellt und Anwendungen logisch voneinander isoliert. Zonen ermöglichen Ihnen die Erstellung virtueller Betriebssystemumgebungen innerhalb einer Instanz des Solaris-Betriebssystems. Durch die Ausführung von Anwendungen in unterschiedlichen Zonen können unterschiedliche Instanzen oder unterschiedliche Versionen derselben Anwendung auf einem einzigen Computer ausgeführt werden, während es gleichzeitig möglich ist, alle Ressourcen zentral zu verwalten und gemeinsam zu verwenden.

Dieser Abschnitt bietet einen kurzen Überblick über Zonen und beschreibt deren Verwendung mit Message Queue 3.7 UR1.

Grundlegendes zu Zonen

Eine Zonenumgebung umfasst eine globale Zone und eine oder mehrere nicht globale Zonen. Wenn Solaris 10 zum ersten maul auf einem System installiert wird, ist nur eine globale Zone vorhanden. Ein Administrator kann weitere nicht globale Zonen als untergeordnete Elemente der globalen Zone erstellen. Jede Zone wird als unabhängiges System angezeigt, auf dem Solaris ausgeführt wird. Jede Zone verfügt über eine eigene IP-Adresse, eine eigene Systemkonfiguration, eigene Instanzen der ausgeführten Anwendungen sowie einen eigenen Bereich im Dateisystem.

Die globale Zone enthält Ressourcen, die von den nicht globalen Zonen gemeinsam verwendet werden können. Auf diese Weise ist es möglich, bestimmte Verwaltungsfunktionen zu zentralisieren. Beispielsweise stehen Pakete, die in der globalen Zone installiert wurden, für alle nicht globalen Zonen zur Verfügung (Verbreitung). Dies ermöglicht eine zentrale Lebenszyklusverwaltung einschließlich Installation, Upgrade und Deinstallation. Gleichzeitig für die Isolierung durch die nicht globalen Zonen zu mehr Sicherheit und ermöglicht es Ihnen, unterschiedlich konfigurierte Instanzen oder unterschiedliche Versionen derselben Anwendung auf einem einzigen Computer auszuführen.

Bei nicht globalen Zonen wird zwischen Whole-Root-Zonen und Sparse-Root-Zonen unterschieden. Für welche dieser Zonen Sie sich als Umgebung für eine Anwendung entscheiden, richtet sich danach, welche Schwerpunkte Sie in Bezug auf administrative Steuerung und Ressourcenoptimierung setzen möchten.

Whole-Root-Zonen enthalten eine Kopie des Dateisystems der globalen Zone, in der Lese- und Schreiboperationen ausgeführt werden können. In der globalen Zone installierte Pakete werden (mit Registrierungsinformationen) automatisch in die Whole-Root-Zone kopiert. Dies maximiert die administrative Steuerung, jedoch auf Kosten der Ressourcennutzung.
Sparse-Root-Zonen enthalten eine Kopie eines Teils des Dateisystems der globalen Zone, in der Lese- und Schreiboperationen ausgeführt werden können. Weitere Dateisysteme werden als schreibgeschützte Dateisysteme geladen. In der globalen Zone installierte Pakete werden über schreibgeschützte Dateisysteme und über die automatische Synchronisierung von Registrierungsinformationen in den Sparse-Root-Zonen bereitgestellt. Sparse-Root-Zonen optimieren die Ressourcennutzung auf Kosten der zentralen Verwaltung.

Java Enterprise System - Zoneneinschränkungen

Die Java Enterprise System-Komponenten hängen von einigen gemeinsam genutzten Komponenten ab, was zu einigen Einschränkungen bei der Arbeit mit Zonen führt. In einer Zonenumgebung gelten für gemeinsam genutzte Komponenten die folgenden Regeln:

Alle gemeinsam genutzten Komponenten innerhalb einer Zone müssen dieselbe JES-Version aufweisen. Diese Anforderung hat drei Auswirkungen.
- Wenn Sie unterschiedliche Versionen einer gemeinsam genutzten Komponente verwenden möchten, muss jede Version in einer eigenen Zone vorliegen.
- Wenn innerhalb einer Zone eine gemeinsam genutzte Komponente auf eine neuere Version aktualisiert oder eine neuere Version installiert wird, müssen alle gemeinsam genutzten Komponenten aktualisiert werden.
- Wenn Sie gemeinsam genutzte Komponenten in der globalen Zone installieren, müssen Sie dafür Sorge tragen, dass die gemeinsam genutzten Komponenten in nicht globalen Zonen gegebenenfalls aktualisiert werden.
Gemeinsam genutzte Komponenten können nicht in Sparse-Root-Zonen installiert werden, da das Dateisystem in Sparse-Root-Zonen lese- und schreibgeschützt ist. Stattdessen muss die Installation in der globalen Zone erfolgen. Produktkomponenten, die von gemeinsam genutzten Komponenten abhängen, müssen zunächst in der globalen Zone installiert werden und dann auf die nicht globalen Zonen verbreitet werden.

Diese Anforderungen wirken sich auf die Installation von Message Queue aus, da es sich um eine Produktkomponente von Java Enterprise System handelt und somit die Verwendung von Zonen eingeschränkt ist.

Hinweis –

Message Queue wird im /usr Verzeichnis installiert und muss daher zunächst in der globalen Zone installiert oder aktualisiert werden.

Message Queue - Fallbeispiele

Wenn Message Queue in der globalen Zone installiert ist, ist eine Weitergabe an alle nicht globalen Zonen konfiguriert. Nach der Installation von Message Queue in der globalen Zone ist in allen Zonen die gleiche Version Message Queue installiert: Melden Sie sich an einer beliebigen Zone an und führen Sie den Befehl pkginfo -l SUNWiqu aus. Sie werden feststellen, dass in der Zone die gleiche Produktversion installiert ist wie in der globalen Zone. Anschließend können Sie unabhängige Instanzen des Message Queue-Broker in jeder Zone ausführen, da die in den Verzeichnissen /var und /etc gespeicherten Instanzen- und Konfigurationsdaten nicht gemeinsam genutzt werden. (Die meisten der weiteren Java Enterprise System-Komponenten werden nicht weitergegeben, wenn sie in der globalen Zone installiert werden.)

Da Message Queue an nicht globale Zonen weitergegeben wird, ist die globale Instanz dauerhaft an die Installation in den nicht globalen Zonen gekoppelt. Jede Deinstallation oder Aktualisierung von Message Queue in der globalen Zone wirkt sich auf die Instanzen aus, die in den nicht globalen Zonen ausgeführt werden. Das folgende Beispiel zeigt, wie dieses Verhalten zu unerwünschten Ergebnissen führen kann:

Sie installieren Message Queue 3.7 UR1 in der globalen Zone. Dies führt dazu, dass Message Queue 3.7 UR1-Pakete auch in allen nicht globalen Zonen installiert werden.
Sie deinstallieren Message Queue 3.7 UR1 in einer Whole-Root-Zone. Anschließend installieren Sie Message Queue 3.6 in der Whole-Root-Zone.

Sie verfügen nun über unterschiedliche Versionen von Message Queue in den verschiedenen Zonen. Diese Konfiguration kann in bestimmten Situationen von Vorteil sein.
Sie deinstallieren Message Queue 3.7 UR1 in der globalen Zone. Dies führt dazu, dass Message Queue in allen weiteren Zonen ebenfalls deinstalliert wird - einschließlich der Message Queue 3.6-Instanz in der Whole-Root-Zone.

Berücksichtigen Sie stets den kaskadierenden Effekt, den die Installation bzw. Deinstallation von Message Queue in der globalen Zone hat.

Die zwei folgenden Praxisbeispiele erläutern, wie Sie unterschiedliche Instanzen und unterschiedliche Versionen von Message Queue in verschiedenen Zonen installieren.

Hinweis –

Wenn Sie Message Queue in einer Whole-Root-Zone unter Solaris 10, Solaris 10U oder Solaris 10U2 installieren möchten, müssen Sie zunächst ein Upgrade für Lockhart in der globalen Zone vornehmen. Zusätzliche Informationen finden Sie in den Umgehungsmöglichkeiten für Fehler 645030.

So installieren Sie die gleiche Version von Message Queue in unterschiedlichen Zonen

Installieren Sie die gewünschte Version von Message Queue in der globalen Zone.

Diese Versionen werden an eine bestehende nicht globale Zone weitergegeben. Wenn Sie zusätzliche nicht globale Zonen erstellen, wird Message Queue ebenfalls an diese Zonen weitergegeben. (Sie können unterschiedliche Instanzen sowohl in Whole-Root-Zonen als auch in Sparse-Root-Zonen installieren; der Einsatz von Sparse-Root-Zonen erlaubt jedoch eine effizientere Nutzung von Speicherplatz und anderen Ressourcen.)

Wenn Sie Message Queue an eine beliebige andere nicht globale Zone weitergeben möchten, müssen Sie diese Zonen jetzt erstellen.

Führen Sie eine Instanz von Message Queue in jeder nicht globalen Zone aus.

So installieren Sie unterschiedliche Versionen von Message Queue in verschiedenen Zonen

Deinstallieren Sie Message Queue aus der globalen Zone.

Erstellen Sie Whole-Root-Zonen, und konfigurieren Sie jede Zone so, dass das Verzeichnis /usr nicht gemeinsam genutzt wird. Sie erreichen dies, indem Sie bei Erstellung der Zone die folgende Direktive verwenden:
```
remove inherit-pkg-dir dir=/usr
```

Installieren Sie unterschiedliche Versionen von Message Queue in jeder Whole-Root-Zone.

Hinweis –
Berücksichtigen Sie, dass die Installation oder Deinstallation von Message Queue in der globalen Zone Auswirkungen auf alle Instanzen (und Versionen) von Message Queue hat, die in Whole-Root-Zonen ausgeführt werden.