Requirements Modelling and Specification for Service Oriented Architecture

2.5. Stateless Services

As we saw in Chapter 1, services are usually regarded as 'stateless'. An object, service, system or protocol is said to be stateless if it does not keep a persistent state between transactions. Services that do have this property are called stative^[]. It is a axiom of the architectural vision or rationale of SOA that all services should be stateless.

^[] I refuse to use the utterly barbarous 'stateful' since there is already a perfectly good word in existence and which anyway means something quite different - according to the OED: full of state or dignity, stately.

A stateless service treats each message as an independent transaction that is unrelated to any previous request. For example, a web server is stateless because processes requests to display pages require neither any context nor any memory of previous requests. Contrast this with an FTP server conducting an interactive session with a user; a request to the server for a file might assume that this user has been authenticated and that the current directory and file transfer mode have been set, requiring a remembrance of things past.

Statelessness helps ensure loose coupling and reusability. Statelessness also simplifies service design; services do not need to allocate memory dynamically to deal with conversations in progress or worry about freeing it if a client crashes mid-transaction.

The main disadvantage of statelessness is that it may be necessary to include more information in messages. This ...