バス構成
要件に応じて、さまざまな方法でバスを接続することができます。 例えば、メッセージング・エンジンをリンクしてメッセージの作業負荷を分散し、 システム障害が発生した場合の可用性を確保できます。
一部のアプリケーションでは、単一のメッセージング・エンジンのみを持つ構成が適切な場合があります。ただし、複数のメッセージング・エンジンをデプロイして、これらを相互にリンクさせると、以下の利点が得られます。
- メッセージングの作業負荷が、複数のサーバーに分散されます。
- メッセージ処理機能を、その処理を使用しているアプリケーションの近くに配置して、 ネットワーク・トラフィックを削減します。例えば、 送信アプリケーションと受信アプリケーションが同一のサーバー・プロセスで稼働している場合、 リモート・サーバーで稼働するメッセージング・エンジンを介して、2 つのアプリケーション間で 流れるすべてのメッセージをルーティングすることは非効率的です。
- システム障害、またはリンク障害が発生した場合の可用性が向上します。例えば、 バス・トポロジーで Single Point of Failure を除去し、2 つのサーバー間でのストア・アンド・フォワードを有効にすることができます。
- スケーラビリティーのオプションが向上します。
- 単一のメッセージング・エンジンへの接続に対するネットワーク・ホストの機能を制限する、ファイアウォールや他のネットワーク制限を適用できます。
- バス構成には IBM MQ ネットワークへのリンクを組み込むことができます。 これにより、IBM MQ キュー・マネージャーに接続されたアプリケーションと、サービス統合バスに接続されたアプリケーションの間をメッセージが流れるようになります。
サービス統合バスでメッセージング・エンジンをホストするアプリケーション・サーバーまたはクラスターは、バス・メンバーと呼ばれます。IBM MQ サーバーは、IBM MQ でメッセージング・エンジンと同等の役割を果たします。IBM MQ サーバーをバスのメンバーにすることができます。これは、アプリケーション・サーバーによってホストされないメッセージング・エンジンになります。
バス構成には 1 つ以上のブートストラップ・メンバーを組み込むことができます。バスに接続する必要がある場合、アプリケーションは、要求を認証するブートストラップ・メンバーに接続してから、その接続要求を適切なバス・メンバーに送信します。ブートストラップ・メンバーはブートストラップ要求のみに応答し、常にメッセージング・エンジンをホストするわけではありません。
バス構成が複数のセキュリティー・ドメインを使用する場合、サーバーまたはクラスターのサブセットのみがバスにアクセスできるようにブートストラップ・メンバーを構成することによって、バスとバスを使用するアプリケーションを隔離することができます。