SOA Patterns | Design Patterns | Idempotent Capability


SOA Patterns > REST-inspired Patterns > Idempotent Capability
Home > Design Patterns > Idempotent Capability

Idempotent Capability (Wilhelmsen, Pautasso)

How can a service capability safely accept multiple copies of the same message to handle communication failure?

Idempotent Capability

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 or undesirable behavior when the service capability inadvertently receives multiple copies of the same request message.

Solution

Design service capabilities with idempotent logic that enables them to safely accept repeated message exchanges.

Application

Idempotency guarantees that repeated invocations of a service capability are safe and will have no negative effect.

Idempotent capabilities are generally limited to read-only data retrieval and queries. For capabilities that do request changes to service state, their logic is generally based on “set”, “put” or “delete” actions that have a post-condition that does not depend on the original state of the service.

The design of an idempotent capability can include the use of a unique identifier with each request so that repeated requests (with the same identifier value) that have already been processed will be discarded or ignored by the service capability, 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. Potentially unsafe capabilities include 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.

Architecture

Inventory, Composition, Service

SOA with REST: Principles, Patterns & Constraints

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.arcitura.com/books.