Network Deployment (Distributed operating systems), v8.0 > Applications > Web services > WS-Notification
Options for associating a permanent topic namespace with a bus topic space
When you configure a permanent topic namespace on a WS-Notification service, you nominate a service integration bus topic space to which messages are published in response to the WSN Notify operation, and from which they are received when they match a subscription. We can create many to many relationships between the set of permanent topic namespaces defined in a cell (that is for all WS-Notification services defined in that cell) and the service integration bus topic spaces with which they are associated. These relationships can become quite complex depending upon the topologies required by the applications that connect to the WS-Notification service. This topic provides guidance on when certain configurations might or might not be appropriate.
The following options are arranged in increasing order of complexity. You should think carefully before configuring anything except the "1 to 1" association:
- 1 to 1 association between a service integration bus topic space and a topic namespace URI
- many to 1 association between a service integration bus topic space and a topic namespace URI
- 1 to many association between a service integration bus topic space and multiple topic namespaces URIs (same WS-Notification service)
- 1 to many association between a service integration bus topic space and multiple topic namespaces URIs (different WS-Notification services)
- Different buses with same service integration bus topic space names
1 to 1 association between a service integration bus topic space and a topic namespace URI
In this situation there is either only one WS-Notification service defined on this bus, or if there are two WS-Notification services defined the second service does not contain a topic namespace associated with the same service integration bus topic space.
This configuration provides the ability for WS-Notification applications to insert event notifications into (or receive notifications from) the service integration bus topic space, which might include notifications originated by other clients of the bus.
In situations where there are multiple WS-Notification services defined on a given Bus this "1 to 1" association guarantees segregation between the clients attached to each service - that is to say that no event notification inserted by use of the first WS-Notification service will be received by applications connected through the second WS-Notification service.
Note that this segregation pattern is one of the reasons for creating two WS-Notification services on the same bus.
many to 1 association between a service integration bus topic space and a topic namespace URI
In this case a single topic namespace URI has been associated with multiple service integration bus topic spaces. This can only occur if multiple WS-Notification services have been defined, because a namespace URI can only be associated with a single service integration bus topic space in a given WS-Notification service.
This approach should be taken in situations where there are a number of clients using the same namespace URI and to segregate a subset of the clients so that they do not interact with the other clients. The exact justification for doing this is entirely dependent upon the situation at hand, however in the general case this should not be necessary. Note that this segregation pattern is the second (and most compelling)
reason for creating more than one WS-Notification service on a given bus.
1 to many association between a service integration bus topic space and multiple topic namespaces URIs (same WS-Notification service)
In this situation multiple permanent topic namespaces have been defined on the same WS-Notification service that point at the same service integration bus topic space.
The most obvious reason for doing this is because there are two groups of applications that are already coded to use the two distinct URIs, and these application groups are in some way linked, and you therefore want to support them by using the same service integration bus topic space. This might be for any of the following reasons:
- The topics used by the two applications groups do not overlap, but they want to interact with the same non-WS-Notification applications. Using this pattern the other bus applications need only connect to a single topic space in order to be able to receive messages from both of the application groups.
- The topics used by the two application groups overlap in some way, and you want them to be able to receive publications sent by applications in the other group. For example if the two namespaces contain the exact same topics, but the namespace URI was changed in order to conform to some standardized naming scheme, then older applications would use the original name, whereas new applications would use the new name.
A second reason for defining multiple topic namespaces on the same WS-Notification service (with the same service integration bus topic space but different namespace URIs) is to apply different topic space documents for different application groups. This might be for any of the following reasons:
- The topic namespaces are in no way related, but to use the same service integration bus topic space to avoid the administrative cost of creating a separate service integration bus topic space. You should usually only do this if the topics used by the namespaces do not overlap, otherwise there might be interference between the two sets of applications.
- Topics defined in the namespaces overlap, and applications that use each of the namespaces want to interact with the same non-WS-Notification applications.
In this situation you use a topic namespace document to define (in a tree structure) the subset of topics that applies to a particular topic namespace, and you associate that document with a particular group of applications. Note that if the topic namespace documents for two different groups of applications define a topic structure that overlaps, then a non-WS-Notification application that subscribes to the overlapping topic will receive notifications published by both groups of applications.
1 to many association between a service integration bus topic space and multiple topic namespaces URIs (different WS-Notification services)
If we have defined multiple WS-Notification services then you can create equivalent permanent topic namespace definitions on each service in order to provide the same functions to clients connected to any of the WS-Notification services. This might however be achieved more easily by getting all the applications to connect to service points associated with a single service.
Different buses with same service integration bus topic space names
An additional case that might cause confusion is where there are two service integration buses, each with a (single) WS-Notification service defined, and the buses contain identical service integration bus topic space names. In this situation the topic space destinations used are completely separate (not linked) and thus there is no overlap between applications that use the two WS-Notification services. You should be aware of the possibility for confusion in this situation and take appropriate action.
Reasons to create multiple WS-Notification services in a bus
WS-Notification
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification
Create a new WS-Notification permanent topic namespace
Showing the properties of a permanent WS-Notification topic namespace
Related
WS-Notification troubleshooting tips
createWSNTopicNamespace command
showWSNTopicNamespace command
Permanent topic namespace [Settings]
Concept topic