11

I have an webapp that is expected to fetch and display data from an External App which is accessible only via messaging (JMS).

So, if a user submits a request on a browser, the same HTTP request thread will have to interact with the Messaging system (MQ Series) such that the same request thread can display the data received from the Messaging System.

Is there a pattern I can make use of here? I saw some vague references on the net that use "Correlation ID" in this way:

Msg m = new TextMsg("findDataXYZ");
String cr_id = m.setCorrelationID(id);

sendQueue.send(m).

// now start listening to the Queue for a msg that bears that specific cr_id

Response r = receiverQueue.receive(cr_id);

Is there something better out there? The other patterns I found expect the response to be received asynchronously.. which is not an option for me, since I have to send the response back on the same HTTP request.

rk2010
  • 3,481
  • 7
  • 27
  • 39

2 Answers2

10

The request/reply messaging pattern is useful for your requirement. You typically use a CorrelationId to relate request & reply messages.

While sending request message you set JMSReplyTo destination on the message. Typically a temporary queue is used as JMSReplyTo destination. When creating a consumer to receive response use a selector with JMSCorrelationId, something like

cons = session.createConsumer(tempDestination,"JMSCorrelationId="+requestMsg.JMSMessageId);

At the other end, the application that is processing the request message must use the JMSReplyTo destination to send response. It must also use the MessageId of the request message and set it as CorrelationId of the response message.

Shashi
  • 14,980
  • 2
  • 33
  • 52
  • If I send one request after another, then should I create *new* temporary queue for each request? Or reuse the same temporary queue for all requests? Is such kind of reuse even allowed? If so, what approach is good, reuse or create? – Nawaz Feb 10 '16 at 09:36
  • Also, in your suggestion, if I set `"JMSCorrelationId="+requestMsg.JMSMessageId`, then I think I cannot *reuse* the same consumer to get more than responses, as the correlation id of the responses will be different? Moreover, if I use new tempQueue for each request, then I dont need to set message selector, as the tempQueue is dedicated for one response only. Either way I dont see any reason to set `JMSCorrelationId="+requestMsg.JMSMessageId`, as only one response will reach the consumer no matter what. Am I right? – Nawaz Feb 10 '16 at 09:42
  • Yes, if you are using tempQueue for each request then you don't need to use selectors. Selector is only needed when a queue is shared. – Shashi Feb 10 '16 at 10:26
  • Thanks. That makes sense to me. Now the next question is, if I use message id in the selector, then I cannot reuse the consumer. Right? – Nawaz Feb 10 '16 at 10:38
5

First, open the response queue. Then pass that object to the set reply-to method on the message. That way the service responding to your request knows where to send the reply. Typically the service will copy the message ID to the correlation ID field so when you send the message, take the message ID you get back and use that to listen on the reply queue. Of course if you use a dynamic reply-to queue even that isn't neessary - just listen for the next message on the queue.

There's sample code that shows all of this. If you installed to the default location, the sample code lives at "C:\Program Files (x86)\IBM\WebSphere MQ\tools\jms\samples\simple\SimpleRequestor.java" on a Windows box or /var/mqm/toolsjms/samples/simple/SimpleRequestor.java on a *nix box.

And on the off chance you are wondering "install what, exactly?" the WMQ client install is downloadable for free as SupportPac MQC71.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Thanks for the answer. So it looks like the pattern is: 1. Use the regular 'Send' queue for sending the request. 2. But for receiving, use a 'Temporary Queue. I installed the Client tool you have mentioned, and the SimpleRequestor class does this: `tempDestination = session.createTemporaryQueue(); consumer = session.createConsumer(tempDestination);` It looks great, but is it code that will work in Production where we are expecteg handle 1000s of such requests per second ? Looks like we will will creating a Temporary Queue for each request. – rk2010 May 28 '12 at 14:44
  • 1
    WMQ reuses the temporary queues and everything is in memory so obtaining a handle is very quick. You will need to keep an eye on the DLQ though because if your app times out before the reply shows up, the reply is routed to the DLQ. If you wish to use a pre-defined queue for the response queue, that works as well. You would then need to perform the GET by Correlation ID though, if multiple instances used the same queue. Predefined or Permanent Dynamic queue is necessary if the messages are persistent, though. – T.Rob May 28 '12 at 17:23