最後に

第2〜3回で説明した疎結合のレベルを高めるための指針が、ESBの機能によって実現できることを説明してきた。今一度、ここでまとめておこう。

RPC指向よりもメッセージ指向に: ESBのサービスは単純な関数としてサービスをとらえるのではなく、メディエータとしてサービスをとらえるべきだ。そのためESBのサービスに入力されるメッセージは、関数の引数ではなく粒度の大きい意味のある単位で考える。そのため、RPC指向よりもメッセージ指向になる。
同期よりも非同期: ESBが複数のトランスポートをサポートしているために、SOAPやJMSといった同期・非同期にかかわらずにサービスを呼び出すことができる。そのため、同期よりも非同期にすることが可能だ。
ヘテロジニアス環境で実現する: Webサービスへの接続、外部アダプタの利用によりヘテロジニアスな環境で実現することが可能だ。ただし、Webサービスの呼び出しに関しては標準仕様のバージョンなどにより接続ができない場合があるので、WS-IのBasicプロファイルに対応させるなど工夫が必要だ。
結合要素間の技術は変更可能にせよ: 複数トランスポートサポートと外部アダプタなどによって、結合要素間の技術を変更可能とすることができる。第 2回の例として説明したEJBとメッセージキューシステムを統合する場合は、JMSのAPIを利用してEJBもメッセージキューシステムも統合することが可能となる。

表2：疎結合のレベルを高めるための指針

ESBの位置づけ

   ESBを語る上で、よく聞くのが「BPELとの違いと何か」ということである。そこで、ESBとBPELサーバ（エンジン）との違いを明確にすることで、ESBの位置づけを明確にしていく。また、ESBを提供しているベンダーによってこの2つの使い分けが異なっているため、SOAを導くシステムのイメージに混乱が生じているともいえる。

   両者の違いを考える上では2つの立場がある。1つはESBをミドルウェアの中心としてメディエーションをうまく利用するという立場で、もう1つは BPELサーバをミドルウェアの中心としてメディエーションはBPELとして記述する。ESBは位置透過性やルーティングといった役割だけを持つという立場だ。どちらが正しいというわけではない。各プロダクトの特徴をうまく利用することが大事なのである。

   本連載ではESBを中心としてとらえ、次の場合にBPELを利用するという方針にしていく。