Terminologie aus den WS-Notification-Standards
Die in diesem Artikel beschriebene Terminologie ist in den WS-Notification-Spezifikationen definiert und gilt für alle anbieterspezifischen Implementierungen dieser Spezifikationen.
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 Version 1.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 Version 1.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 Version 1.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.
Der folgende Begriff ist zwar aus den WS-Notification-Spezifikationen abgeleitet, entspricht aber nicht dem exakten Wortlaut der Spezifikationen:
- Pull-Punkt:
- Es gibt bestimmte Situationen, in denen der "Push-Stil" der NotificationMessage-Zustellung nicht angemessen ist. Beispielsweise befinden sich bestimmte NotificationConsumer hinter einer Firewall, sodass der NotificationProducer keinen Nachrichtenaustausch einleiten kann, um die Benachrichtigung (Notification) zu senden. Ähnliches gilt für NotificationConsumer, die nicht in der Lage oder bereit sind, einen Endpunkt bereitzustellen, an den der NotificationProducer Benachrichtigungen senden kann. In anderen Fällen bevorzugt der NotificationConsumer, den Empfang von Benachrichtigungen zeitlich zu steuern. Anstatt die Benachrichtigungen in unvorhersehbaren Intervallen zum empfangen, kann er vorziehen, die Benachrichtigungen zu einem Zeitpunkt seiner Wahl zu "extrahieren" (Pull) oder "abzurufen".
- Aus diesen Gründen definiert die Spezifikation Web Services Base Notification ein portTypes-Paar: eine Schnittstelle "PullPoint", die einen Endpunkt definiert, an dem sich Benachrichtigungen ansammeln und von dem ein Anforderer die angesammelten Nachrichten abrufen kann, und eine Schnittstelle "CreatePullPoint", die als Factory für PullPoint-Ressourcen dient.
- Das geplante Verwendungsmuster ist, dass ein Subskribent oder eine andere Partei einen Pull-Punkt (PullPoint) über die Factory-Schnittstelle erstellt und diesen anschließend als Referenz auf den Konsumenten (ConsumerReference) in einer oder mehreren Subskriptionsanforderungen (Subscribe) verwendet. Der Konsument extrahiert dann die Benachrichtigungen aus dem Pull-Punkt.