WS Notification and WS Topics in the WS Resources Framework
(Page 1 of 6 )
This article continues our discussion of the WS-Resource Framework, a set of proposed standards that formalizes the relationship between Web services and state. In this part, the third of a multi-part series, we cover the use of notifications and topics. 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).
Using Notifications
Recall the StockAvailableNotification service from Chapter 4. SkatesTown introduces this service to notify customers when back-ordered stock became available. We discussed how the customers would use the registration operation to express their interest in receiving notification when certain part numbers (SKUs) were available. This service also provided a means by which stock-available notification messages were delivered (an out-only notification operation) and a means by which the customer could cancel its interest in receiving notifications.
Associated with the WS-Resource Framework, IBM, Sonic, and other companies introduced a family of related specifications called WS-Notification. WS-Notification describes the sort of publish/subscribe/notification pattern that you saw with StockAvailableNotification service and many other business processes. The specifications within the WS-Notification family include a standard set of message exchanges that provides a level of interoperability between companies involved in this sort of business process.
Now that WS-Notification is available, SkatesTown can refactor its StockAvailableNotification service to take advantage of this standardization opportunity. The benefit to SkatesTown is that it can use more common tooling and infrastructure that often follows the establishment of industry-accepted specifications. The advantage to SkatesTown's customers is that they don't have to build custom application infrastructure to deal with the way that each of their vendors (including SkatesTown) implements this style of notification-based business processes. The net benefit to the industry is that Web services can be used to build more interoperable business processes between suppliers and vendors, yielding reduced operating costs through less expensive and more effective computer systems integration.
The WS-Notification family is made up of the following four components:
Publish-Subscribe Notification for Web Services—A whitepaper that defines the base concepts, roles, and so forth within the WS-Notification set of specifications.
WS-BaseNotification—A specification that defines the basic interfaces in WS-Notification. These include Web service interfaces to describe the behavior of producers of notification messages, consumers of notification messages, and subscriptions that relate producers with consumers.
WS-Topics—A specification that defines topics, a means to categorize notifications.
WS-BrokeredNotification—A specification that defines the Web service interface to an intermediary or message broker Web service.
Let's examine WS-Notification in the context of refactoring the facilities from the SkatesTown-specific StockAvailableNotification portType into the WS-Notification-based operations added to POPortType.
Base Notification Concepts and Roles
The basic idea behind WS-Notification is to standardize the way that a Web service can notify interested parties (other Web services) that something of interest has happened. WS-Notification uses the term situation to refer to the thing of interest that has happened. There are many types of situations (situations can be literally anything): a change of state such as the status of a PurchaseOrder going from pending to invoiced, a time-based event such as the expiry of a timer, or a system resource like a server going offline. Some similar notification systems use the term event to mean a situation; however, the term event is also used to describe the message documenting the situation. WS-Notification avoided using the term event precisely because of this double meaning.
WS-Notification doesn't define what can or can't be a situation; it simply says that situations exist, and there are entities in the system that are interested in getting a message when a situation occurs. WS-Notification distinguishes between a situation and a notification message. A notification message is an XML artifact that captures important details about a situation. When did the PurchaseOrder status go from pending to invoiced? Who initiated that transition? What reason was given for the transformation? These are the sorts of information that are usually captured about a situation and made part of the notification message that documents that the situation occurred.
A notification producer is a Web service that is capable of detecting that a situation has occurred and creating an XML artifact (a notification message) that captures important details of that occurrence. In the case of SkatesTown, the PurchaseOrder WS-Resource is the entity that can detect situations related to a PurchaseOrder and generate related notification messages.
Certain parties are interested in a given situation and want to receive a notification message when that situation occurs. WS-Notification calls those parties notification consumers. The purpose of a notification consumer is to receive notification messages. In our running example, we'll make one of the Web services deployed by The Skateboard Warehouse a notification consumer.
A notification consumer is registered with a notification producer to receive notifications. When situations are detected, the notification producer is responsible for sending a notification message to the notification consumer. The basic roles and message exchanges are described in Figure 8.2.
Figure 8.2 Basic notification roles
The notification producer behavior is added to the PurchaseOrder by copying the operations defined in WS-BaseNotification's NotificationProducer portType into the POPortType definition. Two operations are defined by the NotificationProducer portType: Subscribe and GetCurrentMessage. Here is what the POPortType looks like with these added operations:
<?xml version="1.0" ?>
<wsdl:definitions name="PurchaseOrder"
...
xmlns:wsnt="http://www.ibm.com/xmlns/stdwip/
web-services/WS-Notification"
...
<!-- Port type definitions -->
<wsdl:portType name="POPortType"
wsrp:ResourceProperties=
"poRP:poResourceProperties">
<wsdl:operation name="getInvoice"> ...
<wsdl:operation name="cancelPO"> ...
<!-- ========== extends wsrp:GetResourceProperty
============ -->
<wsdl:operation name="GetResourceProperty"> ...
<!-- ===== extends
wsrp:GetMultipleResourceProperties ======= -->
<wsdl:operation
name="GetMultipleResourceProperties"> ...
<!-- ======== extends wsrp:SetResourceProperties
============ -->
<wsdl:operation name="SetResourceProperties"> ...
<!-- ======= extends wsrp:QueryResourceProperties
=========== -->
<wsdl:operation name="QueryResourceProperties">
...
<!-- ======== extends wsnt:NotificationProducer
============= -->
<wsdl:operation name="Subscribe"> ...
<wsdl:operation name="GetCurrentMessage"> ...
...
</wsdl:portType>
</wsdl:definitions>
We'll discuss how these two additional operations are used by requestors like The Skateboard Warehouse in the following sections. We'll also discuss the additional resource properties that are added to the PurchaseOrder resource properties document as a result of mixing notification producer behavior into the POPortType. But first, let's examine the subscribe operation in more detail.
Next: Subscribing for Notification >>
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). Buy this book now.
|
|
/ 2 
