バス内で複数の WS-Notification サービスを作成する理由
一般的に、各サービス統合バスに複数の WS-Notification サービスを作成する必要はありません (ただし、それを行うと有効なケースもあります)。
1 つのセルに複数のサービス統合バスを定義し、各バスに定義されたメッセージング・リソースに WS-Notification アクセスを提供する場合は、各バスに WS-Notification サービスを定義する必要があります。WS-Notification アクセスを必要とする各サービス統合バスに、1 つの WS-Notification サービスを構成することをお勧めします。 これによって、異なる WS-Notification サービスに接続されているアプリケーションが、互いに情報を渡せなくなるか、干渉を起こします。
クライアント・アプリケーションのグループを別々の集合に分離するために、単一のバス上に複数の WS-Notification サービスを定義することを選択する場合があります (例えば、このセクション内で後に示す要件の 1 つに合わせるため)。ただし、このパターンは注意して使用してください。この選択には、特に、WS-Notification サービスに定義されている WS-Notification トピック名前空間に関連した重要な意味が含まれているからです。トピック名前空間パターンについて詳しくは、永続トピック名前空間とバス・トピック・スペースを関連付けるオプションを参照してください。
- 異なる名前空間を使用したアプリケーションの分離。 2 つの WS-Notification サービスで、それぞれのサービスを使用するアプリケーションを分離するために、異なったトピック名前空間 URI (および同様に、異なるサービス統合バス・トピック名前空間) を使用できます。詳しくは、サービス統合バス・トピック・スペースとトピック名前空間 URI 間の "1 対 1" アソシエーションを参照してください。このような分離は、単一の WS-Notification サービスを使用しても行うことができます。
- 同じ名前空間を使用したアプリケーションの強制分離。 単一のバスに複数の WS-Notification サービスを定義する主な利点は、同じトピック名前空間を使用するために書き込まれたアプリケーションのコレクションを、2 つ以上の全く対話しない異なるグループに区分けする機能から発生します。 これにより、最初の WS-Notification サービスに接続されたアプリケーションは、たとえ同じトピック名前空間 (およびおそらく同じトピックのセット) を使用していても、第 2 の WS-Notification サービスに接続されたアプリケーションと完全に分離して操作できます。詳しくは、サービス統合バス・トピック・スペースとトピック名前空間 URI 間の "多 対 1" アソシエーションを参照してください。
- 代替の JAX-RPC ハンドラー・リストおよびアウトバウンド・セキュリティー設定。 これらのプロパティーは、各アウトバウンド・ポートではなく、各 WS-Notification サービスに指定されています。これらのプロパティーに代わるオプションを必要とする場合は、各代替のアウトバウンド構成で同じバス上に別個の WS-Notification サービスを作成します。