Service Statelessness principle is one of the most ambiguous among SO principles. Actually, it is not the fault of the principle definition but rather an inherited 'understanding' of similar concepts from other technologies. Additionally, the initial definition of the principle - 'services are stateless'- has contributed to this problem.
I assume that aforementioned definition was read similarly to the definitions of stateless and stateful EJB. That is, services should not maintain consumer state between service invocations. At that time, the explanation of the statement 'services are stateless', given by T. Erl, talked about different meaning: 'This principle states that services should minimize the amount of state information they manage, as well as the duration for which they remain stateful. ... state information usually represents data specific to a current service activity. While a service is processing a message, for example, it is temporarily stateful'. The words 'services should minimize the amount of state information they manage' unmistakably show that service may be as stateful as needed because minimum amount of state information does not necessary mean no state information.
It is obvious that statelessness supports scalability of a SO solution. However, we should not forget that scalability is not the absolute requirement in all cases in the life, it depends on particular business needs and used technique. For example, if service body is implemented using asynchronous communication with service's parts, i.e. it releases original invocation almost immediately or becomes available for another consumer right away, can we insist that service should not maintain the consumer state?
Back to 2006, T. Erl said: 'For a service to retain as little state as possible, its underlying service logic needs to be designed with stateless processing considerations', which is crystal clear. Why, in this case, wrapping legacy systems with 'services' (more accurately, with Web Services) was considered as SOA implementation? It is more than less likely that the legacy system is not stateless, i.e. such wrapping can barely comply with 'services are stateless'...
Contemporary definition of this principle states: 'Services minimize resource consumption by deferring the management of state information when necessary' declares that services may be stateful or stateless 'when necessary'. According to the SOA: Principles of Service Design (by T. Erl) book, 'There are different levels of statelessness a service design can achieve, depending on the frequency of state deferral and the quantity of state data being deferred. These levels are usually specific to each service capability.' While I certainly agree with this conclusion, I find the current name of the principle - Statelessness - rather misleading.
I think so because SO principles are not the principles of technology or technical design only. Nowadays tendency extends Service Orientation and shifts it from a pure technical mechanism into a business-oriented concept. In other words, SO design reaches its maximum value when and only when it models real business services and processes. In the business world, there are no many stateless business services, functions, features and processes. Following this logic, corresponding SO principle may not promote one state model over another model, it has to be agnostic to the model to become flexible enough to address actual business needs. Thus, the name 'Service State Management' for the SO principle, dealing with the service state model, seems to me more suitable for the task.
Leave a comment