Message-Based State Deferral
How can session state be deferred without incurring service-side storage or coordination overhead, and while remaining loosely coupled with service consumers?
Despite the best efforts of architects, service compositions can generate session state that needs to be retained by a service between separate capability invocations. In these cases, state deferral is an important design consideration. Services often seek to defer state to a state database or a dedicated state management service in order to avoid retaining it in memory. However, state databases and services can be costly, can be difficult to distribute effectively over multiple data centers, and can complicate failure modes and load balancing scenarios across server clusters.
Services conform where possible to the principle of stateless design. Services defer state back to the service consumer whenever session state is required.
Complete session state is included in the response message of any invoked capability. The service consumer subsequently includes the complete session state as part of later request messages.
Service scalability is improved, as is the ability to take individual servers off-line for maintenance without impacting overall service availability. Communication and coordination overheads are reduced between components of the service.
Additional bandwidth is required to transfer state back and forth between services and consumers. This may impact the overall performance.
Clients must be capable of storing deferred session state.
Session state may be lost, corrupted, or deliberately modified by the service consumer, leading to unpredictable application behavior. Security or consistency may be compromised if sensitive state is transferred back to service consumers.
ContributorsRaj Balasubramanian, Benjamin Carlyle, Cesare Pautasso
Session state used to trace through several capability invocations can be returned to the service consumer between requests.
Session state can be incorporated into endpoint identifiers when combined with the fine-grained service endpoint, entity linking and uniform contract patterns. This novel container for session state information can be easily stored and handled by service consumers due to its standard syntax. When the service consumer invokes the capability of the session-inclusive service endpoint, the session information attached acts as a message from the service to itself. The service does not have to remember the session state, but can parse the service endpoint identifier to extract the information it requires. The endpoint identifier effectively refers to a new conceptual entity: The basic underlying conceptual entity as viewed from the perspective of the service consumer's session.