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.

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

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

- Temporäre Warteschlange als Antwortwarteschlange verwenden.
- Bereichsorientiertes SIB-Aliasziel verwenden, um Nachrichten auf einen einzigen Warteschlangenpunkt zu beschränken.
- Antwortnachrichten auf den lokalen Warteschlangenpunkt der anfordernden Anwendung beschränken.
- Anfordernden für den gleichzeitigen Nachrichtenkonsum von allen Warteschlangenpunkten konfigurieren.
Berücksichtigen Sie die Vor- und Nachteile jeder Option sowie die Anforderungen Ihrer Anwendung, bevor Sie sich für einen Ansatz entscheiden.
Zusammenfassung
- 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.
- 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.