ESBの役割

最後に

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

RPC指向よりもメッセージ指向に

ESBのサービスは単純な関数としてサービスをとらえるのではなく、メディエータとしてサービスをとらえるべ きだ。そのためESBのサービスに入力されるメッセージは、関数の引数ではなく粒度の大きい意味のある単位で考える。そのため、RPC指向よりもメッセー ジ指向になる。
 

同期よりも非同期

ESBが複数のトランスポートをサポートしているために、SOAPやJMSといった同期・非同期にかかわらずにサービスを呼び出すことができる。そのため、同期よりも非同期にすることが可能だ。
 

ヘテロジニアス環境で実現する

Webサービスへの接続、外部アダプタの利用によりヘテロジニアスな環境で実現することが可能だ。ただし、Webサービスの呼び出しに関しては標準仕様のバージョンなどにより接続ができない場合があるので、WS-IのBasicプロファイルに対応させるなど工夫が必要だ。
 

結合要素間の技術は変更可能にせよ

複数トランスポートサポートと外部アダプタなどによって、結合要素間の技術を変更可能とすることができる。第 2回の例として説明したEJBとメッセージキューシステムを統合する場合は、JMSのAPIを利用してEJBもメッセージキューシステムも統合することが 可能となる。

ESBの位置づけ

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

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

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

   次回以降でBPELの詳細について説明する。