複数サーバーで構成されるエンタープライズ・サービス・バスは、 スケーラビリティーに優れ、より多くのクライアント接続やより大きなメッセージ・スループットを 処理することができます。また、(例えば、さまざまなリソースやサービス品質を提供したり、組織内の異 なる部門ごとに別々の選択肢を用意したり、テスト機能と実動機能を分離したりするために) SCA モジュールを複数の異なるサーバーにデプロイすることもできます。
バス環境で複数のサーバーを作成するには、デプロイメント・マネージャー・セルに 管理対象ノードが含まれている必要があります。
メディエーション・モジュールが必要とする SCA ランタイムごとに、 サーバーを構成してください。この拡張構成によって、 SCA ランタイムが活用するキュー宛先をローカル・サーバーでホストするのか、 リモート・サーバーでホストするのかが定義されます。サーバーがキュー宛先を ホストするように指定した場合、そのサーバーは SCA.SYSTEM バスのメンバーになり、 キュー宛先が割り当てられるメッセージング・エンジンを取得します。 サーバーがキュー宛先をホストしないように指定した場合、そのサーバーは SCA.SYSTEM バスのメンバーである必要はなく、 したがって、メッセージング・エンジンも必要としません。
図 1 に 示すシナリオを参照してください。
SCA.SYSTEM バス内のメッセージング・エンジンはすべて、暗黙的に接続されていて、 要求はバス内のどのメッセージング・エンジンでも処理できます。 バス内の各メッセージング・エンジンに割り当てられているリソースに関する情報は、 そのバスのすべてのメッセージング・エンジン間で共有されます。
バス内のすべての メッセージング・エンジンが同時に稼働している必要はありません。そのうちの 1 つが 停止しても、残りのメッセージング・エンジンは引き続き 作動します。ただし、メッセージング・エンジンが停止すると、そのメッセージング・エンジンが 所有するリソース (具体的にはメディエーション・モジュールのキュー・ポイント) は使用できなくなります。 また、メッセージング・エンジンはその作成対象となったサーバーでのみ実行できます。したがって、 そのサーバーが Single Point of Failure となります。サーバーが稼働できない場合は、 メッセージング・エンジンも使用できません。サーバー・クラスターをバス・メンバーとして構成することにより、 メッセージング・エンジンには、クラスター内の 1 つのサーバーで稼働する機能が備わります。 この場合、そのサーバーが故障しても、メッセージング・エンジンはクラスター内の代替サーバーで 実行できます。
複数サーバー・エンタープライズ・サービス・バスを作成するには、次のよう ないくつかの方法を使用することができます。