|
||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
| レベル2 | ||||||||||||||
|
レベル2ではインターフェースを静的に決定せずに、プログラムから動的に取り替えることができるようにしている。つまり、実行時にインタフェースを決定している。JavaのリフレクションAPIを利用してメソッドの呼び出しをしているイメージだ。 しかし動的にルーティングされているわけではなく、インターフェースに対して1つの実装となっており、実装を取り替えることはできない。 |
||||||||||||||
| レベル3 | ||||||||||||||
|
レベル3では、インターフェースに対する実装も変更することができる。もちろん、クライアント側のプログラムが実装を指定しまえば依存関係が強くなってしまうが、対応するメッセージをインターフェースに送信するだけで適切な実装を発見し、実行することができるようになる。この、発見して呼び出すことを動的ルーティングと呼ぶ。 「インタフェース=実装」という粒度でインターフェースを決定するとレベル2と変わらなくなってしまう。粒度の大きなインタフェースをサービスとして定義する必要があるだろう。例えば、請求業務の例で考えてみるとA事業部請求書発行といったインタフェースでは意味がなく、請求書発行というインタフェースに対して、A事業部用の実装があり、送信されたメッセージの中身によって実装が選択されることになる。 このレベルを満たすためには動的なルーティングが必要になる。この動的ルーティングはコンテンツベースルーティング(CBR)と呼ばれ、メッセージの内容によって呼び出し先を変える機能のことを指す。このレベル3こそが、SOAが求める疎結合のレベルだ。 |
||||||||||||||
| 次回は | ||||||||||||||
|
さて、ここまででSOAを理解する上で問題となる疎結合ということばをレベル分けして説明してきた。この基準に異論はあるだろう。筆者としても完全に練られたものでないと思う。ご意見ご感想をお聞きしたい。 それでもあえて図1をあらわしたのは、このように基準を明確にすることで疎結合についても議論することができるからだ。 次回はレベル3の疎結合、つまりはSOAを実現する技術にはどのようなものがあるのかを説明していく。 |
||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||

