Home arrow Web Services arrow Page 2 - Notifications and Resources in the WS-Resource Framework
WEB SERVICES

Notifications and Resources in the WS-Resource Framework


This article concludes our discussion of the WS-Resource Framework, a set of proposed standards that formalizes the relationship between Web services and state. In this part, we finish covering notifications and go into greater detail about resources. It 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).

Author Info:
By: Sams Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 4
July 20, 2006
TABLE OF CONTENTS:
  1. · Notifications and Resources in the WS-Resource Framework
  2. · Notification Consumers
  3. · Resource Lifetime
  4. · Initializing Termination Time
  5. · Notification of WS-Resource Termination
  6. · Other WS-Resource Framework Specifications

print this article
SEARCH DEVARTICLES

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 isa 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.



blog comments powered by Disqus
WEB SERVICES ARTICLES

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials