Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
Message-Based State Deferral (candidate)
|
Home > Candidate Patterns List > 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?
|
|
|
|
|
|
Problem
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.
|
|
|
Solution
Services conform where possible to the principle of stateless design. Services defer state back to the service consumer whenever session state is required.
|
|
|
Application
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.
|
|
|
|
Impacts
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.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Balasubramanian, Carlyle, 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.
|
|
|
