Asynchronous Request/Reply

In my previous post I concluded a discussion on synchronous request/reply and why it is bad news at the service boundary. But does that mean request/reply is finished altogether? Not at all.

There are many instances in which request/reply is the appropriate choice of message exchange pattern between services. Take for example a service that assesses risk. The requesting service provides a risk profile to be assessed, while the risk assessment service delivers the risk assessment response back to the requesting party.

So how do we deal with this requirement? We use asynchronous request/reply. Asynchronous request/reply is where the sending thread continues on about its business without awaiting the response, and when the response arrives it is handled by a separate thread.

The difficulty with this approach is that when the response is received, we have lost the state that was previously stored in all the local instance variables on the requesting thread. We need a way of restoring this state when the response is received in order to process the response.

I'll discuss some approaches for achieving this in my next post.