EIP / Content Filter

Content Filter †

一言要約 †

複雑なメッセージの一部分だけが必要なのだったら、フィルターで絞り込んでみよう。

Context †

実際のメッセージよりももっと多くの要素を受け手側が求めていることがあって、そんなときに使えるのがContent Enricherだった。 驚くなかれ、時にはその正反対のことが求められる場合もあるのですよ。

Problem †

大きなメッセージの中で、実際に使いたいのはごく一部の要素だという場合はどうすればいい？

Force †

あるサービスにデータをリクエストするアプリがあったとして、そのサービスからのレスポンスに含まれるデータの中には (権限的な意味で)そのアプリが見ないほうがいいものが含まれているかもしれない。 セキュリティとかあまり気にしないサービスの場合、誰がリクエストしたのかにかかわらず同じ形式のメッセージを返すことがある。

また、それとは別に、メッセージのハンドリングを単純化したいとかネットワークのトラフィックを軽減したいとかいう要件も考えられる。 どこかの団体とか何とか委員会とかが策定したいわゆる『業界標準XMLフォーマット』ってやつは、たいていばかでかいものになる。 何百もの項目もあって、何段階にもネストしているとか。 それを内部的なメッセージ交換に使うのは無駄が多いし、デバッグもたいへん。

入力ドキュメントを単純化して、内部処理で実際に使う項目だけにしてしまうステップが欲しくなる。

そこで…

Solution †

Content Filterを使って、重要でない項目をメッセージから削除する。そして、重要な項目だけを残す。

重要な項目を除去するだけでなく、メッセージの構造を単純化するにも便利に使える。 外部システムやパッケージソフトからやってくるデータは、多段ネストや繰り返しが含まれることが多い（正規化されたRDBのデータに由来することが多いから）。 Content Filterを使えば、無駄な階層構造をときほぐして「平坦化」できる。

複数のContent Filterを静的なSplitterとして使えば、複雑なメッセージの各部分を個別に扱える。

Examples †

データベースアダプタ †

たいていのインテグレーションスイート製品には、既存システムとのチャネルアダプタが用意されている。 それを使って、こんなスキーマのデータベースと接続することを考えてみよう。

商用製品のデータベースアダプタは、この手の正規化されたスキーマを階層構造で管理することが多い。 Content Filterを使えば、このメッセージを単純化できる。次の図は、GUIツールでContent Filterを実装した例。

ただ、この例については、Content Filterが唯一の解だというわけではない。データベースのビュー機能を使ったほうがよっぽどすっきりするだろう。

でも、えんたーぷらいずな世界だと、そんな気安くビューを作れないかもしれない。「ビュー禁止！」とかいう場合さえあるかもね。

担当者のつぶやき †

特に引っかかることもなく「ああ、そうですよねえ」という感じでした（高木）

みんなの突っ込み †