Home > State Management Explained > Measuring Service Statelessness

Measuring Service Statelessness

Using the state types and data we just established, we can define common categories to measure the level of a service capability's statelessness during its participation in a runtime activity. It is then the collective levels of the capabilities that determine the extent of a service's overall statelessness (Figure 1).

Measuring Service Statelessness: As with most serviceorientation design characteristics, measures of statelessness can exist at different levels within different service capabilities. RESTcompliance does not allow anything other than the full deferral of session state.

Figure 1 - As with most service-orientation design characteristics, measures of statelessness can exist at different levels within different service capabilities. REST-compliance does not allow anything other than the full deferral of session state.

The following are categories that can be used to label a service or any one of its capabilities in order to communicate its level of statelessness:

  • Non-Deferred State Management (low-to-no statelessness)
  • Partially Deferred Memory (reduced statefulness)
  • Partial Architectural State Management Deferral (moderate statelessness)
  • Full Architectural State Management Deferral (high statelessness)
  • Internally Deferred State Management (high statelessness)

The examples that supplement these sections are all based on the use of a database as the means of state management deferral, which is why they are not included in this appendix. When associated with REST, the most relevant category is that of Full Architectural State Management Deferral, whereby, service capabilities are designed to maximize statelessness by off-loading state data whenever possible (Figure 2).

Measuring Service Statelessness: The service with fully deferred state management maximizes its opportunities to exist in a stateless condition. Even when stateful, it defers state data when possible. Within a REST architecture, the state data repository would be substituted for the message layer for the deferral of session state data.

Figure 2 - The service with fully deferred state management maximizes its opportunities to exist in a stateless condition. Even when stateful, it defers state data when possible. Within a REST architecture, the state data repository would be substituted for the message layer for the deferral of session state data.