Asynchronous Request/Reply (continued...)

In my last post, I discussed how request/reply can be achieved asynchronously in place of the synchronous variety at the service boundary. When the sending service receives its response, it needs a way of restoring the state that was present at the time the request was sent.

In order to achieve this, we must put a correlation ID in the request and response messages. The requesting party stores the relevant information it needs to process the response in persistent storage referenced by the correlation ID, and then sends the request.

The responding party places the correlation ID it received in the request into the response message. When the sending party then receives the response, it can look up the relevant state in the database and restore the state that was present at the time the request was sent.

MS Workflow Foundation natively contains the ability to correlate workflow instances to external interactions. Leveraging libraries such as this behind the service boundary can certainly make our lives easier.

Workflow Foundation persists the state of the workflow instance in a persistent store when it goes to sleep awaiting another message so that if the server is rebooted, the workflow state is not lost.

Another approach to maintaining state between asynchronous requests and responses is to store the entire thread state in the request message header, rather than just a correlation ID. The receiving service then places the state back in the header of the response.

When the response is received, the service that sent the request can extract all the relevant state from the response message header.

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.