Asynchronous request response

It is very common to have asynchronous request response/reply communications between different systems in enterprise environments. A typical approach is to utilize the Queue and Message Driven Bean to implement the asynchronous conversations. For example, system A is running a workflow with multiple steps. At one of the steps, it needs to rely on another system B to execute a particular task, which might take a while to do; in this case, system A sends a message to system B, through a queue, which system B is listening to; once system B finishes the task, it will send response to another queue, and trigger a MDB at system A, to resume the workflow.

Recently I am facing an issue – at system A side, we have multiple releases all installed and running on servers, lets call them A1, A2, A3….and they are all sending requests to system B;l at system B side, there is only one environment unfortunately.  So, the challenge is, without changing anything at system B side, how can we make sure the responses from system B reach to the correct system A?

Obviously the normal one request queue and one response queue at the middle is not supporting this scenario. We’d need something like a router in the middle to faciliate the routing of responses to its request source. There are two open source frameworks to help us here – the Apache Camel and the Spring Integration. We will need to set up multiple queues, code and configure channels and routers.

Now I am wondering whether we can make it even simpler? First, I still need to set up queues for every release of system A, also, Apache Camel and Spring Integration are great help but still I need to do more coding.

I think we need to find a way to implement the asynchronous communications without queues. One way is to leverage the Restful web service – at both A and B sides.
When A needs to send a message, it will send a POST request to http://dev.system-b.com/resources/message/1234. The message will includes system A’s state, for example, {reply-to:”http://release1.system-a.com/resources/message/response/1234″}; Then after system B finishes the task, it will send a response to the reply-to address in the original message: http://release1.system-a.com/resources/message/response/1234.

This approach assumes we have services running at both A and B, wihch usually happens in practice.
The benefits are – no more queue configuration for every realease of A and less coding.
The trade-off, might be, the queues are more stateble and reliable than http calls.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s