Disconnected Services and Clients
The previous chapters were all predicated on a connected interaction between the client and the service where both sides must to be up and running to be able to interact with each other. However, there are quite a few cases (as well as 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. Much the same way, the service may be offline, perhaps because of network problems. You want to enable clients to continue working against the service even in such a case. 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, the 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 (potentially even transactional) 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 ...