ESBの成り立ち
ESBとマルチトランスポート
SOA基盤を構築する上でESBのメッセージング基盤としての役割で最も重要なのが、安定して信頼できる基盤を提供することです。一般に適用される製品としてのESBも企業の中で適用されるESBも、どのアプリケーションがどれくらいの性能を必要とするかは特定できません。そのためには性能に重点を置いたESBの設計が重要です。
一方、ESBはプロトコルやテクノロジーをアプリケーションに意識させないという側面を持っていますので、実際にメッセージを転送するトランスポートを選択できる場合があります。
XMLで書かれたSOAPメッセージを構文解析するにはCPUコストがかかります。大量のバイナリデータをエンコードして転送するのも無理があります。従来ですとアプリケーションの設計者が要件にあわせてテクノロジーを選択するので、APIもそれぞれ異なるものになり、複数のノウハウが同時に必要でした。
ESBはこの点を改善することができます。アプリケーションに対して統一したAPIでマルチトランスポート、マルチペイロードをサポートすることができます。必要なあればあればAPIを変更せずに適合できるテクノロジーとして、別のトランスポートを選択することができます。
図3：SOAPメッセージのマルチトランスポートでのサポート
非同期／同期メッセージング
ESBでアプリケーション同士の連携を解説するまえに、アプリケーション間のメッセージについて解説します。
アプリケーション間で行うメッセージには非同期と同期メッセージングという区別があります。非同期メッセージングの代表はWebSphereMQであり、JMSでしょう。同期メッセージはCORBAとRMIでしょうか。また、Webサービスも同期メッセージングが中心です。
最近は疎結合という言葉が盛んに使われています。本来はアプリケーション同士が連携するためのインタフェースが、それぞれの内部処理に影響しない、アプリケーションの処理がにじみでてくるようなことのないインタフェースであることが望ましいのです。
つまり、きれいなインタフェースを設計しなさいという意味ですが、メッセージングのレベルでは非同期メッセージングが疎結合となります。なお、メッセージングという言葉はRPC（Remote Procedure Call）と区別する使い方があるのですが、ここでは同期メッセージングはリクエスト／レスポンスを示し、RPCと同様のメッセージング・スタイルという意味で使います。
これに対して、非同期メッセージングとMOMであればキューを介するようなメッセージング・スタイルのことであり、EAIツールであれば、ブローカがメッセージの転送の仲介する非同期のメッセージング・スタイルのものです。
では、なぜ非同期メッセージングがよいかというと、1つはリクエスト・メッセージを送信した後、レスポンス・メッセージをその場で待ち合わせなくてもよいことがあげられます。
つまり、サーバ（これはRPCでの言い方であり、サービス指向ではサービス提供者が正しい呼び名です）側で行うアプリケーション処理を待ち合わせることがないため、疎結合であるといわれています。
また、トピックを購読するパブリッシュ／サブスクライブのメッセージング・スタイルの場合はブローカが必須であり、非同期メッセージになります。さらに、数時間や数日もかかるようなトランザクションの場合、同期メッセージングでシステムが待ち合わせるわけにはいかないので非同期メッセージングになります。
このように非同期メッセージングには有効な点が多くあるのですが、その実装方法は複雑です。例えば、クライアントからのリクエストを非同期メッセージングで送信した場合、結果は非同期のイベントとして処理しなければなりません。つまり、受信したイベントとアプリケーションの状態を照合して、次の処理を決める状態遷移のプログラムを作る必要があります。
このときのサービス提供者、つまりサーバ側はマルチスレッドで動作しているはずであり、サービス利用者側もマルチスレッドで実装すれば、サービス利用者、サービス提供者がともにスレッドを割り当てられて、アプリケーションの意味としては同期メッセージングでもいいわけです。
