Exploring WS-Notification

Building a scalable domotic infrastructure

Marco is assistant professor and head of the Distributed Systems and Service-Oriented Computing research program at DIT, University of Trento, Italy. He can be reached at [email protected]. Manuel and Alessandro are undergraduate students in the Informatics curricula and can be reached at [email protected], and alessandro [email protected], respectively.

Home appliances are evolving at a pace well beyond the capabilities designers of X10—a standard that uses powerlines to remotely control home devices—ever expected. Equipping home devices with processors and wireless connectivity has become affordable and painless, thanks in part to wireless connectivity Standards such as GSM, GPRS, Wi-Fi (IEEE 802.11), Bluetooth (IEEE 802.15.1), and ZigBee (IEEE 802.15.4).

Still, one of the challenges users face is having devices that make proper use of this communication infrastructure. What are appropriate messaging schemes for these loosely coupled autonomous devices? How can these devices discover each other and interact? Interestingly, XML-based web services offer an answer to this question.

In this article, we will examine WS- Notification, a web-service publish/subscribe protocol that we apply to a "domotic" living environment for elderly adults. In particular, we use WS-Notification to integrate different sensors and actuators in a home environment, with the goal of detecting life-threatening situations, such as when elderly inhabitants of the home fall.

WS-Notification

WS-Notification is a web-service protocol that defines a standard approach to notification via a topic-based publish/subscribe mechanism (http://www-106.ibm.com/developerworks/library/specification/ ws-notification/). In particular, it includes three distinct specifications:

• WS-BaseNotification defines web-service interfaces for notification producers and notification consumers. Operational requirements and message structure for producers and consumers are fully defined in this specification. This is the basic point-to-point communication mechanism.
• • WS-BrokeredNotification defines the web-service interface for the notification broker—an intermediary that allows publication of messages from service providers and other entities. Operational requirements and message structure for producers and consumers are fully defined in this specification. This is the heart of the notification service.
• • WS-Topics defines a mechanism to organize and categorize items of interest for subscription known as "topics" into a tree structure. The specification determines the form of the subscription expression as well as the form of the metadata to be added to topics.

With WS-Notification, you have standard ways for creating an ontology of topics for describing events, a communication mechanism between event producers and consumers, and a policy for subscriptions and event forwarding. In short, WS-Notification lets you build platform-independent scalable systems made of autonomous nodes asynchronously exchanging messages—exactly what you need in the context of domotics.

The WS-Notification Server

The WS-Notification server we present here consists of five modules (Figure 1). The rule engine is for event triggering. The various home sensors transmit lots of raw data that is transformed by appropriate rules into more meaningful events. Notifications of events are sent to the WS- Notification interface, which implements the WS-BrokeredNotification specifications. These rely on the WS-Topics, implemented in the Event Tree module. All the active registrations and a log of passed registrations are handled by the Registration Tree module. Event subscriptions can specify conditions to be verified before event forwarding. These conditions (classified by the standard in preconditions for event generations and selectors for event subscriptions) are handled by an appropriate Precondition Parser.

We have deployed the WS-Notification server in a home with the goal of monitoring elderly citizens and detecting if they fall. Indeed, one of the most common accidents in the aging population is the accidental fall that, especially if undetected, may have dangerous effects. In Great Britain, accidental falls constitute about 30 percent of the home accidents of people over 65. A number of sensors can be used to detect this hazardous situation; for instance, one can place an array of infrared sensors at the floor level, one can equip the person with an accelerometer, or one can use fixed cameras. With the notification server, we can actually combine more sensors to reduce the amount of false positives. In particular, we use a custom-made accelerometer built by ITC-irst (http://www.itc.it/irst/) and standard fixed video cameras. State-of-the-art posture-recognition software built by CNR-IMAG lecce (http:// www.imm.cnr.it/) analyzes the images and classifies postures into three main categories: standing, sitting, and laying. The rule engine fuses the data from the accelerometer and image-analysis software, and identifies potentially dangerous situations. The information of each sensor taken alone is not enough to detect a fall with an acceptable reliability.

Listing One is the topic tree we consider for this case (simplified for this article). It is a simple two-level tree in which the Health category is divided into two subcategories: Fall and Irregular Heartbeat. The topic tree is a dynamic structure that can be modified at runtime. Dynamic changes may occur when it is necessary to take into account new events without interrupting normal operation; for instance, when new sensors are placed in the home. This feature is implemented in our system, even though it is not used in the fall-detection scenario.

Any event consumer implementing the WS-Notification specification can subscribe to health events. We use a PDA with a wireless connection in the hands of a nurse or relative who can intervene immediately in case of a fall.

Implementation

The topic tree is a hierarchical structure of the events. The root of the tree is called event and represents the entire set of the events that can occur. In Listing One, you can see the instance of the topic tree that we use in our example scenario. In this tree, the most important node of the tree is the one that represents the Fall event, son of Health event. The events Topics and MySubscribedEvents communicate service information between subscribers and the server. Once the topic tree is defined in the server, the event broker has only to wait for a notification or a subscription on an event in its domain. The waiting is a standard server loop listening on a specific port:

Socket info;
ServerSocket ss =
new ServerSocket(Property.listeningPort);
while (true){
info = ss.accept();
RegisterSubscriptionNotifyThread
registerSubscriptionNotifyThread=
new RegisterSubscription-
NotifyThread
(info,eventSubscriptionTree);
registerSubscriptionNotifyThread.start();
}

Now suppose that the user of the PDA wants to subscribe to a specific event. To do so, a number of parameters need to be specified. First, the address of the client that receives the event notifications. This is done via the message structure:

<wsnt:ConsumerReference>
<wsa:Address> hostName:port
</wsa:Address>
</wsnt:ConsumerReference>

where hostName is the client's host name, and port is the default port on which the client is waiting for message notification.

Second, you must choose the event to subscribe to. The way to express the event name is specified in the topic expression dialect exposed by the broker. In this case, we insert the tag:

<wsnt:TopicExpression dialect=
"myDialect" xmlns:esns=
"eventServerNamespaceURI">
"esns:eventPath"
</wsnt:TopicExpression>

where myDialect is the reference to where the topic expression dialect is, and eventPath is the name of the event expressed following that dialect.

Third, you have to specify an expiration time for the subscription. The expiration time is not a mandatory parameter to provide. If it is not specified, the default value is infinite; that is, the subscription will not expire. The format for expiration is:

<wsnt:InitialTerminationTime>
xmlDate
</wsnt:InitialTerminationTime>

where xmlDate is the date and time (and timezone) expressed as standard XML Schema type.

Finally, you can also specify precondition and selector parameters. These determine the conditions under which the notification to the event consumer will take place. Preconditions and selector parameters are expressed using the XML Path Language grammar (http://www.w3.org/TR/1999/REC-xpath-19991116.html). We don't use these in this example.

When the event broker receives a subscription for a particular event, it stores it into an appropriate repository. Instead of a database here, we use an XML file that is similar to the topic tree. The idea is to augment the topic tree with a line for every subscription. Listing Two shows the topic tree with a subscription to the Fall event. This is represented by:

<esns:Address name="127.0.0.1:1234"
end="1103934000750"
id="11020014327817175" />

The esns:Address tag comprises three attributes: name, id, and end. The attribute name represents the host name or address of the subscriber. The attribute id is mandatory and a unique identifier of the subscription. Finally, end is the attribute storing the expiration date of the subscription expressed in milliseconds departing from January 1, 1970.

Suppose that the accelerometer has recorded a strong acceleration and concurrently the video cameras indicate that the posture of the elder is laying down. This pattern is interpreted by the rule engine as the occurrence of a fall and triggers a falling event to the WS-Notification interface. The publication of this event means that the WS-Notification server checks the event registration data repository (Listing Two). If there exist one or more subscribers for the event, as it is in our case with subscription "11020014327817175," then it checks whether there are any specific conditions to be met (specified in the subscription selector tag). This is not the case for event "11020014327817175." At this point, the server is ready to notify the host 127.0.0.1:1234 that the Fall event has occurred. To do so, it prepares the appropriate WS-Notification message in a Java string; see Listing Three.

Now consider the PDA side of using WS-Notification. First, the PDA queries the server to get the current topic tree. Once received, the user navigates the topic tree from the root. The first two children are Health and Cooking events (Figure 2). Suppose the user chooses the Health event. The event has two topic children: Fall and Irregular Heartbeat (Figure 3). For instance, suppose users are interested in the Fall event and decide to subscribe to it. They are then presented with the Subscription interface (Figure 4) in which they can also make an explicit end time for the subscription. Once completed, the subscription is sent to the WS-Notification server. After the subscription, the client runs a dedicated thread that is listening for a notification. Listing Four is the listening cycle.

When a notification message comes in, the thread forwards the content of the notification to another thread that parses it and takes proper action. In the case of the notification of the Fall event, an alarm goes off on the PDA and a proper message is displayed (Figure 5). Other events that could reach the client are the MySubscribedEvents and the Topics events. These are used by brokers to communicate to users changes in the event hierarchy that, as mentioned earlier, is a dynamic data structure. For instance, a new event could have been added to the topic tree or an event could have expired. The PDA keeps track of the history of the notified events in an appropriate log, which is an augmentation of the current topic tree. This is similar to the topic tree with subscriptions kept by the server and presented in Listing Two.

The PDA and the WS-Notification server also have request/acknowledge interactions. These are the case when the subscriber issues a request or formulates a query. Requests include event subscriptions and unsubscriptions, while the object of a query are checking the status of subscription, the topic tree, or parts of it.

Conclusion

Home networking in general and domotics in particular are applications where WS-Notification can be successfully applied. While not all home appliances will implement a web-service stack that goes from SOAP messages up to WSDL or even BPEL descriptions, many will aggregate home functional units and offer interfaces for the external world (and vice versa). Home sensor networks will have different forms of computationally less-expensive communication and will use web-service-ready devices as gateways for higher level communication.

Acknowledgment

We are thankful to Paolo Busetta of ITC-irst, Trento, Italy, for inspirational discussion and for improving the quality of this article.

DDJ

Listing One

<?xml version="1.0" encoding="UTF-8"?>

<wstop:topicSpace name=
       "Event" targetNamespace="event broker namespace URI" 
        xmlns:esns=" event broker namespace URI " 
        xmlns:wstop="http://www.ibm.com/xmlns/stdwip/web-services/WS-Topics" >
    <wstop:topic name="Topics" final="true" />
    <wstop:topic name="MySubscribedEvents" final="true" />
    <wstop:topic name="Health" >
        <wstop:topic name="Fall" />
        <wstop:topic name="Irregular heartbeat" />
    </wstop:topic>
</wstop:topicSpace>

<?xml version="1.0" encoding="UTF-8"?>
<wstop:topicSpace name=
      "Event" targetNamespace="my event broker namespace URI" 
       xmlns:esns=" event broker namespace URI" 
       xmlns:wstop="http://www.ibm.com/xmlns/stdwip/web-services/WS-Topics" >
    <wstop:topic name="Topics" final="true" />
    <wstop:topic name="MySubscribedEvents" final="true" />
    <wstop:topic name="Health" >
        <wstop:topic name="Fall">
           <esns:Address name="127.0.0.1:1234" 
                 end="1103934000750" id="11020014327817175" />
</wstop:topic name="Fall">
        <wstop:topic name="Irregular heartbeat" />
    </wstop:topic>
</wstop:topicSpace>

Socket resp=new Socket(hostAddress,port);
PrintStream ps=new PrintStream(resp.getOutputStream());

String response="<s12:Envelope";
response=response+"xmlns:s12=\""+Property.s12+"\" ";
response=response+"xmlns:wsa=\""+Property.wsa+"\" ";
response=response+"xmlns:esns=\""+Property.esns+"\" ";
response=response+"xmlns:wsnt=\""+Property.wsnt+"\">\n";
response=response+"<s12:Header>\n";
response=response+"<wsa:Action>\n";
response=response+" 
  http://www.ibm.com/xmlns/stdwip/web-services/WS-BaseNotification/Notify\n";
response=response+"</wsa:Action>\n";
response=response+"</s12:Header>\n";
response=response+"<s12:Body>\n";
response=response+"<wsnt:Notify>\n";
response=response+"<wsnt:NotificationMessage>\n";
response=response+"
         <wsnt:Topic dialect=\""+Property.topicExpressionDialect+"\">\n";
response=response+"esns:"+topic+"\n";
response=response+"</wsnt:Topic>\n";
response=response+"<wsnt:Message>\n";
response=response+message+"\n";
response=response+"</wsnt:Message>\n";
response=response+"</wsnt:NotificationMessage>\n";
response=response+"</wsnt:Notify>\n";
response=response+"</s12:Body>\n";
response=response+"</s12:Envelope>\n";
ps.println(response);

while(true) {
   try {
    errCode++;
    scn = (ServerSocketConnection)Connector.open
                   ("socket://:"+app.myDefaultPort);
    errCode++;
    sc = (SocketConnection)scn.acceptAndOpen();
    errCode++;
    is = sc.openInputStream();
    errCode++;
    while((c = is.read())>=0){
     incoming = incoming+(char)c;
    }
    ParsingManager pman = 
            new ParsingManager(incoming, null, this.app, this.eventsTree);
    pman.start();
    incoming = null;
    errCode++;
    is.close();
    errCode++;
    sc.close();
    errCode++;
    scn.close();
    errCode++;
   } catch(Exception e) {
    String errMsg = null;
    switch(errCode) {
       case 1: errMsg = "Failed while opening server socket connection!";
       break;
       case 2: errMsg = "Failed while waiting for an incoming connection!";
  break;
  case 3: errMsg = "Failed while opening input stream!"; break;
     case 4: errMsg = "Failed while reading an incoming message!"; break;
     case 5: errMsg = "Failed while closing input stream!"; break;
     case 6: errMsg = "Failed while closing socket connection!"; break;
     case 7: errMsg = "Failed while closing server socket connection!";
 break;
  }
  Alert a = new Alert("Error!", errMsg, null, AlertType.ERROR);
  a.setTimeout(3000);
  app.d.setCurrent(a);
}