Search code examples
jmsmq

Synchronous request-reply pattern in a Java EE container

I am looking to implement an synchronous request-reply pattern using JMS inside a Java EE container. The sequence would be something like this

  1. Browser makes a request to web application for data. This is a blocking request (say on thread T1).
  2. The web app needs to connect to a remote web service to fulfill the above request. So it forms a request and places it on a queue (with a reply-to queue also declared).
  3. The remote service processes the requests and places the response on to the reply-to queue declared in step 2
  4. The response is read from the reply-to Q in the web app and made available to the blocking thread T1 of step 1.

I have followed the answer provided by T.Rob (How to match MQ Server reply messages to the correct request)

QueueReceiver queueReceiver = 
  session.createReceiver(destination, "JMSCorrelationID='customMessageId'");
TextMessage receivedMessage = (TextMessage)queueReceiver.receive( 15000 );

Is the above solution valid when running in a Java EE container (web module) where there could be multiple concurrent requests coming in?

Solution

  • This depends on the perception of "valid": It will probably compile and work. But from the design perspective, one could say that you can really improve it.

    If your thread is blocking, any asynchronous communication won't add any value. Instead it will make it slow, it will consume resources, and it might even create trouble (see link below).

    Whatever service is exposed by the the system processing the messages (possibly an MDB), extract it into a separate service class, and provide another frontend in the shape of a stateless session bean. So your service is exposed both by an sync and async interface, and the client can choose.

    In your scenario your servlet just calls an EJB synchronously.

    As for the problems which may happen otherwise: Have a look at JMS request/response pattern in transactional environment (this approach uses a temporary queue).

    Using a single queue (the way you have quoted in your question), you need a selector (the condition) to get relevant messages: This might be slow, depending on the volume in the queue.

    On the other hand, if you implement your servlet with asynchronous support as well (using @WebServlet(asyncSupported = true)), it's something different. In that case I would say it's a valid approach.

    In that scenario you can save resources (namely threads; but the HTTP connections remain open), because one background thread listening on a queue can serve multiple clients. Consider this if you have performance or resource problems. Until then I suggest the synchronous way, because it is easier to implement.