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. 您可以在 Cell 中所定義的一組永久主題名稱空間(也就是說,針對這個 Cell 中所定義的所有 WS-Notification 服務)與它們所關聯的服務整合匯流排主題空間之間,建立起多對多的關係。 這些關係有可能會變得非常複雜化,這會隨著連接 WS-Notification 服務的應用程式所需要的拓蹼而不同。 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

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 you want 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 you want 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 you 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.


指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:11
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjwsn_ptn_options
檔名:cjwsn_ptn_options.html