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.