ESBを必要とするシーン
サービスのメディエーション
ESBは複数のサービスをまとめて1つのサービスとすることができ、この機能をメディエーションと呼ぶ。GoF(Gang of Four)のデザインパターンのメディエータパターンと同じ役割を持っており、この機能を使ったサービスがESBのサービスらしいサービスとなる。これは VETROパターンの組み合わせによって構成されるが、詳しくは次回解説する。
図3にメディエーションの例を示す。これは入力されたメッセージの部分を利用して、外部サービスの呼び出し、DBMSへのアクセス、Javaの実装 を実行している。このようにいくつかのサービスや実装を組み合わせることにより、メディエーションとしてのサービスを構築することができる。
BPELとの違いは、BPELのサービスは同期・非同期を問わないが、ESBのメディエーションによるサービスから他のサービスを呼び出すときは原 則として同期呼び出しをするところにある。当然のことながらビジネスプロセスをあらわすのがBPELで、サービスをあらわすのがESBだということもでき る。
この両者の関係をうまく活かすためにシステムサービスは、ESBの機能として実装されている場合が多く、WS-*のやCBR(注3)はESBのサービスとして実装している。
この場合はメディエータをサービスとして公開し、内部ではこれらのシステムサービスとユーザの処理サービスを呼び出して全体を構成する。システム サービスの種類によっては宣言的に行うほうがふさわしい場合もあり、その際には先に説明したフィルタなどによって設定される。例えば、SCAのモジュール はメディエータを表現している。
メッセージの内容によって呼び出すサービスやエンドポイントを変えるルーティングの方法
サービスの位置透過性
ESBのクライアントはESBが公開しているWSDLに基づいてリクエストを組み立てればよく、実際のサービスがどこにあっても関係がない。これが ESBの位置透過性である。実際のサービスが変更された場合は、ESBの内部で呼び出している箇所を変更すればよく、以下の図のように左から右に移っても クライアントに影響はない。これもESBの機能の1つである。
図4は位置透過性をあらわしており図の左から右に変更をしても、サービスクライアントの変更を必要としない。
次回は
次回は、ESBのメディエーションを表現できるVETRO処理パターンについて説明し、ESBを利用するシステムがどのような形状になるかを説明する。
前回説明した、SOAに必要な技術要素とESBの関係を説明してまとめとする予定だ。