永続トピック名前空間とバス・トピック・スペースを関連付けるオプション
WS-Notification サービスで永続トピック名前空間を構成する場合は、WSN 通知操作に応じて公開されるメッセージ、およびサブスクリプションと突き合わせる時点で受信されるメッセージ間でサービス統合バス・トピック・スペースを指定します。セルで定義された永続トピック名前空間のセット (そのセルで定義されたすべての WS-Notification サービス用) と、これらの名前空間が関連付けられたサービス統合バス・トピック・スペースとの間で、多対多のリレーションシップを作成することができます。これらのリレーションシップは、WS-Notification サービスに接続するアプリケーションで必要になるトポロジーによっては、非常に複雑になる場合があります。このトピックは、特定の構成が適切な場合、また適切でない場合のガイダンスを提供します。
次のオプションは、複合度が増す順序で配置されます。 "1 対 1" アソシエーション以外で構成する場合は、慎重に考慮してください。
- サービス統合バス・トピック・スペースとトピック名前空間 URI 間の "1 対 1" アソシエーション
- サービス統合バス・トピック・スペースとトピック名前空間 URI 間の "多 対 1" アソシエーション
- サービス統合バス・トピックと複数のトピック名前空間 URI 間の "1 対 多" アソシエーション (同じ WS-Notification サービス)
- サービス統合バス・トピック・スペースと複数のトピック名前空間 URI 間の "1 対 多" アソシエーション (異なる WS-Notification サービス)
- 同じサービス統合バス・トピック・スペース名と異なるバス
サービス統合バス・トピック・スペースとトピック名前空間 URI 間の "1 対 1" アソシエーション
この状態では、このバスに WS-Notification サービスが 1 つだけ定義されます。あるいは、WS-Notification サービスが 2 つ定義されている場合は、2 つ目のサービスが同じサービス統合バス・トピック・スペースと関連のあるトピック名前空間を含みません。
この構成によって、WS-Notification アプリケーションが、バスの他のクライアントによって発信される通知を含む場合があるサービス統合バス・トピック・スペースにイベント通知を挿入する (または通知を受ける) ことができます。
特定のバスに複数の WS-Notification サービスがある状態では、この "1 対 1" アソシエーションが、各サービスに付加されるクライアント間での分離を保証します。つまり、最初の WS-Notification サービスを使用することで挿入されるイベント通知が、2 つ目の WS-Notification サービスを介して接続されるアプリケーションによって受信されることはありません。 この分離パターンは、同じバス上で 2 つの WS-Notification サービスを作成する理由の 1 つです。
サービス統合バス・トピック・スペースとトピック名前空間 URI 間の "多 対 1" アソシエーション
この場合、シングル・トピック名前空間 URI は、複数のサービス統合バス・トピック・スペースと関連付けられています。 これは、名前空間 URI が、特定の WS-Notification サービスの単一のサービス統合バス・トピック・スペースにだけ関連付けられるため、複数の WS-Notification サービスが定義された場合にのみ生じます。
この方法は、同じ名前空間 URI を使用する数多くのクライアントがいて、他のクライアントと対話しないようにクライアントのサブセットを分離するときに実行します。 これを行う正確な理由付けは、目先の状態に完全に依存します。ただし、一般的には必要ありません。この分離パターンは、特定のバスに複数の WS-Notification サービスを作成する理由の 2 つ目で、最も有力なものです。
サービス統合バス・トピックと複数のトピック名前空間 URI 間の "1 対 多" アソシエーション (同じ WS-Notification サービス)
この状態では、複数の永続トピック名前空間が、同じ WS-Notification サービスで定義され、同じサービス統合バス・トピック・スペースをポイントします。
- 2 つのアプリケーション・グループによって使用されるトピックはオーバーラップしませんが、同じ非 WS-Notification のアプリケーションと対話します。 このパターンを使用して、他のバス・アプリケーションは、両方のアプリケーション・グループからメッセージを受けられるように、単一のトピック・スペースにのみ接続する必要があります。
- 2 つのアプリケーション・グループで使用されるトピックは一部オーバーラップしているので、他のグループのアプリケーションによって送信されるパブリケーションを受信することができるようにします。例えば、2 つの名前空間が全く同じトピックを含んでおり、一部の標準化されたネーミング体系で確認できるように名前空間 URI が変更された場合、古いアプリケーションが元の名前を使用して、新しいアプリケーションが新しい名前を使用します。
- トピック名前空間との関連性は全くありませんが、 同じサービス統合バス・トピック・スペースを使用して、別のサービス統合バス・ トピック・スペースを作成する管理コストを回避します。 通常これは、名前空間がオーバーラップしない場合にのみ行います。そうしないと、2 つのアプリケーションのセット間で干渉が生じる可能性があります。
- 名前空間に定義されるトピックはオーバーラップし、そのそれぞれの名前空間を使用するアプリケーションが、同じ WS-Notification 以外のアプリケーションと対話します。 この状態では、トピック名前空間文書を使用して、(ツリー構造 内で) 特定のトピック名前空間へ適用するトピックのサブセット を定義し、その文書をアプリケーションの特定のグループと関連付けます。 アプリケーションの 2 つの異なるグループのトピック名前空間 文書が、オーバーラップするトピック構造を定義する場合、オーバーラップ するトピックに対してサブスクライブしている WS-Notification 以外のアプリケーションが、アプリケーションの両方のグループがパブリッシュした通知を受信することに注意してください。
サービス統合バス・トピック・スペースと複数のトピック名前空間 URI 間の "1 対 多" アソシエーション (異なる WS-Notification サービス)
複数の WS-Notification サービスを定義する場合、いずれかの WS-Notification サービスに接続されたクライアントに同じ機能を提供するために、各サービスに同等の永続トピック名前空間定義を作成できます。これは、単一サービスに関連するサービス・ポイントに接続するすべてのアプリケーションを取得することにより、簡単に行うことができます。
同じサービス統合バス・トピック・スペース名と異なるバス
混乱が生じるもう一つのケースは、2 つのサービス統合バスがあり、それぞれが、(単一の) 定義された WS-Notification サービスを持ち、それらのバスが同一のサービス統合バス・トピック・スペース名を含んでいる場合です。この状態では、使用されるトピック・スペース宛先は完全に分離しており (リンクされていない)、2 つの WS-Notification サービスを使用するアプリケーション間にオーバーラップがありません。この状態では混乱が生じる可能性のあることを認識し、適切な措置を取るようにしてください。