EIP
メッセージバス †
一言要約 †
要約 †
- 企業が有する既存システムの中には、データを共有し、共通の業務的要求に応じて統一されたやり方で処理しなければならないものもある
別々のアプリケーションが一緒に動かなければならない一方で、個別に増やしたり減らしたりできるように疎結合にしておかなければならない。どんなアーキテクチャにすればいいだろう？
- 企業が抱える様々なアプリケーションの中には、独立して操作するが協調して統一的に動かなければならないものもある。EAIはこの問題に対するソリューションを提示するが、実際にはどうすればよいのだろう？
- たとえば、保険会社が色々な種類の保険商品を売ろうとしているとする（生命保険、健康保険、自動車保険、住宅保険などなど）。企業統合の結果、様々な商品を管理するために個別のアプリケーションがある。しかし、ある顧客に色々な商品を売るためにバラバラのシステムにログインするのは手間がかかるし、間違いも増えそうだ。
- エージェントには、顧客に方針のポートフォリオを売るための統一されたアプリケーションが必要だ。また、クレーム対応係や顧客サービス担当者は、保険商品と連動するアプリケーションが必要だが、統一されたビューがほしい。
- 商品用アプリケーションを同じ技術を使って協調動作するように書き直してもいいが、既に動いているシステムを置き換えるためかかる時間とお金を考えるとやる気にならない。また、エージェント用の統合アプリケーションを作ってもいいが、このアプリケーションは実際にポリシーを管理しているアプリケーションにつながなければならない。他と統合しないアプリケーションがひとつ増えるだけのようだ。
- これらのシステムをすべて統合するアプリを作ることもできるが、それはそれで大変だ。
- 仮にすべてのアプリケーションを協調動作させようとしたところで、どれかに変更が入るとすべてに影響が出てきてします。つまり、協調動作はするけど、疎結合にしておかなければならないのだ。
これらのアプリケーションの間をつなぐミドルウェアをメッセージバスとして構成し、メッセージングを使って協調動作できるようにしよう。
- メッセージバスは、標準データモデル（355）の組み合わせだ。コンピュータシステム内のコミュニケーションバスに似ている。メッセージバスの構成要素を以下に挙げる。
- 共通のコミュニケーションインフラ - メッセージングシステムは、物理的なコミュニケーションインフラとなり、アプリケーション間でプラットフォームや言語をまたがる汎用アダプタを提供する。
- アダプタ - 様々なシステムがメッセージングバスとやりとりするインターフェイスを必要とする。アプリケーションによってはメッセージバスに自分でつなげるものもあるが、アダプタが必要なものもある。
- 共通のコマンド構造 - メッセージバスの参加者すべてが理解できる共通のコマンドが必要だ。
- 保険会社EAIの例では、メッセージバスが様々なシステム間の汎用コネクタとして、またクライアントアプリケーションのための汎用インターフェイスとして機能する。
- メッセージバスしか知らないGUIがふたつある。このGUIは後ろにあるシステムの複雑さをまったく意識しない。メッセージバスはコマンドメッセージを適切なシステムにルーティングする責務がある。コマンドメッセージを扱う場合、コマンドを解釈するアダプタを作った方が良い場合もあるし、直接コマンド処理をアプリケーションに埋め込んでよい場合もある。
- エージェントGUI用にメッセ―ジバスを開発すれば、他のGUIで再利用するのも簡単
- メッセージバスはシンプルで役立つサービス指向アーキテクチャを形作る。各サービスはリクエストを受けつけるチャネルを少なくともひとつ持つ。また、レスポンスを返すチャネルを持っている場合もある。サービスのクライアントはリクエストを送ってレスポンスを待てばよい。
- メッセージバスでは、バスを使うアプリケーションがすべて同じ標準データモデル（355）を使わなければならない。
