5

Let's say there is a mobile application that needs to make a sync request/query for some data from a server. The request will come to hosted JMS client first, that will publish a message/request on external Queue (from partner). Now here where it start to be unclear. How do I get a response back from the partner in the synchronous fashion.

  • Should the partner expose separate queue for me to subscribe and I then block the mobile request till I get the response message from that separate queue?
  • Does JMS or proprietary WebSphere MQ interface have support for sync messaging?
  • What are other ways to implement it with messaging?

Thanks

user567068
  • 435
  • 8
  • 15

3 Answers3

5

The textbook pattern is as follows:

  1. JMS app receives a request from the mobile device.
  2. JMS app opens the reply-to queue (which may be dynamic).
  3. JMS app prepares a request message specifying the destination from #2 as the JMSREplyTo destination.
  4. JMS app sends the request outside of syncpoint to the external service provider.
  5. JMS app listens for a response with a specified wait interval. If it used a dynamic reply-to queue it does a simple receive. If multiple instances are listening on the same queue (which is more likely with an external service) then it uses the JMSMessageID returned from the send as the JMSCorrelationID specified on the receive.
  6. JMS app receives the response from the external service.
  7. JMS app replies to the mobile device.

Note that with WMQ the expected behavior from the service provider is to copy the JMSMessageID from the request message to the JMSCorrelationID of the response. It is less common to require the sender to generate a JMSCorrelation ID and copy it to the JMSCorrelationID of the response but some applications use that behavior. You will need to understand how your service provider deals with this to determine the correct behavior for your requester application.

If you are using the complete WMQ Client install you will already have sample code that does most of this. If installed to the default location, look in...

C:\Program Files\IBM\Websphere MQ\tools\jms\samples\simple\simpleRequestor.java

...or the equivalent location under /var/mqm for UNIX/Linux distributions. This is one of the many reasons to install the full client rather than simply grabbing the jar files. If you need to download the client is is delivered as SupportPac MQC7.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Thanks T.Rob, \n we don't have WMQ server. Can the reply-to queue (from 1.) be a remote queue as well? So that we be a pure client and don't have to host server? Or you kind of have to have reply-to queue locally? Also, will this scenario work in a concurrent environment? Like if hundreds of mobile devices will send messages trough the same consumer and receive response through the same listener. – user567068 Feb 18 '11 at 03:11
  • D'oh! I misunderstood the question. Let me re-write the answer. – T.Rob Feb 18 '11 at 03:18
  • Thank you T.Rob. You made it super clear! Can you please tell me if for every single request from mobile I need to perform all the steps from SimpleRequestor.java (like create connection factory, get connection, open queue, create temp queue, etc.). Or should I create connection factory, connection, and dest. queue only once? But create temp. (reply-to) queue for every request? Also temp. queue is that something that is created locally? And doesn't requre hosting server, right? – user567068 Feb 18 '11 at 15:04
  • 1
    Typically the app will open a connection per-thread and loop through the steps above. Just be aware that transactions are scoped per connection so this usually means a connection per thread. When using an external service, they will tell you whether they support dynamic queues. A dynamic queue is created on the QMgr your app is connected to. It is actually a bit unusual for an external service to allow client connections rather than making you run your own QMgr but the decision is up to them. WMQ supports either model. – T.Rob Feb 18 '11 at 16:04
2

The "client" can create a temporary queue and pass the name of this in the request.

The "server" receives a request on a known queue, but sends the "replyTo" with has the name of the queue sepecified by the "client".

JMS has a "replyTo" property for this purpose.

This way the client only sees messages intended for it.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

On the top of my head I see 2 ways.

  1. create 2 queues: incoming and outgoing. Client sends to incoming queue and receives messages from outgoing queue.

  2. you can use the same queue for both. Just set special property to each message and use selector to filter relevant messages only.

your server side should send message first and then call receive method (see JMS javadoc). This method is blocked until you get message or timeout is expired. It is important for you to use this way and not listen for messages (listeners are used for async. mode)

AlexR
  • 114,158
  • 16
  • 130
  • 208