Skip to content
Software Architecture Guide

Composed Message Processor

Explanation

Section titled “Explanation”

Some messages carry several elements, and those elements may need different handling. The Composed Message Processor pattern addresses this problem: how to keep the overall message flow intact while the elements are processed.

The gathering step relies on the Aggregator pattern. An Aggregator is a special kind of filter. It receives a stream of messages and works out which ones belong together.

The Aggregator needs a completeness condition. This rule decides when enough replies have arrived to publish the combined result.

A related pattern is Scatter-Gather. It broadcasts a message to several recipients and merges their responses back into one message. The pattern catalog lists Composed Message Processor as related to it. See also the articles on Scatter/Gather, Content-based Router and Correlation Identifier.

Example

Section titled “Example”

An order contains several items. Each item needs a different check before the order can be confirmed. The system collects the individual results and publishes one combined answer. It does this once its completeness rule says all results are in.

Trade-offs

Section titled “Trade-offs”

Waiting for all parts has a cost. A single missing or delayed reply blocks the whole aggregate, so further processing stops. Plan for this partial-failure risk when you define the completeness condition.

Checks

Section titled “Checks”
  • The document states the completeness condition that tells the Aggregator when to publish the combined result.
  • The document says what happens when one reply is missing or delayed, since that blocks the whole aggregate.
Section titled “Related”

Sources

Section titled “Sources”