ESBとBPELサーバの連携

メディエータの内部に複雑なビジネスロジックを用いる場合

   ESBによるメディエータは複雑なビジネスロジックを取り扱えるとは限りません。ESBの実装依存となるが、ESBのメディエータは一般的に VETROの組合せとなるため、複雑なビジネスロジックを取り扱えない。そのため、複雑なビジネスロジックに関してはBPELを利用することになる。

メディエータの中から非同期呼び出しをする場合

   ESBのメディエータでは、トランザクション管理の標準、並行稼動させた場合の識別の標準がないため、OnewayのMEPでない非同期呼び出しは開発が難しくなる。そのため、人間の作業待ちなどの非同期呼び出しをする場合はBPELを利用することになる。

   このような基準による使い分けを考える必要がある。ここでは筆者の考えてとして述べたが製品や状況に異なるのはいうまでもない。このようなことを考えることが重要ということだ。

BPELサーバとESBを利用したシステムイメージ

   以上の特徴を生かしたシステムイメージを考えると図4のようになる。

図4：BPELサーバとESBを利用したシステムイメージ図

   BPELは、なんらかのクライアントから呼び出される。その呼び出しはESBを経由しておこなわれる。

   呼び出されたBPELはBPELサーバで実行され、人間をおこなうタスクを待ち合わせたり、他のサービスをESB経由で呼び出したりすることで実行する。

   サービスそのものはESBで実行されるだろう。BPELではステータスや非同期を管理することが可能なので、人間との応答を含むプロセスはESBではなくBPELサーバの責務とするのがふさわしいだろう。

   全6回を通じて、SOAらしいシステムの形状をサービスの性質、ESB、BPELの技術を踏まえて検討してきた。読者の方々は、この図4を別の場所でもみたことがあるのではないだろうか。5回から説明してきた内容があってこの図にたどりつく。

   この図4で実感がわいてもらえれば幸いだ。