Home arrow Web Services arrow Page 4 - WS Notification and WS Topics in the WS Resources Framework
WEB SERVICES

WS Notification and WS Topics in the WS Resources Framework


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

Author Info:
By: Sams Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 6
July 13, 2006
TABLE OF CONTENTS:
  1. · WS Notification and WS Topics in the WS Resources Framework
  2. · Subscribing for Notification
  3. · The Subscription WS-Resource
  4. · Topics and Topic Spaces
  5. · TopicPathExpressions
  6. · Rounding Out the XML Model of Topics: aliasRef

print this article
SEARCH DEVARTICLES

WS Notification and WS Topics in the WS Resources Framework - Topics and Topic Spaces
(Page 4 of 6 )

As we mentioned earlier, a notification producer organizes the situations and associated notification messages into a collection of topics g. Subscribers use a topic expression to indicate which topic or set of topics they're interested in subscribing to. Because topics are central to the way situations and notification messages are associated, the WS-Topics specification of WS-Notification defines an XML model for topics.

Topics

A topic is a category of notification message; it's an organizational structure superimposed on all the notification messages produced by a notification producer. This organization allows the notification producer to declare the kinds of situations for which it produces notification messages, and therefore allows the requestor to understand what it can subscribe for. So, you can think of a topic as a channel associated with a particular kind of notification message. Subscribers can tune into this channel by subscribing to that topic. When a notification message is published on the topic, any notification consumer subscribed to that topic will receive a copy of that notification message.

Topics are organized hierarchically, forming a topic tree. A topic tree organizes a family of related topics and child topics. Each topic tree has a root topic.

Consider the following example from a customer-relationship management (CRM) system using WS-Notification. The system is responsible for detecting various customer contact situations (customer calls to complain or make an inquiry, customer is contacted by a sales person, customer uses a Web service to place an order, and so on). Various other applications are interested in receiving notifications when certain situations occur, such as a VIP customer calling with a complaint. Topics are used to organize these situations into recognizable categories, making the job of subscribing for particular situations easier.

As part of our CRM topics, we can model a telephoneContact topic that is the root topic for all topics related to telephone contacts. There might be several subcategories of telephone contact that we can model as child topics, including inquiry, complaint, and orderPlacement. These subtopics are organized as child topics of the telephoneContact root topic as depicted in Figure 8.4.

Figure 8.4  An example topic tree

The hierarchical relationship among the topics is represented by the following XML:

<wstop:Topic name="telephoneContact">
<wstop:Topic name="inquiry" .../>
<wstop:Topic name="complaint" ... />
<wstop:Topic name="orderPlacement" ... />
</wstop:Topic>

The topic named telephoneContact has three child topics, each represented by a child topic element. Any of these child topics can have child topics, and so on. The only restriction is that child topic elements must have different names. The names don't have to be unique within the topic tree—they just have to be unique among sibling topics (topics that share the same parent topic). Typically, you don't see more than three or four levels of nesting; many topic trees are made up of the root topic and nothing more.

The XML model for topics is more than just the hierarchical relationship between topics—each topic can be described with additional information. This additional information allows the user of the topic XML to understand more about the topic. The XML model for topics is used by notification designers to communicate a set of topics and the meta-data associated with them. Designers of applications that are WS-Notification subscribers or consumers use the XML model of topics to help determine what are reasonable topic expressions to include in subscribe operations.

The following XML is a more richly detailed topic description for our CRM application:

 <wstop:topic name="telephoneContact">
<wstop:topic name="inquiry" 
messageTypes="crm:inquiryNotification"/>
<wstop:topic name="complaint" 
messageTypes="crm:complaintNotification"
final="false"> <wstop:documentation> Note: all complaints, including VIP customer
complaints appear on this topic. </wstop:documentation> <wstop:topic name="VIPComplaint" messageTypes="crm:complaintNotification"
final="false"> <wsrp:QueryExpression dialect="http://www.w3.org/TR/1999/REC-xpath-
19991116" > boolean(/*/customer/@customerStatus="vip") </wsrp:QueryExpression> <tns:VIPHotline>555-1212</tns:VIPHotline> </wstop:topic> </wstop:topic> <wstop:topic name="orderPlacement"> <wstop:AliasRef dialect= "http://www.ibm.com/xmlns/stdwip/web-services/
WS-Topics/TopicExpression/ concreteTopicPath" > crm:orderContact </wstop:AliasRef> </wstop:topic> ...

