Section 9.1. Disconnected Services and Clients


9.1. 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, thatis, where each operation must take place, but not necessarily immediately or in a particular orderit 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 of each other.


Compensating work

When your business transaction may take hours or days to complete, you typically split it into at least two transactions. The first queues up the work to be completed immediately, and the second verifies the success of the first and compensates for its failure if necessary.


Load leveling

Load is usually defined as the number of outstanding clients, while stress is the number of concurrent calls. If you have a large load, unfettered, it will translate into direct stress on your system. Most systems do not have a constant level of load or stress, as shown in Figure 9-1. If you design the system for the peak load, you will be wasting system resources through most of the load cycle. If you design a system to handle the average load, you will not be able to handle the peak. In a similar manner, you need to examine not just the absolute load level, but also the rate of increase of the load (its first derivative). A sudden spike in load, even if it does not max out your system ability in absolute terms, may still be more than what your system is capable of handling in a timely manner, so responsiveness will be inadequate. With queued calls, the service can simply queue up the excess load and process it at leisure. This enables you to design a system for a nominal average of the desired throughput, as opposed to the maximum load.

Figure 9-1. Fluctuating load





Programming WCF Services
Programming WCF Services
ISBN: 0596526997
EAN: 2147483647
Year: 2004
Pages: 148
Authors: Juval Lowy

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net