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)
|
|
|
Idempotent Capability (candidate)
|
Home > Candidate Patterns List > Idempotent Capability
|
|
How can a service consumers recover from lost messages after network disruption or server failure within a service cluster?
|
|
|
|
|
Problem
Despite best engineering practice, networks remain a weak point in distributed communication. Service may be disrupted, and messages lost. Server hardware is also prone to failure. These failures may occur during service capability invocation. A consumer sends a request message, but subsequently receives no response. Without a response message, the consumer cannot determine whether the request was lost or only the response was lost. A lost request should be retried, but a lost response may cause unintended side-effects if retried automatically.
|
|
|
Solution
Guarantee that capability invocations are safe to repeat in the case of network or server failure modes that could lead to a response being lost.
|
|
|
Application
Capabilities are labeled as "safe", "idempotent", or "unsafe".
Safe capabilities do not request changes to service state, and can always be safely retried from a service consumer perspective. Safe capabilities are generally read-only data fetches or queries only.
Idempotent capabilities guarantee that subsequent repeated invocation will have no effect. Idempotent capabilities are generally defined in terms of "set", "put" or "delete" operations that have a post-condition that does not depend on the starting state of the service.
Idempotent capabilities can also be defined by providing a unique identifier with each request. Repeated attempts at requests that have already been processed will be discarded by the service rather than being processed again.
Unsafe capabilities are often defined in terms of "increment", "reverse" or "escalate" transition operations whose post-condition depends on the starting state of the service.
Service consumers automatically retry safe and idempotent requests. Unsafe requests are only retried if explicitly requested by an end user.
|
|
|
|
Impacts
The use of a unique identifier to define an idempotent capability requires session state to be reliably recorded by the service even across server hardware failures. This can harm the scalability of the service.
|
|
|
|
|
|
|
|
Status
Under Review
|
|
|
|
Contributors
Herbjorn Wilhelmsen, Cesare Pautasso
|
|
|
|
| |
Even highly-available network and server configurations fail, or fail over. Safe and Idempotent methods can be safely retried after network or server failure, and also after a server is shut down for maintenance purposes.
Failure of a network path may take time to resolve, leading to message loss. Failure of a service instance can similarly lead to a request being completely processed or rolled back without returning a response message.
The Service Consumer is able to safely retry the getValue() request. Issuing setValue() multiple times will have no unintended side-effects. It is idempotent and can also be safely retried. The incrementValue() capability must not be retried unless each request is associated with a unique identifier. The identifier is incorporated into the service's session state must be synchronized between service instances alongside changes to the value.
|
| |
|
|
