subbu.org

Carlos Perez at manageability.org posted an interesting discussion on OO-styled interactions, and I can’t agree more.

It is very common to find most people listing statelessness as one of the key principles of service API design. Statelessness is an overloaded term. To my experience, when someone says that a service is stateful, he/she usually means that the service maintains some internal state. We can argue all day long on whether maintaing state is good or bad - the answer usually depends on what the service is doing. In most cases, whether a service needs to maintain state or not is a service implementation choice - service users do not need to know or care about it.

From the client’s point of view, statefulness of a service usually implies that interactions with the service need to happen in some sequence to be meaningful, i.e. the client maintains some context with the service it is interacting with. Context is what a client should care about - not about whether the service is stateful or stateless.

Shared context makes service invocation interesting and meaningful. The service needs to define the context which may then be updated by the service or the client, and may even include references to any internal state maintained by the service itself. Services that don’t require any client-managed context are usually general-purpose utility services. Most usuful services need to depend on some share context to be useful. Context is what makes it possible to break a task into sub-tasks and let the client invoke sub-tasks in some defined sequence.

Some designers may prefer combining shared context with the inputs and outputs of service invocations. IMO, keeping the context separate from the data being processed and returned makes the service interface definition lot more cleaner, easier to understand, and extend. One problem with most programming models used for implementing services is that they don’t provide for shared context. For instance, take stateful EJBs. They are becoming extinct (rightly so) because they emphasize on the stateful nature and not on the shared context. With stateful EJBs, sharing the context meant that the client held onto the bean till the work is done. That is not the same as the shared context. Unfortunately, later layers like Java web services extended the same notion, and don’t provide for shared context within the supported programming models. You can easily bind a web service implementation to a class or a EJB, but you need to invent your own mechanisms for supporting shared context. Then there is the Web Servces Composite Application Framework, but I don’t think that is what service developers really want to worry about.

This also reminds me of The Need for Shared Context by Anne Thomas Manes, which argued for the need for defining a shared context.

Another harmful aspect OO-styled interactions that Carlos did not mention is idempotency. One of the problems with object-oriented development is that it is difficult to tell whether a given service invocation is idempotent or not.