Notifications and Resources in the WS-Resource Framework - Notification Consumers
(Page 2 of 6 )
We haven't said much about notification consumers. Essentially, a notification consumer is any Web service. WS-BaseNotification defines an optional operation called Notify that consumers may choose to implement. If a consumer chooses to implement a Notify operation, then there is a simple, clearly defined operation that notification producers can invoke in order to deliver a notification message. However, WS-Notification allows the message to be delivered directly to the notification producer, without wrapping the notification message in additional XML to make it conform to a well-known operation signature.
The format of a Notify message is
<wsnt:Notify>
<wsnt:NotificationMessage>
<wsnt:Topic dialect="xsd:anyURI">
{any}
</wsnt:Topic>
<wsnt:ProducerReference>?
wsa:EndpointReference
</wsnt:ProducerReference>
<wsnt:Message>xsd:any</wsnt:Message>
<wsnt:NotificationMessage>+
</wsnt:Notify>
A Notify message can contain multiple individual notification message payloads. This grouping of messages allows a notification producer to deliver multiple notifications in a single Web service message exchange. Each notification message includes the topic associated with the message (the part of the subscription that causes the notification to be delivered to the notification consumer), an optional endpoint reference to the Web service that created the notification, and, of course, the message payload itself.
Notify is a one-way message. No response or fault message is expected back from the notification consumer.
Notification Brokers
In addition to the point-to-point model of pub/sub described by the notification producer role, the WS-BrokeredNotification specification adds an additional role called a notification broker. The notification broker acts as an intermediary between entities that detect situations and produce notification messages (a publisher) and the subscribers and notification consumers. These roles are depicted in Figure 8.5.
Figure 8.5 Adding the notification broker role
The notification broker relieves the publisher of the burden of creating and maintaining subscriptions, notifying notification consumers based on their subscriptions, and so on. The notification broker also provides the ability to keep publishers and consumers anonymous, in cases where it's important that the publisher isn't known to the consumer, or where the consumer doesn't care which publisher produces the notification message. The notification broker also has the potential of a value-added intermediary logging the notification messages for auditing purposes, for example, or using sophisticated message-oriented middleware to perform the pub/sub operations efficiently.
WS-BrokeredNotification defines a notification broker as an extension of a notification producer. So, a notification broker is everything a notification producer is—a Web service that accepts subscribe requests, provides a list of topics through a wsnt:Topics resource properties element, and so forth.
In addition to the base notification producer operations, the notification broker also supports a RegisterPublisher operation (to allow publishers to register prior to publishing notifications on particular topics). Not all brokers require preregistration of publishers. The publisher can tell whether it needs to preregister by examining the RequiresRegistration resource property of the notification broker. If this resource property is true, publishers are required to preregister before they attempt to publish. RegisterPublisher is similar to the subscribe request, in that it's a factory for a particular kind of WS-Resource, a PublisherRegistration. A PublisherRegistration WS-Resource maintains information about the publisher's registration, including duration (using WS-ResourceLifetime, of course) and the list of topics the publisher is permitted to publish on.
The notification broker also implements the Notify operation. Publishers send a notify message to the notification broker in order to publish a notification message on one or more topics. Because the publish function is implemented by sending the notify message, a notification broker looks like any other notification consumer to the publisher. This allows notification brokers to be inserted into the message flow (for auditing purposes, for example) without the publisher needing to change the way it sends its notification messages.
WS-Notification and WS-Eventing - WS-Notification isn't the only notification- or eventing-style Web service standard to be proposed. In January 2004, Microsoft, together with BEA and Tibco, proposed a specification called WS-Eventing. WS-Eventing is similar to WS-Notification in that it describes a mechanism for entities to subscribe to receive messages (events) asynchronously. However, WS-Eventing doesn't have the topic notion for categorization of situations and notification messages. WS-Eventing also doesn't have the notion of a notification broker, allowing scalability and better affinity with existing message-oriented middleware.
However, the Web services community doesn't benefit from having two notification standards. The community expects that the companies involved will work together to reconcile WS-Notification with WS-Eventing in some fashion.
Next: Resource Lifetime >>
More Web Services Articles
More By Sams Publishing
|
 This article is excerpted from chapter 8 of the book Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418). Check it out today at your favorite bookstore. Buy this book now.
|
|
