WAS v8.5 > WebSphere applications > Web services > WS-Notification > WS-Notification: Overview

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 v1.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 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 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 WAS, see Applying 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 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 WAS are as follows:

Simple TopicWAS, Expressions

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 TopicWAS, Expression dialect, and there is no topic hierarchy or use of wildcards. Examples of valid Simple TopicWAS, Expressions are tns1:stock or tns2:sports, where (for example) tns1 is a reference to the namespace in which the topic is located.

Concrete TopicWAS, Expressions

This topic dialect extends the Simple TopicWAS, 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 TopicWAS, Expressions are tns1:stock/IBM or tns2:sports/football. Note that a valid Simple TopicWAS, Expression is automatically valid in the Concrete TopicWAS, Expression dialect.

Full TopicWAS, Expressions

This topic dialect extends the Concrete TopicWAS, 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 TopicWAS, 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 WAS 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 TopicWAS, Expression dialect, whereas for simpler cases the application can use the Simple or Concrete TopicWAS, Expression dialects.


Related concepts:

Base notification
Brokered notification
WS-Notification


Related


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
List active WS-Notification administered subscribers


Reference:

WS-Notification troubleshooting tips
createWSNAdministeredSubscriber command
listWSNAdministeredSubscribers command
showWSNAdministeredSubscriber command

WS-Topics v1.3 OASIS Standard


Related information:

Administered subscribers [Settings]


+

Search Tips   |   Advanced Search