EIP/Claim Check - Java EE勉強会

Claim Check †

システムを流れるメッセージのデータ量を減らしつつ、情報の内容を犠牲にしないようにするにはどうすればよいか？

メッセージングは、サイズの大きいデータを転送するには非効率だ。メッセージングシステムによっては、メッセージサイズに上限を設けているものもある。
メッセージに含めるデータを少なくすると、途中のシステムが余計な情報に依存してしまうのを防ぐことにもなる。
Content Filterは余計なデータを削ってくれるが、後でそれをまた参照できることは保証してくれないので、完全なメッセージの中身をどこかに保存しておく必要がある。
メッセージのデータをどこかに保存しておく際には、後で参照するためのキーが必要だが、メッセージIDをキーにすると、連携の途中でメッセージIDが変わったときに困る。

メッセージデータを永続化ストアに保存すると共に、後続コンポーネントに「引換券（Claim Check）」を渡すようにせよ。後続コンポーネントは後でこの「引換券」を使ってデータを復元できる。

Claim Checkパターンの構成ステップ：
1. データを持ったメッセージ到着
2. Check Luggageコンポーネントが「引換券」となる一意キーを生成
3. Check Luggageコンポーネントがデータを永続化
4. Check Luggageコンポーネントがメッセージからデータを削除し「引換券」を付与
5. 別のコンポーネントがContent Enricherを使って「引換券」を基にデータを取得
このプロセスは、空港での荷物預かりと同様。
このパターンを使うことのメリット
- データの転送に非効率なメッセージングに比べ、効率的にデータを転送できる
- メッセージが一旦外部の複数コンポーネントへルーティングされて帰ってくるようなシナリオにも使える

データのキーをどうやって選ぶか？
1. メッセージ内に既存のビジネスキー（ex. 顧客ID）を使う
2. メッセージIDを使う
3. 一意なIDを生成する
既存のビジネスキーを再利用するのが最も手軽。例えば、メッセージに顧客情報が含まれていたときに、顧客IDだけを残す、など。キーの扱いを抽象化すれば、汎用的なデータ抽出メカニズムが利用できる。
メッセージIDを使うのはお勧めしない。メッセージIDに二重の意味が付与されることになり、後で問題を起こす可能性があるから。例えば、別のメッセージに「引換券」のキーを渡すときなど。
- データ参照の処理が1つのメッセージ内で閉じている場合のみ、使ってもよい。
データをいつまでデータストアに保持しておくか。
- データが参照されたら削除する。
- データに有効期限を付与して、GCプロセスに定期的に掃除させる。
- ずっとデータを保持しておく。（会計システムなど、実際のビジネスシステムをデータストア代わりに使う場合など）
データストアの実装方法：
- データベース
- XMLファイル
- インメモリメッセージストア
- アプリケーション

外部パーティへの重要データの秘匿という、大きなデータを扱う以外の目的にも利用できる。
外部パーティへはキーだけを渡して、外部パーティは必要に応じて情報を元のシステムに問い合わせるという形。毎回固有のキーを生成すれば、それ毎に外部パーティが実行できるアクションに制限を掛けることもできる（悪意のあるデータ参照を防ぐ、など）。

複数の外部パーティと連携するような場合、Process ManagerがClaim Checkとして機能することもできる。
Process Managerは処理メッセージ単位でプロセスインスタンスを作る。そのプロセスインスタンスに、付加情報を紐付けることもできるので、実質プロセスエンジンがデータストアの役割を担う。
こうすることで、Process Managerは外部パーティ毎に必要最小限のデータだけを送り、メッセージの完全なデータはプロセスエンジンが保持しておく、といったプロセスの制御が可能になる。