Reasons to create multiple WS-Notification services in a bus
In general it is not necessary to create more than one WS-Notification service in each service integration bus, however there are some cases where it is useful to do so.
If we have multiple service integration buses defined in a cell and to provide WS-Notification access to messaging resources defined on each of the buses, then define a WS-Notification service on each of the buses. This configuration of one WS-Notification service on each service integration bus that needs WS-Notification access is the recommended approach. It ensures that applications connected to different WS-Notification services cannot pass information to each other, or cause interference.
We might choose to define multiple WS-Notification services on a single bus in order to segregate groups of client applications into disjoint sets, for example to meet one of the requirements listed later in this section. However, you should use this pattern with care, because there are significant implications to making this choice, in particular associated with the WS-Notification topic namespaces defined on the WS-Notification service. For more information about topic namespace patterns, see Options for associating a permanent topic namespace with a bus topic space.
- Segregation of applications by using different namespaces. Use distinct topic namespace URIs (and equally, different service integration bus topic spaces) in the two WS-Notification services to segregate the applications that use each service. For more information, see 1 to 1 association between a service integration bus topic space and a topic namespace URI. Note that segregation in this way can also be achieved by using a single WS-Notification service.
- Enforced segregation of applications using the same namespace. The key advantage of defining multiple WS-Notification services on a single bus comes from the ability to partition a collection of applications that are written to use the same topic namespace into two (or more) distinct groups that do not interact at all. This allows the applications connected to the first WS-Notification service to operate completely isolated from those connected to the second WS-Notification service, even though they are using the same topic namespace, and quite probably the same set of topics. For more information, see many to 1 association between a service integration bus topic space and a topic namespace URI
- Alternative JAX-RPC handler lists and outbound security settings. These properties are specified for each WS-Notification service, rather than for each outbound port. If we need alternative options for these properties then you should create a separate WS-Notification service on the same bus for each alternative outbound configuration.
Related concepts
WS-Notification Options for associating a permanent topic namespace with a bus topic space
Related tasks
Use WS-Notification for publish and subscribe messaging for web services Secure WS-Notification Create a new Version 6.1 WS-Notification service
WS-Notification troubleshooting tips createWSNService command
Related information:
WS-Notification services [Settings]