Service Statelessness

While autonomy may indeed be a well understood component of Information Technology, there is quite often less clarity when it comes to the constitution of state information. For this reason, we should take time out to define state management before going on to explore this particular principle.

The word “state” refers to something’s particular condition. A car moves in a state of motion; when the car is not moving, it can be said to be in a stationary state.

When it comes to Business automation, a software program has two states that tend to be associated with it. These are the active state and the passive state.

The active state symbolizes the software program that is being executed or invoked and thus enters in to a state of activity. The second state refers to when the program is not being used and thus is passive.

When programs are being designed, it is interesting for us to see what will happen when the program becomes active. It is so interesting, in fact, that designers have additional states that are applied to the program that are representative of particular types of active conditions.

In regards to the discussion of state management, two primary conditions can be evoked: they are stateless and stateful. Such terms are utilized as a means of identifying the runtime or active condition that a program is in as it can be related to the processing that is necessary for a particular task to be carried out.

When a particular task is being automated, the program may be required to process data that is specific to that particular task. This data may be referred to as “state information.”

A program might be active, but not necessarily engaged in the processing of state information. In such an idle situation, the program is thus considered as stateless. A program, on the other hand, that is actively engaged in the process of retaining or processing state information is considered to be stateful.

As processing demands on reusable services increase on a normal basis, so does the necessity for optimizing service processing logic. When engaged in the design of Service Oriented Architectures, extra attention should be paid to state management. Thus, the focus on streamlining state information management with architecture becomes emphasized to the extent that one should now have a principle that is dedicated exclusively to this aspect of service design.

That principle exists. It states that services should minimize the amount of state information that they manage, not to mention the duration for which they are stateful. In a service oriented solution, state information is typically representative of data that is particular to a service activity that is currently going on.

A service is temporarily stateful, for instance, when it is engaged in processing a message, as we can see in the diagram below. If a service is in charge of retaining state for a longer duration, then its capability of remaining available to other concurrent consumers will indeed become impeded.

Just as in autonomy, statelessness can be the preferred condition for services. It promotes both scalability and reusability. In order for a service to retain as little state as possible, then its underlying service logic has to be designed with stateless processing considerations in mind.

Moreover, the architecture must be equipped with state deferral extensions that are supportive of the application of this principle across a vast array of different services. This is why service autonomy is a key component in any Service Oriented Architecture.

First Page: Service Autonomy