Programming WCF Services, 3rd Edition

Disconnected Services and Clients

The previous chapters were all predicated on a connected interaction between the client and the service, where both sides must be up and running to be able to interact with each other. However, there are quite a few cases (as well as the overall business model justification) for wanting to have disconnected interaction in a service-oriented application:

Availability

The client may need to work against the service even when the client is disconnected; for example, when using a mobile device. The solution is to queue up requests against a local queue and send them to the service when the client is connected. Similarly, if the service is offline (perhaps because of network problems or machine crashes), you want clients to be able to continue working against the service. When the service is connected again, it can retrieve the pending calls from a queue. Even when both the client and the service are alive and running, network connectivity may be unavailable, and yet both the client and the service may want to continue with their work. Using queues at both ends will facilitate that.

Disjoint work

Whenever it is possible to decompose a business workflow into several operations that are separated in time—that is, where each operation must take place, but not necessarily immediately or in a particular order—it is usually a good idea to use queuing, because it will improve availability and throughput. You can queue up the operations and have them execute independently ...