Enterprise Integration PatternsConversation Patterns
HOME    PATTERNS    RAMBLINGS    ARTICLES    TALKS    DOWNLOAD    BOOKS    CONTACT

Incremental State Build-up

Conversation Patterns

Previous Previous   Next Next

Stuttering

A participant transmits information to a conversation partner.

How can a participant invoke an operation when the it does not have all required information available at the same time?

  • The initiator could store data locally until all elements are present, which requires it to hold local state. The client may be be desired to be stateless or unreliable, which makes holding local state difficult.
  • The data set may be very large and exceed the message size allowed by the system or a practical limit. In this case, the initiator may consider using a Claim Check if the system provides such a service.

The requestor transmits information incrementally until it is ready to execute the operation.

The Incremental State Build-up conversation involves the following participants:

  • The Requestor transmits data via multiple Data messages and finally invokes the Operation. Invoking the operation may coincide with the last data message (implicit invocation) or via a separate message (explicit invocation).
  • The Provider accepts a sequence of Data messages and collects the state contained in them. When it receives the final Data message or an Operation message it invokes an operation based on the collected data.

Incremental State Build-up requires the provider to allocate resources for the convenience of the consumer. It should therefore employ resource management, such as a Lease. After the invocation of the operation the Provider may immediately release the collected data or keep it for subsequent operations. If it keeps the data, the need for a Lease increases.

The incremental transmission can occur in two "flavors":

  • Building a large data set, i.e. transmitting sections of the same type of data. In this case the number of Data messages is typically not limited.
  • Building a complex structure, i.e. transmitting different data types. In this case, each message tends to transmit a different element of the structure. thus the number of Data messages is limited, but it does not have to be fixed as some elements may be optional.

Incremental State Build-up introduces a strong form of coupling and chatty network traffic. Because it is stateful, it also requires "stickiness", i.e. the initiator always has to talk to the same provider instance unless the state is explicitly shared across providers. This limits scalability. Incremental State Build-upshould therefore be used with caution. In some cases the finer granularity of the incremental requests can aid reuse if each request relates to a different business entity.

Related patterns: Lease, Claim Check



Introduction
Overview
Preface
Table of Contents
Introduction
Describing Conversations
Choreography
Orchestration
Hypermedia State
Conversation Vocabulary
Discovery
Dynamic Discovery
Advertise Availability
Consult Directory
Referral
Leader Election
Starting a Conversation
Three-Way Hand Shake
Acquire Token First
Rotate Tokens
Verify Identity
User Grants Access
Basic Conversations
Fire-and-Forget
Asynchronous Request-Response
Request-Response with Retry
Polling
Subscribe-Notify
Quick Acknowledgment
Intermediaries
Proxy
Relay
Load Balancer
Scatter-Gather
Managing Distributed Systems
Heartbeat
Resource Management
Incremental State Build-up
Lease
Renewal Reminder
Ensuring Consistency
Ignore Error
Compensating Action
Tentative Operation
Coordinated Agreement
Appendices
Bibliography