Scatter-Gather †
サマリ †
ばら撒いて(scatter)集める(gather)という比較的使われるシナリオを、1つのコンポーネントとしてまとめてパターン化しよう、というもの。
詳細 †
- これまでの注文処理サンプルでは在庫の無い各注文アイテムは複数の外部サプライヤの中から発注先を選ぶことができたが、サプライヤによって、在庫の有無、価格の違い、納期などにばらつきがある。
- こうした注文処理を最適化するには、すべてのサプライヤに見積り要求を出して、最善のものを選ぶようにする必要がある。
複数の受信先へメッセージを送って、その受信先が返信するか分からないような場合、どのように全体のメッセージフローを管理すればよいか?
- ソリューションとしては、受信先の決定に柔軟性を許容する必要がある(中央集権的に管理するのか、誰でも競売に参加できるようにするのか)。外部受信先を制御する権限はないので、受信先が返信しないことも想定しなければいけない。
- ソリューションとしては、この競売方式の詳細を後続の処理から隠蔽/カプセル化する必要もある。
- また、後続のメッセージフローを調整する必要もある。受信先毎に返信用チャネルを用意するような単純なやり方だと、上記のカプセル化を実現できない。
- したがって、ルーティングロジック、受信先、返信メッセージの後処理を論理的にひとまとまりのコンポーネントにするのが理に適っている。
種蒔き−収穫(Scatter-Gather)を用いて、複数の受信先にメッセージをブロードキャストし、返信を1つのメッセージに再集約せよ。
他のパターンとの関係 †
例:Loan Broker †
例:パターンの結合 †
- ウィジェット&ガジェットの注文処理サンプルをScatter-Gatherで実装する。
- Scatter-GatherとComposed Message Processorを組み合わせる。まず入ってきた注文を個別の注文アイテムに分割して、そのアイテム毎に競売を掛けてそれぞれ最善の結果を集計、最後にそれをまとめて1つの見積りにする。
- EIPを活用したとてもリアルな例。こうすると、高い抽象度でソリューションを議論したり、他のコンポーネントに影響を与えずに実装の詳細を修正したりできる。
- この例は、Aggregatorの汎用性も示している。1つ目のAggregatorは競売結果を集計する複雑なアルゴリズムを実装している。一方で、2つ目は、単に全部を集計するという単純なロジックだが、すべての結果が集計できなかったときのエラー処理を実装しなければいけない。
担当者のつぶやき †
みんなの突っ込み †