+

Search Tips   |   Advanced Search

WS-Topics

The WS-Topics standard describes how a NotificationProducer application can associate a Topic with the NotificationMessages that it produces.

The abstract of the WS-Topics Version 1.3 OASIS Standard describes WS-Topics as follows:

This document defines a mechanism to organize and categorize items of interest for subscription known as "topics". These are used with the notification mechanisms defined in WS-BaseNotification. WS-Topics defines three topic expression dialects that can be used as subscription expressions in subscribe request messages and other parts of the WS-Notification system. It further specifies an XML model for describing metadata associated with topics.

Copyright © OASIS Open 2004-2006. All Rights Reserved.

This document and translations of it might be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation might be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the previous copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

A Topic is used to group notification messages that relate to a particular type of information - for example a stock ticker NotificationProducer application might set the Topic of the NotificationMessages it produces to the stock symbol with which the information is associated - for example "stock/IBM".

NotificationConsumer applications are able to specify a Topic when they Subscribe, which results in delivery of all messages produced by that NotificationProducer application on the specified Topic.

Each Topic is defined as part of an XML namespace. The set of Topics associated with a given XML namespace is called a TopicNamespace. Allocation of Topics to a particular TopicNamespace is used to avoid naming collisions and facilitate interoperation between independently developed NotificationProducer application and NotificationConsumer applications.

The WS-Topics TopicNamespace concept is slightly different to the service integration technologies concept of a Topic Space. For more information, see WS-Notification terminology.

The mechanism for achieving this collision avoidance is usually determined by the application developer - in one pattern an application developer defines a namespace for use by a related group of applications. This leaves the developer free to use whatever topic structure they see fit within that namespace. To continue the prior example, the application developer might define one TopicNamespace for notification messages published in French, and a different one for notifications published in English. A subscribing application then specifies the namespace/topic in which they are interested (for example "english:stock/IBM") to ensure they receive notification messages in the appropriate language. In this way we can use the "same" topic structure (with different namespaces) to ensure that the application does not receive incompatible notifications.

Section 6 of the WS-Topics standard describes the method for modeling TopicNamespaces as an XML document. This allows the structure of a Topic Space to be defined, and (optionally) places conditions on the Topics that can be used by applications referencing a given Topic Space. For information about how this has been implemented in WebSphere Application Server, see Apply a WS-Notification topic namespace document.

Section 7 of the WS-Topics standard defines example topic expression dialects that are recommended for use by WS-Notification applications. Note that the WS-Notification standards provide an extensibility mechanism to allow vendors to define their own topic expression dialects. The three topic expression dialects supported by WebSphere Application Server are as follows:

Simple TopicWebSphere Application Server Express ions

A basic style of topic expression in which the only allowed topics are QNames. This means that only root topics are supported by the Simple TopicWebSphere Application Server Expression dialect, and that there is no topic hierarchy or use of wildcards. Examples of valid Simple TopicWebSphere Application Server Expressions are tns1:stock or tns2:sports, where (for example) tns1 is a reference to the namespace in which the topic is located.

Concrete TopicWebSphere Application Server Expressions

This topic dialect extends the Simple TopicWebSphere Application Server Expression pattern to allow topic hierarchies using the / (forward slash) character to indicate a "child of" relationship. Note that this topic dialect also does not allow use of wildcards. Examples of valid Concrete TopicWebSphere Application Server Expressions are tns1:stock/IBM or tns2:sports/football. Note that a valid Simple TopicWebSphere Application Server Expression is automatically valid in the Concrete TopicWebSphere Application Server Expression dialect.

Full TopicWebSphere Application Server Expressions

This topic dialect extends the Concrete TopicWebSphere Application Server Expression dialect to include the concepts of wildcards and conjunction. It is based on a subset of the XPath location path expressions, and describes how expressions of this type can be evaluated using the XML document representation of a Topic Space as previously described. Use the XPath-style asterisk (*) and dot (.) characters as wildcards, and the vertical bar (|) character as the conjunction operator. Examples of valid Full TopicWebSphere Application Server Expressions are as follows: 
tns1:t1/*
tns1:t1/*/t3
tns1:*
tns1:t1/t3//.
tns1:t1/t3//*
tns1://*
tns1:t1//t3
tns1:t1/t2 | tns1:t4/t5

In general NotificationProducer applications might support any number of the topic dialects described previously (including none, and also support dialects not listed in the previous section). This allows simple NotificationProducer applications to specify how they want to expose the structure of the information on which they provide notifications.

The NotificationBroker provided by WebSphere Application Server supports all three of the dialects previously described, and the application developer can decide which one to use depending upon their requirements. For complicated expressions that use wildcards the application needs to use the Full TopicWebSphere Application Server Expression dialect, whereas for simpler cases the application can use the Simple or Concrete TopicWebSphere Application Server Expression dialects.


Related concepts

  • Base notification
  • Brokered notification
  • WS-Notification


    Related tasks

  • Use WS-Notification for publish and subscribe messaging for web services
  • Secure WS-Notification
  • Create a new WS-Notification administered subscriber
  • Modify a WS-Notification administered subscriber
  • Listing active WS-Notification administered subscribers

  • WS-Notification troubleshooting tips
  • createWSNAdministeredSubscriber command
  • listWSNAdministeredSubscribers command
  • showWSNAdministeredSubscriber command
  • WS-Topics Version 1.3 OASIS Standard


    Related information:

  • Administered subscribers [Settings]