The WS-Notifications family of specifications, although not a part of WSRF, has strong ties to it. It provides a set of standard interfaces to use the notification design pattern with Web Services. WS-Notifications is divided into three specifications: WS-Topics, WS-BaseNotification, and WS-BrokeredNotification.
First of all, we have topics, which are used by the other two specifications in WS-Notifications to present a set of "items of interest for subscription". As we will see next, a service can publish a set of topics that clients can subscribe to, and receive a notification whenever the topic changes. Topics are very versatile, as they even allow us to create topic trees, where a topic can have a set of child topics. By subscribing to a topic, a client automatically receives notifications from all the descendant topics (without having to manually subscribe to each of them).
This specification defines the standard interfaces of notification consumers and producers. In a nutshell, notification producers have to expose a subscribe operation that notification consumers can use to request a subscription. Consumers, in turn, have to expose a notify operation that producers can use to deliver the notification. Furthermore, the client actually requesting the subscription need not necessarily be the consumer of those notifications. In other words, clients can perform subscriptions "on behalf of other notification consumers".
Figure 8.3, “A typical WS-Notification interaction” shows an example interaction between a notification consumer and producer, in the simple case when the subscriber and consumer are the same entity. In this example we have a single notification consumer, and a single notification producer that publishes two topics: SystemLoadHigh and SystemFault.
First of all, the notification consumer subscribes himself to the
SystemLoadHightopic. It is interesting to note that, internally, aSubscriptionresource is created with information regarding the subscription (not shown in the figure).Next, at some point in time, something happens in the notification producer that must trigger a notification from the
SystemLoadHightopic. For example, we might have implemented our service to send out a notification every time the system load passes from "more than 50%" to "less than 50%".The notification producer delivers the notification to the consumer by invoking the
notifyoperation in the consumer. As shown in the figure, this notification delivery is tied to the topic that triggered the notification.
Figure 8.4. A WS-Notification interaction where the subscriber and the consumer are different entities
Figure 8.4, “A WS-Notification interaction where the subscriber and the consumer are different entities”, on the other hand, shows how the subscriber and the consumer need not be the same entity. In the figure, the subscriber requests the producer that Service A be subscribed to the SystemLoadHigh topic. When a notification is triggered, the notification is sent to Service A (the consumer) not to the subscriber.
In brokered notifications we consider the case when notifications are delivered from the producer to the consumer through an intermediate entity called the broker. The WS-BrokeredNotification defines the standard interfaces for the notification broker.
As shown in Figure 8.5, “A typical brokered WS-Notification interaction”, in the presence of a notification broker, the producer must register with the broker and publish its topics there. The subscriber (separate from the consumer in this case), must also subscribe through the broker, not directly with the producer. Finally, when a notification is produced, it is delivered to the consumer through the broker.
