The Response Service
The programming model of queued calls described so far was one-sided: the client posted a one-way message to a queue, and the service processed that message. This model is sufficient when the queued operations are one-way calls by nature. However, the queued service may need to report back to its client on the result of the invocation, or return results or even errors. By default, this is not possible: WCF equates queued calls with one-way calls, which inherently forbids any such response. In addition, queued services (and their clients) are potentially disconnected. If a client posts a queued call to a disconnected service, by the time the service finally gets the message and processes it, there may no longer be a client to return the values to. The solution is to have the service report back to a client-provided queued service. I call such a service a response service. Figure 9-12 shows the architecture of such a solution.
Figure 9-12. A response service
The response service is just another queued service in the system. The response service may be disconnected toward the client as well, or it may share the client's process, or be hosted in a separate process or even on a separate machine. If the response service shares the client's process, when the client is launched the response service will start processing the queued responses. Having the response service ...