Java EE勉強会

EIP / Composed Message Processor

Composed Message Processor †

ひとこと要約 †

複数のものから構成されるメッセージの処理は、Splitter、Content-Based Router、Aggregatorなどを組み合わせて使う。

要約 †

Content-Based RouterとSplitterで示した注文処理の例は注文を扱った。

それぞれの明細行は各々の在庫管理システムに在庫の確認を求め、検証後は有効な注文メッセージを次の処理ステップに回したい。

異なる処理が求められる複数の要素から成るメッセージを処理するときに、全体的なメッセージフローをどのように維持する？

この問題は複数のパターンの要素を含んでるようにみえる。

  • Splitterは複数のパートからなる単一のメッセージを分割できる。
  • Content-Based Routerはメッセージの内容やタイプに基いて個別のサブメッセージをルーティングできる。

WidgetとGadgetの例では、それぞれの明細は適した在庫管理システムにルーティングされる。

今のところ欠点と成るのは、注文されたすべての商品が在庫有りで出荷可能かどうかを判断できないこと。

  • すべての商品（ボリュームディスカウント適用）の価格を検索し、単一の請求書としてまとめる必要がある。
  • このことは、複数のサブメッセージに分割しながらも単一のメッセージのままであるかのように処理を続けることを要求する。

一つ目のアプローチは分離した注文として固有の在庫管理システムに送ったすべての明細を、再びまとめ上げるもの。

  • 注文が満たされ出荷できたら注文書が送られる。
  • 個々のサブオーダーは独立した処理として扱われる。
  • いくつかの例としては、下流のプロセス制御が不十分だとこのアプローチのみが適用出来る解決策となった。
  • Amazonの例
  • 注文は異なるフルフィルメント（商品の受注から引渡しまでの流れ）会社に回され、そこで管理される。

しかしながら、このアプローチはベストなカスタマー・エクスペリエンスを提供しない。

  • 顧客は複数の出荷と複数の請求書を受け取ることになる。
  • 返品やクレームの収拾も難しくなる。
  • 書籍を注文するのに顧客には大きな問題とはならないが、個々の注文明細がお互いに依存しあっていたら計算が難しいだろう。
  • 棚を作るのに家具の明細からなる注文を考えてみる。
  • 土台となるものが一時的に入手できなくて遅れて送られるといった時、顧客はそれ以外の家具が収められたいくつもの大きな箱を受けとりたくないはず。

メッセージングシステムの持つ非同期性がタスクの分割を同期的なメソッドコールに比べてより複雑なものにしている。

  • 個々の注文明細を処理して次の明細をチェックする前にレスポンスが来るのを待つことができる。
  • 一時的な依存性を簡素化するが、非常に効率の悪いものになる。
  • でも個々のシステムが複数の処理を一斉に取り扱う利益を得たい。

複合的なメッセージの処理にComposed Message Processorを使う。Composed Message Processorは、メッセージを分割し、サブメッセージを適切な場所へ配信し、返信されたものを単一のメッセージとして再び集約する。

DistributionAggregate.gif

Composed Message Processorは複数の在庫管理システムで処理されたリクエストを扱うのにAggregatorを使う。

  • それぞれのシステムはレスポンスメッセージをAggregatorに送る。
  • Aggregatorは個々のレスポンスを集め、定義済みのアルゴリズムに基いて処理する。
  • サブメッセージは単一のメッセージを元にしているので、サブメッセージの数などの情報を付与してAggregatorに送る。
  • 在庫管理システムが利用できない場合、そのシステムに含まれる商品を含むすべての注文の処理を遅らせたい？

このパターンは、どのようにいくつかの個別なパターンを一つの大きなパターンとして組み入れるかをデモンストレートしている。

  • Composed Message Processorは単一の入力チャネルと単一の出力チャネルを持つ単純なフィルターに見える。
  • より複雑な内部の処理を効果的に抽象化している。

Menu