ESBとBPELサーバの連携

BPELサーバ

   BPELは実行時には、BPELエンジン上にデプロイされたBPELで記述したファイルが実行される。BPELで作成したプロセスは、一般に receiveアクティビティからはじまる。このアクティビティにメッセージが到着して、プロセスがスタートする。この実行時にBPELを制御するのが BPELサーバ（BPELエンジン）だ。BPELサーバの構造を抽象的に記述すると図3のようになる。

図3：BPELサーバの構造
（画像をクリックすると別ウィンドウに拡大図を表示します）

   BPELサーバは次の4つの機能から構成されている。

   外部インターフェースは、外部との関係で説明した外部からの呼び出し、外部の呼び出しを制御する機能だ。これらの機能はESBなどの他のミドルウェアで実装する場合もあるだろう。

   プロセスの実行管理は、BPELサーバにおける主要な機能だ。外部からの呼び出しに伴い、対象となるBPELファイルを選択し、BPELファイルか らプロセスのインスタンスを生成し、BPELの通りにアクティビティを実行する。そしてこれらの実行状態を内部のデータベースに格納する。

   BPELファイル管理は、BPELエンジンで実行するBPELファイルを管理する。BPELサービスをBPELエンジンにデプロイした時にファイルの管理をおこなう機能だ。

   名前空間・WSDL管理は、BPELと関係付けられるWSDLの名前空間とWSDLファイルを管理する機能だ。WSDLファイルを必要とする場合はBPELファイルと一緒にデプロイする必要がある。

BPELとESBの使い分け

   メディエーションという意味では、ESBとBPELは重なる領域がある。これらの使い分けはシステムアーキテクチャ決定の場面で重要な役割をはたす だろう。しかし、その決定を定式化できるわけではなく、ソリューションのパターンとして理解し、プロジェクトの状況・ミドルウェアの性質に応じてパターン を使い分ければよい。次から解説する3つの点に考慮すると考えやすいだろう。

ESBが複数ある場合（組織そのものやネットワークが異なる場合）

   組織やネットワークが異なる場合はESBが複数存在する場合が多い。この場合にESBが単一であるとすればシステム全体がバス型ではなく、ハブ型の統合になっており、SOA的なシステムから遠ざかっていることになる。

   そのため、ESBが複数あるシステム構成になることはまれではない。このような場合、ESB間をサービスの呼び出しによって統合することも可能だが ESBのサービス自体が順序に依存する場合もありそのような場合は呼び出したという状態を管理する必要があろう。その意味で、ESBが複数ある場合は BPELを利用することになる。