JMS-Messaging (Anforderung/Antwort) mit Cluster-Bus-Membern

Ein typisches JMS-Messaging-Muster ist eine anfordernde Anwendung, die eine Nachricht zur Verarbeitung durch einen Messaging-Service, z. B. eine nachrichtengesteuerte Bean, an eine JMS-Warteschlange sendet.

Wenn die anfordernde Anwendung die Anforderungsnachricht sendet, enthält die Nachricht eine andere JMS-Warteschlange, an die der Service eine Antwortnachricht senden soll. Nach dem Senden der Anforderungsnachricht wartet die anfordernde Anwendung entweder auf die Antwortnachricht, oder sie stellt zu einem späteren Zeitpunkt die Verbindung wieder her, um die Antwortnachricht abzurufen.

Abbildung 1. Typisches JMS-Messaging-Muster
Ein typisches JMS-Messaging-Muster
Das Anforderung/Antwort-Muster setzt die folgenden Bedingungen voraus:
  • Die anfordernde Anwendung kann in der anfordernden Nachricht feststellen, wohin der Service die Antwortnachricht senden muss.
  • Die anfordernde Anwendung kann die Antwortnachricht von der Antwortposition konsumieren.
Eine JMS-Warteschlange kann auf ein SIB-Ziel verweisen, das in einem Busmember des Typs "Server" oder "Cluster" definiert ist.
  • Wenn das Busmember ein Server ist (der nur eine einzige Messaging-Engine haben kann) oder ein Cluster mit einer einzigen Messaging-Engine, identifiziert eine JMS-Warteschlange einen einzigen SIB-Warteschlangenpunkt.
  • Wenn das Busmember ein Cluster mit mehreren Messaging-Engines ist (gewöhnlich für die Unterstützung der gleichmäßigen Auslastung oder der Skalierbarkeit), identifiziert eine JMS-Warteschlange mehrere Warteschlangenpunkte, einen in jeder Messaging-Engine im Busmember.
Abbildung 2. Für ein Busmember des Typs "Anwendungsserver" definiertes SIB-Warteschlangenziel
Für ein Busmember des Typs 'Anwendungsserver' definiertes SIB-Warteschlangenziel
Das Standardverhalten ist wie folgt:
  • Der Warteschlangenpunkt, an den eine Anwendung Nachrichten sendet oder von dem sie Nachrichten empfängt, wird vom Messaging-System bestimmt.
  • Ein Konsument, in diesem Fall ein Konsument von JMS-Nachrichten, konsumiert für seine gesamte Lebensdauer nur von einem einzigen Warteschlangenpunkt.

Dieses Anforderung/Antwort-Verhalten ermöglicht, dass eine Antwortnachricht an einen anderen Warteschlangenpunkt gesendet werden kann als den, an dem der Anfordernde auf die Antwort wartet. Dies kann dazu führen, dass die Antwortnachricht nicht empfangen wird.

Abbildung 3. SIB-Warteschlangenziel, das für ein Cluster-Bus-Member mit zwei Messaging-Engines definiert ist
SIB-Warteschlangenziel, das für ein Cluster-Bus-Member mit zwei Messaging-Engines definiert ist.

Berücksichtigen Sie die Vor- und Nachteile jeder Option sowie die Anforderungen Ihrer Anwendung, bevor Sie sich für einen Ansatz entscheiden.

Zusammenfassung

Verwenden Sie die einfachste Lösung, die die Voraussetzungen für das Anforderung/Antwort-Szenario erfüllt. Beispiel:
  • Wenn Antwortnachrichten nur erforderlich sind, während die anfordernde Anwendung verbunden ist, verwenden Sie nicht persistente Nachrichten und temporäre Warteschlangen. Sie können mit dem Parameter timeToLive auch eine Lebensdauer für die einleitende Anforderungsnachricht festlegen, wenn die anfordernde Anwendung nur eine begrenzte Zeit auf eine Antwort warten soll.
  • Wenn ein einziger Warteschlangenpunkt (und die zugehörige Messaging-Engine) den gesamten Antwortnachrichtenverkehr für die anfordernden Anwendungen verarbeiten kann, aber ein Busmember des Typs "Cluster" mit mehreren Messaging-Engines für anderen Messaging-Verkehr (z. B. für die Anforderungsnachrichten) erforderlich ist, verwenden Sie ein SIB-Aliasziel, um die Nachrichten auf diesen einen Warteschlangenpunkt zu beschränken.

Sofern erforderlich, können Sie diese Optionen kombinieren, um die Lösung zu erhalten, die die Voraussetzungen der Anwendung am besten erfüllt und die beste Leistung und Skalierbarkeit bietet.

Die folgende Methode kann beispielweise geeignet sein, wenn anforderende Anwendungen ihre Antwortnachrichten gewöhnlich während der einleitenden Verbindung empfangen, aber in bestimmten, seltenen Situationen (z. B. bei einem Fehler) die Verbindung wiederherstellen müssen, um die Antwort zu empfangen:
  • Aktivieren Sie die Option scopeToLocalQP der JMS-Warteschlange, und ermöglichen Sie der anfordernden Anwendung, eine Verbindung zu jeder Messaging-Engine im Busmember des Typs "Cluster" herzustellen (d. h., legen Sie das Busmember als Ziel für die JMS-Verbindungsfactory fest). Auf diese Weise können die Verbindungen verteilt, aber die Antwortnachrichten auf den lokalen Warteschlangenpunkt beschränkt werden. In diesem Fall werden die Antwortnachrichten gefunden, während dieselbe Verbindung für den Empfang der Antwort verwendet wird, die zum Senden der Anforderung verwendet wurde.
  • Aktivieren Sie bei der Verbindungswiederherstellung nach einem Fehler die Option Nachrichtenerfassung in der JMS-Warteschlange so, dass die Antwortnachricht von jeder Position, an der sie gehalten wird, empfangen werden kann.

Dieser Ansatz ermöglicht die dynamische Verteilung der anfordernden Anwendungen und minimiert gleichzeitig die Auswirkungen der Nachrichtenerfassung auf die Leistung, indem ihre Verwendung auf Fehlerszenarien beschränkt wird.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjt0020_
Dateiname:cjt0020_.html