Stateful Web Services

While back end code tends to prefer coarse grained interaction, front end user interfaces prefer fine-grained interaction. The reasons are:

• Data validation
• Capability validation

disabling buttons that user doesn’t have rights to, rather than throw exception at the end when user tries to commit the operation

• Long forms

There are times when user interaction need to be broken down into a sequence.

This presents a common dilemma to those designing the appropriate SOA interface. The options are to either use some kind of session (similar to HTTP Sessions), or turn the service into a Corba-style object, where the client manipulates a live-object over several interactions.

A good style that I have observed is with Web Mail interfaces. Attaching documents to a webmail requires a temporary creation of a resource on the server. The browser client proceeds to keep on interacting with the temporary resource, but nothing is committed to the SMTP back-end. In this case:

1. statefulness is a necessary evil, but it is mitigated by the service providing a fool-proof interaction sequence.
2. there is no guarantee of two-phase commit. The final “Send” operation still works as a coarsed grained interaction with the back-end.
3. since the back end interacts only with the resource located at the server itself, there is no network bottleneck
4. in addition, one doesn’t have to worry about the client doing the equivalent of hitting the submit button twice, i.e. reliable HTTP
5. the resource can have a limited lifetime, i.e. a lease, and can be cleaned up if the user has not committed it by the time the lease expires