ESBの成り立ち

ESBがサポートするメッセージング

同期、非同期メッセージングのどちらも、機能として必要なケースがありますが、実装するにあたって、よりシンプルな方式をとることが理想であるはずです。

CORBAなどをシステム連携に利用している米国の大手のテレコム会社ではシステム連携のためにメッセージ基盤を構築しており、そのメッセージ基盤のメッセージング・スタイルの利用状況を調査した結果があります。

調査書によると非同期のパブリッシュ／サブスクライブでの連携を利用しているアプリケーションは全体の10%、バッチによるファイル転送は8%、非同期のメッセージ・キューによるものは10%、同期によるリクエスト/レスポンスは、78%でした。

また、現在のWebサービスの利用方法はリクエスト／レスポンスの方式であることが大半です。サービス提供者が公開したサービスをサービス利用者が利用する場合は、リクエスト／レスポンスの同期メッセージングが最適なのです。

ESBは、サービスを利用するためのインタフェースを中心として提供するので、同期メッセージングを効率的かつ高い可用性を持って提供する必要があります。

図4：メッセージング・スタイルとESB

ビジネス・プロセスは非同期のメッセージングで遷移します。しかし、各プロセスが利用するサービスはESBを通じて、同期メッセージングで呼び出されるのが、典型的なパターンとなるはずです。

サービスを提供する側は、既存のシステムである場合も多くあり、既存のシステム間を連携する手段は、従来の方法がそのまま存在します。特に複数存在するデータベースを同期されるためには、DBMSのデータ同期の機能やファイル転送も使われているでしょう。

非同期メッセージングでも、リクエスト／レスポンスでサービスを呼び出すことは可能ですが、エンタプライズでの要件の厳しいインフラとして、オーバヘッドも少なく複雑さを軽減する同期メッセージングを利用することが、アーキテクチャとしてより合理的といえます。

しかし、ESBが同期メッセージングだけで構成されているかというとそうではありません。プロセスの遷移は非同期メッセージングであり、1対nでイベントをメッセージと通知する場合は非同期メッセージングが必要です。それらもESBがサポートします。つまり、ESBは複数のメッセージング・スタイルをサポートします。

 

次回は

SOAの基盤の事例を交えて、ミドルウェアのスパゲッティを解消するESBと新たな動向について説明します。