複数のものから構成されるメッセージの処理は、Splitter、Content-Based Router、Aggregatorなどを組み合わせて使う。
Content-Based RouterとSplitterで示した注文処理の例は注文を扱った。
それぞれの明細行は各々の在庫管理システムに在庫の確認を求め、検証後は有効な注文メッセージを次の処理ステップに回したい。
異なる処理が求められる複数の要素から成るメッセージを処理するときに、全体的なメッセージフローをどのように維持する?
この問題は複数のパターンの要素を含んでるようにみえる。
WidgetとGadgetの例では、それぞれの明細は適した在庫管理システムにルーティングされる。
今のところ欠点と成るのは、注文されたすべての商品が在庫有りで出荷可能かどうかを判断できないこと。
一つ目のアプローチは分離した注文として固有の在庫管理システムに送ったすべての明細を、再びまとめ上げるもの。
しかしながら、このアプローチはベストなカスタマー・エクスペリエンスを提供しない。
メッセージングシステムの持つ非同期性がタスクの分割を同期的なメソッドコールに比べてより複雑なものにしている。
複合的なメッセージの処理にComposed Message Processorを使う。Composed Message Processorは、メッセージを分割し、サブメッセージを適切な場所へ配信し、返信されたものを単一のメッセージとして再び集約する。
Composed Message Processorは複数の在庫管理システムで処理されたリクエストを扱うのにAggregatorを使う。
このパターンは、どのようにいくつかの個別なパターンを一つの大きなパターンとして組み入れるかをデモンストレートしている。