SOAPatterns.org

Overview
- Introduction
- History
- Acknowledgements
- Podcasts
- Candidate Patterns
- Forms
- Press Releases
- Resources
Compound Patterns
Design Patterns (alphabetical)
Design Patterns (by category)
- Foundational Inventory Patterns
- Logical Inventory Layer Patterns
- Inventory Centralization Patterns
- Inventory Implementation Patterns
- Inventory Governance Patterns
- Foundational Service Patterns
- Service Implementation Patterns
- Service Security Patterns
- Service Contract Design Patterns
- Legacy Encapsulation Patterns
- Service Governance Patterns
- Capability Composition Patterns
  - Capability Composition
  - Capability Recomposition
- Service Messaging Patterns
- Composition Implementation Patterns
- Service Interaction Security Patterns
- Transformation Patterns
- REST-inspired Patterns
Cloud Computing Patterns
Service Technology Specs
SOA School
- Home
- Matrix
- Certifications
- Courses
- Exams
- Self-Study Kits
- Workshops
- Licensing
- Online Store

Home > Design Patterns > State Messaging

State Messaging (Karmarkar)

How can a service remain stateless while participating in stateful interactions?

Problem

When services are required to maintain state information in memory between message exchanges with consumers, their scalability can be comprised, and they can become a performance burden on the surrounding infrastructure.

Solution

Instead of retaining the state data in memory, its storage is temporarily delegated to messages.

Application

Depending on how this pattern is applied, both services and consumers may need to be designed to process message-based state data.

Impacts

This pattern may not be suitable for all forms of state data, and should messages be lost, any state information they carried may be lost as well.

Principles

Standardized Service Contract, Service Statelessness, Service Composability

Architecture

Composition, Service

State Messaging: Service A, acting as a service consumer, issues Request Message X to Service B (1). Service B creates the necessary data structures to maintain the necessary state and updates the data structures after processing this message. Service B then adds the state data to Response Message X, which it then returns back to Service A (2). Service A processes the response and then generates Request Message Y containing updated state data, which is then received and processed by Service B (3).

Service A, acting as a service consumer, issues Request Message X to Service B (1). Service B creates the necessary data structures to maintain the necessary state and updates the data structures after processing this message. Service B then adds the state data to Response Message X, which it then returns back to Service A (2). Service A processes the response and then generates Request Message Y containing updated state data, which is then received and processed by Service B (3).

Related Patterns in This Catalog

Asynchronous Queuing, Data Confidentiality, Data Origin Authentication, Messaging Metadata, Reliable Messaging, Service Agent, Service Instance Routing, State Repository

Related Service-Oriented Computing Goals

Increased Intrinsic Interoperability, Reduced IT Burden

This page contains excerpts from:

SOA Design Patterns by Thomas Erl

Foreword by Grady Booch

With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.

(ISBN: 0136135161, Hardcover, Full-Color, 400+ Illustrations, 865 pages)

For more information about this book, visit www.servicetechbooks.com.