ESBを必要とするシーン

サービスのメディエーション

   ESBは複数のサービスをまとめて1つのサービスとすることができ、この機能をメディエーションと呼ぶ。GoF（Gang of Four）のデザインパターンのメディエータパターンと同じ役割を持っており、この機能を使ったサービスがESBのサービスらしいサービスとなる。これは VETROパターンの組み合わせによって構成されるが、詳しくは次回解説する。

   図3にメディエーションの例を示す。これは入力されたメッセージの部分を利用して、外部サービスの呼び出し、DBMSへのアクセス、Javaの実装 を実行している。このようにいくつかのサービスや実装を組み合わせることにより、メディエーションとしてのサービスを構築することができる。

図3：メディエーションの例
（画像をクリックすると別ウィンドウに拡大図を表示します）

   BPELとの違いは、BPELのサービスは同期・非同期を問わないが、ESBのメディエーションによるサービスから他のサービスを呼び出すときは原 則として同期呼び出しをするところにある。当然のことながらビジネスプロセスをあらわすのがBPELで、サービスをあらわすのがESBだということもでき る。

   この両者の関係をうまく活かすためにシステムサービスは、ESBの機能として実装されている場合が多く、WS-*のやCBR（注3）はESBのサービスとして実装している。

   この場合はメディエータをサービスとして公開し、内部ではこれらのシステムサービスとユーザの処理サービスを呼び出して全体を構成する。システム サービスの種類によっては宣言的に行うほうがふさわしい場合もあり、その際には先に説明したフィルタなどによって設定される。例えば、SCAのモジュール はメディエータを表現している。

サービスの位置透過性

   ESBのクライアントはESBが公開しているWSDLに基づいてリクエストを組み立てればよく、実際のサービスがどこにあっても関係がない。これが ESBの位置透過性である。実際のサービスが変更された場合は、ESBの内部で呼び出している箇所を変更すればよく、以下の図のように左から右に移っても クライアントに影響はない。これもESBの機能の1つである。

図4：位置透過性の例
（画像をクリックすると別ウィンドウに拡大図を表示します）

   図4は位置透過性をあらわしており図の左から右に変更をしても、サービスクライアントの変更を必要としない。

次回は

   次回は、ESBのメディエーションを表現できるVETRO処理パターンについて説明し、ESBを利用するシステムがどのような形状になるかを説明する。

   前回説明した、SOAに必要な技術要素とESBの関係を説明してまとめとする予定だ。