WebSphere MQ Request/Reply-Szenario

Question

Ich arbeite gerade an einem Projekt, bei dem ich mit einem IBM System kommunizieren muss, das über WebSphere MQ mit der Außenwelt kommuniziert. Ich muss das System in einer "Anfrage-Antwort" -Methode mit Warteschlangen abfragen, und ich werde dies über einen Warteschlangenmanager tun.

Allerdings kann ich nicht ganz verstehen, wie das in der Praxis funktioniert.

Angenommen, ich habe mehrere Instanzen der gleichen Anwendung, die eine Nachricht in eine Anforderungswarteschlange legt. Die Nachricht erhält nach dem Verlassen der Anwendung eine CorrelationId und und ReplyToQueue -Eigenschaft wird für jede Nachricht festgelegt, um sicherzustellen, dass der Warteschlangenmanager weiß, auf welche Warteschlange die Antwort zu legen.

Wie funktioniert der Warteschlangenmanager jedoch mit der Antwortwarteschlange? Es gibt keine Garantie hinsichtlich des Zeitpunkts der Antworten, also wie kommt es, dass die richtige Antwort an die Anwendungsinstanz zurückkehrt, die die entsprechende Anfrage ausgegeben hat?

Ich denke an Nachrichtenwarteschlangen als eine FIFO-Warteschlange, in denen Nachrichten nacheinander ausgewählt werden müssen. Dies würde jedoch bedeuten, dass Instanz A eine Antwort auswählen könnte, die für Beispiel B gedacht ist. Offensichtlich kann dies nicht so sein, wie es funktioniert.

Dann, als ich an der API aussehen (com.ibm.mq.MQQueue) Ich sehe, dass eine Nachricht, die ich die Chance haben, wählen Sie die CorrelationId und MessageId der Anforderungsnachricht zu liefern. Bedeutet dies, dass der Warteschlangenmanager, wenn ich den Warteschlangenmanager nach einer Nachricht (mit diesen IDs) abfrage, die Nachrichten in der Warteschlange durchläuft und die entsprechende Nachricht zurückgibt? Dies würde andererseits bedeuten, dass wir nicht über eine FIFO-Warteschlange sprechen?

Answer 1

Es ist allgemeine Praxis, CorrelationId zu verwenden, um Anfrage- und Antwortnachrichten zu verknüpfen. Es funktioniert auf diese Weise:

1) Angenommen, es gibt zwei Warteschlangen, eine REQQ - Anforderungswarteschlange, in der Nachrichten gefragt werden, die eine andere Anwendung, Dienstanwendung, abholen und verarbeiten und eine RESPQ, auf die die Dienstanwendung Antworten ausgibt.

2) Die Requester-Anwendung (nennen wir es als REQAPP) setzt eine Anforderungsnachricht (REQMSG) an die Anforderungswarteschlange (REQQ). Vor dem Senden der Nachricht setzt REQAPP die ReplyToQ-Eigenschaft für die Nachrichten auf RESPQ. Wenn die Anforderungsnachricht gesendet wird, aktualisiert der JMS-Provider die gesendete Nachricht mit einer eindeutigen Nachrichten-ID. Die Anfordereranwendung speichert diese eindeutige Nachrichten-ID zur späteren Verwendung zwischen.

3) Auf der anderen Seite der Welt ruft die Dienstanwendung den REQMSG von REQQ ab, liest die Eigenschaften MessageId und ReplyToQ aus dieser Nachricht, verarbeitet die Anforderung und bereitet die entsprechende Antwortnachricht RESPMSG vor. Es setzt dann die CorrelationId-Eigenschaft des RESPMSG auf die MessageId, die von REQMSG gelesen wird, und setzt die Antwort auf ReplyToQ.

4) Die Anforderer Anwendung, wenn Antworten zu lesen, verwendet es die Caches Meldungs ​​und setzt wie unten Auswahlkriterien Antwortnachricht

GET MESSAGE FROM RESPQ WHERE RESPMSG.CORRELATIONID==REQMSG.MESSAGEID 

Diese Auswahlkriterien stellt sicher, zu lesen, dass die korrekten Antwortnachrichten abgerufen werden. Der Schlüssel hier ist, dass die Dienstanwendung die CorrelationId für die Antwortnachricht auf die MessageId der Anforderungsnachricht setzen muss.

Obwohl die Warteschlange FIFO-Typ ist, bietet die MQ-Implementierung die Zustellung von Nachrichten auf Prioritätsbasis, wenn Nachrichten mit hoher Priorität zuerst oder FIFO-Basis zugestellt werden, wobei die Nachricht über der Warteschlange zuerst übermittelt wird. Nachrichten können auch mithilfe von Auswahlkriterien abgerufen werden, wie im obigen Beispiel erläutert.

Hoffnung half diese

Answer 2

Shashi Antwort ist für viele Situationen vor Ort auf und ist in der Tat die primäre Methode der Antworten unter mehreren, relativ geringen Volumen anfordernden Anwendungen zu verteilen.

Eine bessere Wahl für Dienste mit hohem Volumen würde mehrere RESPQs beinhalten. Sie können eine separate RESPQ für jede Instanz von REQApp bereitstellen, indem Sie temporäre dynamische Warteschlangen zum Empfangen der RESPMsgs verwenden. Jede Instanz von REQApp erstellt das TDQ mithilfe der MQOPEN-Funktion und gibt den RESPQ-Namen im ReplyToQ-Attribut jeder gesendeten Nachricht an .

Mit dieser Konfiguration müssen Sie sich nicht um Sequenzierungs- und Korrelations-IDs kümmern, da die Nachrichten in der Reihenfolge, in der sie von der Dienstanwendung verarbeitet werden, an die einzelnen RespQs zurückgegeben werden.

Wichtiger Hinweis hier ist, dass TDQs genau das sind - vorübergehend. Wenn die Anwendung zum Öffnen die Warteschlange schließt - entweder über MQCLOSE oder durch Beenden - sind alle Nachrichten im TDQ verloren und nicht wiederherstellbar. Wenn dies ein Problem ist - dass alle Antworten verarbeitet werden müssen, egal was -, dann möchten Sie einmalig eine Reihe von permanenten dynamischen Warteschlangen (auch mit MQOPEN) zuweisen, eine für jede Instanz von REQApp, und jede Instanz von REQApp muss Stellen Sie jedes Mal die Verbindung zur selben Warteschlange wieder her.

Ich hoffe, dass dies auch hilft.