Network Deployment (Distributed operating systems), v8.0 > Reference > Developer best practices
Terminology from the WS-Notification standards
The terminology defined in this topic is defined by the WS-Notification specifications and is common to any vendor implementation of these specifications.
This information has been extracted from the WS-Notification standards, and is therefore subject to the following copyright agreement:
Copyright © OASIS Open 2004-2006. All Rights Reserved.
This document and translations of it may 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 above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may 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 copyright is defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The following terms are defined in the WS-BaseNotification v1.3 OASIS Standard:
Situation:
A Situation is some occurrence known to a NotificationProducer and of potential interest to third parties.
A Situation might be a change of the internal state of a resource, or might be environmental, such as a timer event. It might also be an external event, such as a piece of news that has been supplied by a news-feed service.
WS-Notification does not specify what a Situation is or is not, nor does it define the relationship between a Situation and the Notifications that are used to describe it.
Notification:
A Notification is an artifact of a Situation containing information about that Situation that some entity wants to communicate to other entities.
A Notification is represented as an XML element with a Namespace qualified QName and a type that is defined by using XML Schema.
A typical usage pattern is to define a single Notification type (to be precise, its defining XML element) for each kind of Situation, containing information pertinent to that kind of Situation; in this case one can think of a Notification instance as in some sense being (or at least representing) the Situation.
A designer might choose to associate several different Notification types with a Situation, for example, describing different aspects of the Situation, destined for different target recipients, etc. Conversely it is possible that several essentially different Situations give rise to Notification of the same type.
NotificationProducer:
A NotificationProducer is a web service that implements the message exchanges associated with the NotificationProducer interface.
A NotificationProducer is capable of producing Notifications for those NotificationConsumers for which Subscriptions have been registered, based on Situations that occur and on the parameters supplied with the requests from which the Subscriptions were created.
A web service that implements the message exchanges associated with NotificationProducer might directly produce Notifications itself, or it may be a NotificationBroker, reproducing Notifications that were produced by separate Publisher and/or NotificationProducer entities.
It is the factory for Subscription resources.
NotificationConsumer:
A NotificationConsumer is an endpoint, represented by a WS-Addressing endpoint reference, designated to receive Notifications produced by a NotificationProducer as a result of a subscription.
A NotificationConsumer might accept the generic Notify message, or it may be able to process one or more domain-specific Notification types.
Subscription:
A Subscription represents the relationship between a NotificationConsumer and a NotificationProducer, including any filtering parameters such as Topic and various other optional filter expressions, along with any relevant policies and context information.
A Subscription resource is created when a Subscriber sends the SubscribeRequest message to a NotificationProducer.
Subscription resources are manipulated by messages sent to the SubscriptionManager web service associated with the Subscription resource.
SubscriptionManager
A SubscriptionManager is an endpoint, represented by an endpoint reference [WS-Addressing] that implements message exchanges associated with the SubscriptionManager interface.
A SubscriptionManager provides operations that allow a service requestor to query and manipulate Subscription resources that it manages.
A SubscriptionManager is subordinate to the NotificationProducer, and can be implemented by the NotificationProducer service provider, or by a separate service provider.
Subscriber:
A Subscriber is any entity that sends the SubscribeRequest message to a NotificationProducer.
Note that a Subscriber might be a different entity from the NotificationConsumer for which Notifications are produced. The following terms are defined in the WS-Topics v1.3 OASIS Standard:
Topic:
A Topic is the concept used to categorize Notifications and their related Notification schemas.
Topics are used as part of the matching process that determines which (if any) subscribing NotificationConsumers should receive a Notification.
When it generates a Notification, a Publisher can associate it with one or more Topics. The relation between Situation (as defined in [WS-BaseNotification]) and Topic is not specified by WS-Notification but might be specified by the designer of the Topic Namespace.
A synonym in some other publish/subscribe models is subject.
Topic Space:
A forest of Topic Trees grouped together into the same namespace for administrative purposes.
Topic Tree:
A hierarchical grouping of Topics.
Topic Set:
The collection of Topics supported by a NotificationProducer. The following terms are defined in the WS-BrokeredNotification v1.3 OASIS Standard:
Publisher:
A Publisher is an entity that creates Notifications, based upon Situations that it is capable of detecting and translating into Notification artifacts. It does not have to be a web service.
A Publisher can register what topics it wants to publish with a NotificationBroker.
A Publisher might be a web service that implements the message exchanges associated with the NotificationProducer interface, in which case it also distributes the Notifications to the relevant NotificationConsumers.
If a Publisher does not implement the message exchanges associated with NotificationProducer, then it is not required to support the Subscribe request message and does not have to maintain knowledge of the NotificationConsumers that are subscribed to it; a NotificationBroker takes care of this on its behalf.
NotificationBroker:
A NotificationBroker is an intermediary web service that decouples NotificationConsumers from Publishers. A NotificationBroker is capable of subscribing to notifications, either on behalf of NotificationConsumers, or for the purpose of messaging management. It is capable of disseminating notifications on behalf of Publishers to NotificationConsumers.
A NotificationBroker aggregates NotificationProducer, NotificationConsumer, and RegisterPublisher interfaces.
Acting as an intermediary, a NotificationBroker provides additional capabilities to the base NotificationProducer interface:
- It can relieve a Publisher from having to implement message exchanges associated with NotificationProducer; the NotificationBroker takes on the duties of a SubscriptionManager (managing subscriptions) and NotificationProducer (distributing NotificationMessages) on behalf of the Publisher.
- It can reduce the number of inter-service connections and references, if there are many Publishers and many NotificationConsumers
- It can act as a finder service. Potential Publishers and Subscribers can in effect find each other by utilizing a common NotificationBroker.
- It can provide anonymous Notification, so that the Publishers and the NotificationConsumers need not be aware of each other's identity.
An implementation of a NotificationBroker might provide additional added-value function that is beyond the scope of this specification, for example, logging Notifications, or transforming Topics and/or Notification content. Additional function provided by a NotificationBroker can apply to all Publishers that use it.
It might be the factory for Subscription resources or it might delegate the subscription factory to another component.
A NotificationBroker provides publisher registration functions.
A NotificationBroker might bridge between WS-Notification and other publish/subscribe systems.
PublisherRegistration:
PublisherRegistration is a resource. A PublisherRegistration represents the relationship between a Publisher and a NotificationBroker, in particular, which topics the publisher is permitted to publish to.
A PublisherRegistration resource is created when a Publisher sends the RegisterPublisher request message to a NotificationBroker and the NotificationBroker succeeds in processing the registration.
PublisherRegistration resources can be manipulated by messages sent to a PublisherRegistrationManager web service.
RegisterPublisher:
A RegisterPublisher is a web service that implements the message exchanges associated with the RegisterPublisher interface. A PublisherRegistration resource is created as a result of a RegisterPublisher request to a NotificationBroker.
PublisherRegistrationManager:
A PublisherRegistrationManager is a web service that implements message exchanges associated with the PublisherRegistrationManager interface.
A PublisherRegistration resource can be manipulated through PublisherRegistrationManager message exchanges.
A PublisherRegistrationManager provides services that allow a service requestor to query and manipulate PublisherRegistration resources that it manages.
A PublisherRegistrationManager is subordinate to the NotificationBroker, and can be implemented by the NotificationBroker service provider, or by a separate service provider.
Demand-Based Publishing:
Some Publishers might be interested in knowing whether they have any Subscribers or not, because producing a Notification might be a costly process. Such Publishers can register with the NotificationBroker as a Demand-Based Publisher.
Demand-Based Publishers implement message exchanges associated with the NotificationProducer interface.
The NotificationBroker subscribes to the Demand-Based Publisher. When the NotificationBroker knows that there are no Subscribers for the Notifications from a Demand-Based Publisher, it pauses its Subscription with that Publisher; when it knows that there are some Subscribers, it resumes the Subscription.
This way the Demand-Based Publisher does not have to produce messages when there are no Subscribers, however a Demand-Based Publisher is only required to support a single Subscriber on any given Topic, and so can delegate the management of multiple Subscribers, delivery to multiple NotificationConsumers and other related issues (for example security) to the NotificationBroker. The following term, although derived from the WS-Notification specifications, is not described in words taken directly from the specifications:
Pull Point:
There are certain circumstances in which the basic "push-style" of NotificationMessage delivery is not appropriate. For example, certain NotificationConsumers are behind a firewall such that the NotificationProducer cannot initiate a message exchange to send the Notification. A similar circumstance exists for NotificationConsumers that are unable or unwilling to provide an endpoint to which the NotificationProducer can send Notification Messages. In other situations, the NotificationConsumer prefers to control the timing of receipt of Notification Messages, instead of receiving notification messages at unpredictable intervals, it might prefer to "pull" or "retrieve" the notification messages at a time of its own choosing.
For these reasons, the Web Services Base Notification specification defines a pair of portTypes: a PullPoint interface, defining an endpoint that accumulates notification messages and allows a requestor to retrieve accumulated notification messages and a CreatePullPoint interface that acts as a factory for PullPoint resources.
The intended pattern of use is that a Subscriber or other party creates a PullPoint through the factory interface, and then uses it as the ConsumerReference in one or more Subscribe requests. The consumer then pulls Notifications from the PullPoint.
WS-Notification
Use WS-Notification for publish and subscribe messaging for web services
Secure WS-Notification
Related
http://www.research.ibm.com/journal/sj/444/niblett.html
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsn
http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pdf
http://www.w3.org/TR/1999/REC-xpath-19991116
http://www.w3.org/TR/xquery-semantics/
http://docs.oasis-open.org/wsn/wsn-ws_brokered_notification-1.3-spec-os.pdf
http://docs.oasis-open.org/wsn/wsn-ws_topics-1.3-spec-os.pdf
WS-Notification troubleshooting tips