The topics modeled here show most of the facilities available in the WS-Topics XML model of topics. The topic named complaint has two attributes, messageTypes and final. The messageTypes attribute describes the kind of message that is associated with this topic. The value of this attribute can be a list of QNames, each corresponding to a global XML element declaration. The purpose of this attribute is to scope the contents of notification messages associated with the topic. Each message associated with this topic must be an element corresponding to a global XML element identified by one of those QNames. This example includes only one QName, indicating that all notification messages associated with the complaint topic are crm:complaintNotification messages. Designers that have access to the XML Schema declaration for the namespace identified by the crm prefix will understand the contents of messages on the complaint topic. (It's okay that the topic space and the XSD share the same namespace; it's common for a WSDL definition and an XSD definition to share the same namespace.) The messageTypes information is extremely helpful to design the proper selector expressions to filter messages on a subscribe request. The final attribute indicates whether it's possible to add topic children to the topic that aren't already defined by the topic XML model. In this case, the value of final is false, meaning that it's possible to add child topics dynamically to the complaint topic.

The topic model allows topics to contain documentation elements. This allows designers of topics to describe, using human languages like English, extra information to be interpreted by other developers. You see this used in the complaint topic to give extra details about the relationship between the complaint topic and its child topic named VIPComplaint.

The child topic VIPComplaint demonstrates two additional features of the XML model of topics in WS-Notification: open content and message patterns. The messageTypes attribute and the final attribute are repeated. There is no model of attribute inheritance from parent topic to child topic in this model. If the messageTypes attribute doesn't appear in the VIPComplaint topic, then the value xsd:any is assumed (the developer should expect that any kind of XML notification message may appear on that topic). Similarly, if the final attribute is missing, the default value is false.

The QueryExpression child element is used to describe a message pattern or further constraints on the type of message associated with the topic. Although the messageTypes attribute helps define constraints on the message, sometimes it's too coarse grained. In many circumstances, a pattern on the content (not just the type) of message should be further described. In the example of VIPComplaint, the designer can be more precise in describing the messages associated with the topic. In this case, the message is a crm:complaintNotification message but further constrained to guarantee to the subscriber that the value of the customerStatus attribute of the customer element of the crm:complaintNotification message contains the value vip. The message pattern is expressed by a QueryExpression from the WS-ResourceProperties specification described earlier.

The XML model for topics also allows the topic element to contain attributes from other XML namespaces and elements defined in other namespaces. This is typical open content that you see used in many places in Web services (WSDL, for example). The VIPComplaint topic uses this to associate a VIPHotline piece of information with this topic. The meaning of this element is dependent on the application for which the topic is defined.

Topic Spaces

We mentioned that topics are organized into topic trees, each topic tree having a root topic and many topic trees having a rich hierarchy of child topics. Topic trees are also organized, into topic spaces. A topic space works in a way similar to namespaces in XML Schema. A topic space associates topic trees with a namespace; that way, each topic tree can be uniquely identified by the QName of the root of the topic tree.

A topic space document for the CRM example we've been describing appears as follows:

<?xml version="1.0" encoding="UTF-8"?>
<wstop:TopicSpace name="CRMTopicSpace" 
targetNamespace="http://.../CRMexample" 
xmlns:crm="http://.../CRMexample"
xmlns:tns="http://.../AnotherNamespace"
xmlns:wstop=
"http://www.ibm.com/xmlns/stdwip/web-services/
WS-Topics" xmlns:wsrp= "http://www.ibm.com/xmlns/stdwip/web-services/
WS-ResourceProperties" > <wstop:documentation> This is an example TopicSpace definition for a
CRM (customer relationship management) application. </wstop:documentation> <wstop:Topic name="telephoneContact"> <wstop:Topic name="inquiry" .../> <wstop:Topic name="complaint" ... /> <wstop:Topic name="orderPlacement" ... /> </wstop:Topic> <wstop:Topic name="emailContact"> ... <wstop:Topic name="orderContact"> ... </wstop:TopicSpace>

