Design Considerations for Web Service Implementation

The following factors should be considered when writing web service code.

• Atomicity: Web services should be atomic and adhere to an “All-or-Nothing” philosophy. In other words, they should guarantee that all tasks they direct complete successfully or are entirely reversed. Database transactions may be managed by the service itself or by lower-level domain layer entities (e.g., domain objects). If the service coordinates the work of these entities, it should always ensure that data is left in a valid state by instructing the entities to commit or abort at the appropriate times.

• State management: Stateful web services allocate server memory for each client session. These services save information from individual client requests to session variables that can be accessed in subsequent requests. This enables clients to use web services as if they were stateful local objects, and can also help to reduce database load if the data kept in the session variables would have normally been retrieved from a database. Unfortunately, as the web server load increases, the memory needed to support stateful web services usually increases as well. If too much memory is consumed, then data may be swapped from memory to disk, thereby hurting server performance. In the worst-case scenario, a server fault may occur.

  The use of stateful web services can cause other scalability problems as well. Client requests may have to be sent back to the server where the client’s session was established unless an alternative mechanism for state management is used. Client state could, for example, be stored in a distributed memory cache that is accessible to all web servers. It could also be written to a file system or database. Both approaches, however, require additional out-of-process calls which may add to the overall response time. Access of information held in distributed memory caches can be very fast, but data may be lost upon a crash. Information stored in a file system or database can usually survive a server crash, but the data retrieval time may lag.

  These are just a few of the reasons why many create stateless web services. With this approach, any server memory allocated for clients is released at the end of each request. Since requests may be sent to any web server, and temporary client data is rarely held in distributed state management infrastructures, it becomes much easier to balance client load across a clustered web server tier and scale the overall system. However, since the server does not store data from previous requests, the size of each request tends to increase, and this may cause network utilization to increase as well. The web service may also have to retrieve more data from the database on each request since nothing is saved in memory from prior requests.

  For a more in-depth discussion of session state, I recommend Patterns of Enterprise Application Architecture [POEAA] and Architectural Styles and the Design of Network-based Software Architectures [Fielding].

• Service composition: Consistent and reliable outcomes are more likely when the web service controls its own execution and has few dependencies on outside forces. One may certainly create complex web services that call other web services, but the ramifications must be carefully considered. First is the problem of network latency. The overall response time of a web service that calls other web services may be unacceptable for certain situations. The service designer must also think about network and server failures. If a subordinate service is unavailable, then what should the parent service do? Should the parent make multiple attempts to connect to the service? Should the parent fail if a subordinate fails? If the parent decides to fail, it may need to instruct its subordinates to undo any work that they completed prior to the failure. How should it do this? The service designer must also consider whether or not the client should be kept waiting as all of this transpires. These are just a few of the questions that must be answered when building composite services.