EIP
Canonical Data Model †
一言要約 †
要約 †
- メッセージング（53）を通じていくつかのアプリケーションが協調動作するように設計している。各アプリケーションにはそれぞれ内部データフォーマットがある。
- 別々のデータフォーマットを用いるアプリケーションを統合する場合、どうすれば依存関係を最小化できるだろうか？
- 独立して開発されたアプリケーションは、別々のデータフォーマットを使う傾向にある。各フォーマットはそれぞれのアプリケーションを念頭に作られるからだ。あるアプリケーションが別の知らないアプリケーションとメッセージの送受信をするよう設計されている場合、そのアプリケーションは自分にとって最も便利なメッセージフォーマットを使うことになる。
- メッセージ・トランスレーター（85）は、アプリケーションに変更を加えることなくメッセージフォーマットの差異を解決したり、各データフォーマットについてアプリケーションに知らせたりする。しかし、大量のアプリケーションが、互いに通信していると、各アプリケーションのペアに対してメッセージトランスレーターが必要になる。
- それでは、メッセージトランスレーターの数が膨大になってしまう。各アプリケーションが複数のメッセージ型を送受信する場合には特にそうだ。
- メッセージトランスレーターにより、二つのアプリケーションの方向性を無視できるようになるが、各アプリケーションによって使われるメッセージ形式には依存している。その結果、あるアプリケーションのデータフォーマットがかわると、そのアプリケーションに関連するすべてのメッセージトランスレーターを変更しなければならなくなる。同様に、新しいアプリケーションが加わった場合も、既存のアプリケーションとの間でメッセージトランスレーターを作らなければならない。
- 同様に、メッセージフローに差し込まれる追加の変換処理により、レイテンシーが増加し、メッセージのスループットが減少する。
- 特定のアプリケーションから独立した、カノニカルデータモデルを設計しよう。各アプリケーションに対して、共通のデータフォーマットでメッセージを送受信するよう求めよう。
- カノニカルデータモデルを使うと、アプリケーション個々のデータフォーマットの間に新しく間接的な層が追加される。新しいアプリケーションが、統合ソリューションに追加された場合、既に参加している他のアプリケーションがあっても、カノニカルデータモデルとの変換だけをすればよい。
- カノニカルデータモデルの利用は、アプリケーションの数が少ない場合には過度に複雑になってしまうように見えるかもしれない。しかし、アプリケーションの数が増えるにしたがって、このソリューションは割に合うようになる。
- カノニカルデータモデルは、既存のアプリケーションが将来別のアプリケーションと置き換えられる可能性がある場合には、非常に役に立つ。
変換の選択肢 †
- アプリケーションを共通のフォーマットに順応させるためには、基本的な選択肢が３つある
- アプリケーションの内部データフォーマットを変更する：理論的には可能だが現実的ではない（それなら、メッセージングよりは共通データベースを使った方がいい）
- アプリケーション内部にメッセージマッパー（477）を実装する：望ましいデータフォーマットを生成するために、このマッパーを使う
- 外部のメッセージトランスレーターを使う：アプリケーションに固有のメッセージから、カノニカルデータモデルによって定義されたフォーマットに変換する。
- メッセージングマッパーを使うか、外部のメッセージトランスレーターを使うかは、変換の複雑さとアプリケーションの保守性とに依存する。パッケージ化されたアプリケーションでは、メッセージングマッパーが使えないことが多い。ソースコードが手に入らないからだ。カスタムアプリケーションでどれを選ぶかは、変換がどのくらい複雑かによる。ビジュアルなツールが提供されていることもあるが、変換が複雑だとうまくいかなくなる
- 外部のメッセージトランスレーターを使う場合、パブリック（カノニカル）なメッセージと、プライベート（アプリケーション固有）なメッセージとを区別しなければならない。カノニカルデータモデルに従ったメッセージはパブリックだと考えられる
二重の変換（Double Translation） †
- カノニカルデータモデルを使うと、メッセージフローにある程度のオーバーヘッドがかかることになる。各アプリケーションで変換が二回（送信元から共通／共通から送信先）必要になるからだ。そのため、カノニカルデータモデルの利用は、二重の変換と呼ばれることもある。したがって、パフォーマンスが重要なアプリケーションでは、避けられることもある。
カノニカルデータモデルの設計 †
- カノニカルデータモデルの設計は難しい場合もある。たいていの企業は、少なくとも一度は「エンタープライズデータモデル」の策定に失敗している。バランスの取れたモデルを作るためには、統合されるアプリケーションに平等な統一モデルを考えなければならないが、容易ではない。カノニカルデータモデルをうまく設計するためには、カノニカルデータモデルは、アプリケーション内部で使われるデータをすべてモデル化しなければならないわけではなく、メッセージングに参加するアプリケーションの一部でよいと考えるとよい。
- カノニカルデータモデルを使うことには、政治的な長所もある。カノニカルデータモデルを使えば、開発者とビジネス側のユーザーが、統合ソリューションについて、企業のビジネスドメインの観点から議論できる。カノニカルデータモデルを定義することは、アプリケーション間のセマンティック上の不調和を解決するための最初のステップでもある。
データフォーマットの依存関係 †
- 本パターンの最初に示した絵（変更がたくさん必要になる様子を現したもの）は、メッセージブローカー（322）で表現した絵と似通っている。アプリケーションの依存関係は複数のレベルにわたるのだ。メッセージチャネルを使うと、アプリケーション間に変換レイヤを設け、個々の変換プロトコルとの間の依存関係を取り除く。メッセージルーターを使うと、場所に依存しなくなるので、送信側アプリケーションは受信側アプリケーションの場所を意識しなくて良くなる。XMLのような共通データフォーマットを使うと、アプリケーションに固有なデータ型への依存関係はなくなる。最後に、カノニカルデータモデルを使うと、データフォーマットへの依存関係やアプリケーションが使うセマンティクスが解決される。
- 例に漏れず、常に変化は訪れる。それゆえ、カノニカルデータモデルに適合したメッセージは、フォーマット識別子を定義しなければならない。
担当者のコメント †
みんなの突っ込み †
