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
