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).
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).
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.