In this case, the topic space is named CRMTopicSpace and is associated with the namespace http://.../CRMexample. This is much like an XSD file associating a collection of XML Schema element and type definitions with a target namespace or a WSDL document associating WSDL definitions with a target namespace. Don't worry about the name of the topic space; that's just documentation. The important part is the target namespace. All the topics defined in this document will be associated with the namespace identified by the target namespace attribute.

This topic space document defines three topic trees, rooted by telephoneContact, emailContact, and orderContact. Root topics appear as child elements of the topic space element. And just like child topics, each root topic must have a unique name within the namespace. Because root topic names are unique within a topic space, root topics can be identified uniquely by QName. So, the QName crm:telephoneContact uniquely identifies the telephoneContact root topic within the namespace corresponding to the crm prefix. Similarly, crm:emailContact and crm:orderContact can be used to reference the other topic trees in this topic space. All topics are identified relative to their root topic, using hierarchical path syntax. The VIPComplaint topic is identified by the following path: crm:telephoneContact/complaint/VIPComplaint.

Topic spaces can also have documentation elements, and they can contain attributes and elements from other namespaces.

The final topic space document for the CRM example appears as follows:

<?xml version="1.0" encoding="UTF-8"?>
<wstop:TopicSpace name="CRMTopicSpace" 
targetNamespace="http://.../CRMexample" 
xmlns:crm="http://.../CRMexample"
xmlns:tns="http://.../AnotherNamespace"
xmlns:wsnt=
"http://www.ibm.com/xmlns/stdwip/web-services/
WS-BaseNotification" xmlns:wsrp= "http://www.ibm.com/xmlns/stdwip/web-services/
WS-ResourceProperties" > <wstop:documentation> This is an example TopicSpace definition for a
CRM (customer relationship management) application. </wstop:documentation> <wstop:Topic name="telephoneContact"> <wstop:Topic name="inquiry" messageTypes="crm:inquiryNotification"/> <wstop:Topic name="complaint" messageTypes="crm:complaintNotification"
final="false"> <wstop:documentation> Note: all complaints, including VIP customer
complaints appear on this topic. </wstop:documentation> <wstop:Topic name="VIPComplaint" messageTypes="crm:complaintNotification"
final="false"> <wsrp:QueryExpression dialect="http://www.w3.org/TR/1999/
REC-xpath-19991116" > boolean(/*/customer/@customerStatus="vip") </wsrp:QueryExpression> <tns:VIPHotline>555-1212</tns:VIPHotline> </wstop:Topic> </wstop:Topic> <wstop:Topic name="orderPlacement"
aliasRef="crm:orderContact" /> </wstop:Topic> <wstop:Topic name="emailContact"
messageTypes="crm:emailContact" /> <wstop:Topic name="orderPlacement"> <wstop:AliasRef dialect= "http://www.ibm.com/xmlns/stdwip/web-services/
WS-Topics/TopicExpression/ concreteTopicPath" > crm:orderContact </wstop:AliasRef> </wstop:Topic> </wstop:TopicSpace>

Who creates a topic space definition? Normally, whatever authority owns or defines the target namespace. This is similar to the question of who defines an XML Schema definition (XSD) for a namespace. Sometimes it's a standards organization or an industry association; sometimes it's an organization that wants to put a stake in the ground and establish some sort of interoperability.

But the question still remains, where does the requestor find this topic space document? WS-Notification doesn't specify how this is done. Sometimes the document is published on the Web site of the organization controlling the namespace. Sometimes the topic space document is available in an XML registry or repository. Sometimes the topic space is available as a result of a Web service request, such as a variant on the WS-Meta-dataExchange operation, or perhaps made available as a resource property of a notification producer.

WS-Notification also defines an ad hoc topic space to allow dynamic, on-the-fly topics to be described without modeling them explicitly in a topic space (and therefore assigning them to a particular namespace). The ad-hoc topic space is a well-defined namespace with the following URI: http://www.ibm.com/xmlns/stdwip/web-services/WS-
Notification/adHoc
. You should use this topic space with caution because there is no way for the subscriber to know beforehand about it or about topics defined within it. It should be used only for dynamic topics where there is additional out-of-bands communication of topic meta-data between the notification producer and subscribers.


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