How to implement a JMS router with request-reply pattern

Question

I have a couple of applications which need to communicate with each other using JMS. I will describe them as Server and Client. The following steps are performed:

1. The Client sends a request to the Server remembering the message ID.
2. The Server sends a reply to the given reply-to address (and also setting the correlation ID based on the message ID of the request).
3. The Client matched the reply to the request using the correlation ID.

This works fine if it's just those two.

When we introduce the (content based) Router the following steps are performed:

1. The Client sends a request to the Router remembering the message ID.
2. The Router checks the content of the message and forwards the message to the Server. (When forwarding the message ID changes.)
3. The Server sends a reply to the given reply-to address (and also setting the correlation ID based on the message ID of the request).
4. The Client doesn't match the reply to the request because the router changed the message ID.

I cannot for the life of it figure out how to implement the router correctly while being compliant with the JMS specifications.

I have come up with the following but do not know if this is best practice:

1. The Client sends a request to the Router remembering the message ID.
2. The Router checks the content of the message.
3. The Router remembers the original message and sends a new message to the Server (setting the reply-to address to the Router's reply channel).
4. The Server sends a reply to the given reply-to address (and also setting the correlation ID based on the message ID of the new request).
5. The Router matches the reply to the request the Router made.
6. The Router creates a reply based on the reply of the Server, setting the correlation ID to the message ID of the original message.
7. The Client matches the Router's reply to the original request.

How should a JMS router work / is my design correct?

Answer 1

I was looking for a more authoritative answer possibly containing references to official documentation so I did some more research and this is the best I could find:

In the referenced document there are two patterns described:

Message ID Pattern

1. The client sets a reply-to address in the request and sends it to the server.
2. The server copies the message ID of the request, sets this as the correlation ID of the reply and sends the reply to the reply-to address of the request.

Correlation ID Pattern

1. The client sets a correlation ID in the request and sends it to the server.
2. The server copies the preset correlation ID of the request as the correlation ID of the reply and sends the reply to a predefined queue.

The following image gave me the idea to implement the message ID pattern and implement the router as a proxy:

So in short, I have gone with my initial idea.

Source: http://docs.oracle.com/cd/E13171_01/alsb/docs25/interopjms/MsgIDPatternforJMS.html

Answer 2

The reason why things don't work when you have a content based router, is that content based router is creating a new message object which has a new message id, and it does not have the correlation id set form the original message.

---

Here is how I have done it in the past. Suppose you have the following queues.

• Channel A - Client puts requests here

• Channel S - Server get requests here

  1. client puts request on channel A and sets a client specific correlation id and reply to Queue
  2. router consumes message on A , creates a message to S with correlation id set and the reply to queue set
  3. server replies to the reply to queue using the clients correlation id

so the router should not be involved in the response message processing at all. Having said that here are some common errors in implementing this pattern.

• The server does not set the correlation id in the response message it generates, because the final consumer sees a reply to queue and just ignores the correlation id.
• The message queue has a configuration mistake