複数の WS-Notification サービス・ポイントを作成する理由
特定の WS-Notification サービスで複数の WS-Notification サービス・ポイントを作成したほうがよい主なケースが 2 つあります。
これら 2 つのケースは、以下のとおりです。
- セル内で複数のサーバーを介して WS-Notification アクセスを提供する場合。
- 異なるバインディングやセキュリティー・パラメーターを使用して、WS-Notification アプリケーションが同じサーバーに接続できるメカニズムを提供する場合。
セル内で複数のサーバーを介して WS-Notification アクセスを提供するには、セル内の各サーバーについて WS-Notification サービス・ポイントを最大で 1 つ定義する必要があります。これにより、ロード・バランシングのトポロジーで説明されているように、サーバー間のクライアントの手動配布に基づいて、または自動的に、作業ロード・バランシングを行うことができます。 サーバーによっては、サービス・ポイントを全く定義しない場合があるので注意してください。
異なるバインディングやセキュリティー・パラメーターを使用して、WS-Notification アプリケーションが同じサーバーに接続できるメカニズムを提供するには、特定サーバー上に複数の WS-Notification サービス・ポイントを定義し、特定のサービス・ポイントを介して特定のアプリケーションにチャネル接続する必要があります。 このオプションにはさらに 2 つのサブケースがあります。
- 異なるタイプ (バインディング) の WS-Notification サービス・ポイント。
例えば、1 つのサービス・ポイントを SOAP over HTTP を使用するアプリケーション用に、もう 1 つのサービス・ポイントを SOAP over JMS 用に作成する場合、これにより、いずれかのバインディングを使用するように書かれたアプリケーションは、当該の WS-Notification サービスに接続できます。注: WS-Notification: サポートされるバインディングで説明しているように、SOAP over JMS を使用すると、パフォーマンス・コストが生じます。
- 同じバインディングを使用する複数の WS-Notification サービス・ポイント。 例えば、同じサーバー上で両方とも SOAP over HTTP バインディングを使用する 2 つのサービス・ポイントを定義することができます。両方のサービス・ポイントが同一の機能を提供するため、単純なケースではこれを行う理由はありませんが、状態が進むと、この構成によって 2 つのサービス・ポイントの違いが出てきます。例えば、各サービス・ポイントで異なるセキュリティー・ポリシーを構成したほうがよい場合があります。1 つのセキュリティー・ポリシーを、SSL トランスポート暗号化および個別の許可検査を委任するトラステッド環境外から生じる接続用に設定します。 2 つ目のポリシーは、許可ポリシーはなお必要とするものの、SSL を必要としないトラステッド環境内で実行するアプリケーション用に設定することができます。 別の例として、ビジネス価値の高いメッセージ (信頼できるトランスポートが重要)、および価値の低いイベント通知の WS-ReliableMessaging を使用しない別個のサービス・ポイントを持つアプリケーションで使用するために、1 つのサービス・ポイントで WS-ReliableMessaging の使用を要求する例があります。