SeeAlso: EDRADesignNotes

Summary: Building asynchronous services using the EDRA

This topic has come up several times, and often from different angles. So this note touches the topic from the perspective of returning an immediate response to the client and continuing processing (as opposed to things like reliable messaging services which often is associated with asynchronous services).

The EDRA architecture was designed with the intention of supporting either synchronous or asynchronous services. Specifically supporting services in one of three modes: synchronous request/reply, asynchronous request/reply, and asynchronous one-way. But it is up to the transport implementation to determine which combination of these three modes it supports.

* The Webservice transport we included supports synchronous request/reply and asynchronous one-way.
* The MSMQ transport we included supports asynchronous one-way and asynchronous request/reply.
* The Remoting transport we included supports only synchronous request/reply.

You could for example create a Remoting transport that supports asynchronous request/reply and asynchronous one-way as well, and the framework would support that, but the version we created we only added support for the synchronous request/reply mode.