SOA Patterns > Service Messaging Patterns > State Messaging
State Messaging (Karmarkar)
How can a service remain stateless while participating in stateful interactions?
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.
Instead of retaining the state data in memory, its storage is temporarily delegated to messages.
Depending on how this pattern is applied, both services and consumers may need to be designed to process message-based state data.
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.
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