|
History
|
|
Acknowledgements
|
|
Podcasts
|
|
Notification Form
|
|
Feedback Form
|
|
Press Release #1
|
|
Press Release #2
|
|
Press Release #3
|
Master SOA Design Pattern Catalog
|
|
|
Master Pattern List (alphabetical)
|
|
Master Pattern List (by category)
|
|
Master Pattern List (Text)
|
|
Pattern Notation
|
|
Pattern Profiles
|
|
Symbol Legend
|
|
Pattern Contribution Form
|
|
SOA Patterns Review Committee
|
|
Candidate Patterns Overview
|
|
Candidate Patterns List
|
|
Candidate Pattern Contribution Form
|
|
Candidate Pattern Feedback Form
|
|
SOA Pattern Template
|
|
What's a Design Pattern?
|
|
What's a Design Pattern Language?
|
|
What's a Compound Pattern?
|
|
SOA Patterns and Application Technologies
|
|
SOA Design Patterns Historical Influences
|
|
SOA Design Patterns and Design Principles
|
|
SOA Design Patterns and Design Granularity
|
|
Legal
|
|
Design Patterns Publications
|
|
Reference Posters
|
|
SOAPrinciples.com
|
|
WhatIsSOA.com
|
|
SOA Visio Stencil
|
|
|
Idempotent Capability (Candidate)
|
Home> Candidate Patterns List >Idempotent Capability
|
How can services recover from lost messages resulting from communication failures?
|
|
|
|
|
Problem
Network and server hardware failure can lead to lost messages, resulting in cases where a service consumer receives no response to its request. Attempts to reissue the request message can lead to unpredictable behavior within the service and the service consumer logic.
|
|
Solution
Design service capabilities capable of safely supporting repeated message exchanges.
|
|
Application
Idempotent capabilities guarantee that repeated invocations are safe and will have no negative effect. These types of capabilities are generally defined in terms of "set", "put" or "delete" actions that have a post-condition that does not depend on the original state of the service.
Idempotent capabilities that do request changes to service state can be safely retried and are generally limited to read-only data fetches or queries.
The design of an idempotent capability can include the use of a unique identifier with each request so that repeated requests that have already been processed will be discarded by the service rather than being processed again.
| |
|
|
Impacts
The use of a unique identifier to define an idempotent capability requires session state to be reliably recorded by the service and preserved across server hardware failures. This can harm the scalability of the service, and may be further complicated if redundant service implementations are operating at different sites that experience network failures.
Not all service capabilities can be idempotent. Unsafe capabilities included those that need to perform "increment", "reverse" or "escalate" transition functions where the post-execution condition is dependent upon the original state of the service.
|
|
|
Principles
Standardized Service Contract , Service Statelessness , Service Composability
|
|
|
|
Architecture
Inventory, Composition, Service
|
|
|
Status
Under Review
|
|
|
|
Contributors
Pautasso, Wilhelmsen
|
|
|
|
|
The getValue() and setValue() capabilities can be safely retried because they are idempotent. The incrementValue() capability is not idempotent and must not be retried unless each request is associated with a unique identifier. Such an identifier would need to be incorporated into the service's session state and must be synchronized between service instances alongside changes to the value.
|
|
|
Related Patterns in This Catalog
Reliable Messaging (Little, Rischbeck, Simon),
Reusable Contract (Balasubramanian, Carlyle, Pautasso) ,
Uniform Contract (Raj Balasubramanian, Jim Webber, Thomas Erl, David Booth)
|
|
|
Related Service-Oriented Computing Goals
Increased Organizational Agility,
Reduced IT Burden
|
|
This page contains excerpts from:
SOA with REST: Principles, Patterns & Constraints
by Raj Balasubramanian, Benjamin Carlyle, Thomas Erl, Cesare Pautasso
(ISBN: 0137012510, Hardcover, 400+ pages)
For more information about this book, visit www.soabooks.com.
|
|
|
Home
SOA Books
SOA Magazine
What is SOA?
SOA Principles
SOASchool.com
SOA Glossary
|
Copyright © 2007-2011 SOA Systems Inc.
|
gipoco.com
is neither affiliated with the authors of this page or responsible
for its contents. This is a safe-cache copy of the original web site.
gipoco.com
is neither affiliated with the authors of this page nor responsible
for its contents. This is a safe-cache copy of the original web site.
|