7.8. Service statelessness

At first sight, services—and especially Web services—are completely stateless. That is, each invocation of a service operation is completely independent from any other invocation, be it by the same consumer or any other consumer. But once we start looking a little closer, it becomes clear that it is not that simple.

Many real-life business scenarios can be expressed as business processes that include a number of steps; some of them are automated (i.e., IT) steps, others may require manual intervention. Designing an implementation of such a process using service orientation (for example, by describing the process in BPEL) immediately requires that some state be maintained for the duration of the process. The process practically forms the notion of a “session” or “transaction” across multiple service invocations. Hence, a service implementing a business process is not stateless. Any BPEL execution environment will support maintaining state, either by storing it in the local heap of the thread executing the process, or even by storing it in a permanent, relational data store. The latter approach ensures that a process can be continued after a system crash or other interruption.