Web Services Eventing (WS-Eventing) - Deploying Web Services Resource Framework and Web Service

CHAPTER 6 MEASUREMENTS AND ANALYSIS

6.4 Deploying Web Services Resource Framework and Web Services Eventing

6.4.2 Web Services Eventing (WS-Eventing)

A Web Service may benefit from receiving a notification when an event occurs. Instead of checking an event occurrence repeatedly, an entity can be notified by an event source when an event happens. In this paradigm, a service, called as subscriber, needs to register itself to a certain interest with another service, called as event source. Web

163

Service Eventing (WS-Eventing) defines a protocol to standardize this effort. A subscription manager can be employed to administer subscriptions. We utilize FIN, an implementation of WS-Eventing [119] from Pervasive Technology Lab. It provides handler based implementation as well as service based implementation2.

The following XML element shows how a sink entity requests a subscription. The request is registered to the Subscription Manager. When a source publishes an event to the topic, /sensor/cal, the sink is notified.

<even:Subscribe>

<even:EndTo>

<add:Address>http://gf3.ucs.indiana.edu:9080/axis/services/WseSink</add:Address>

</even:EndTo>

<even:Delivery mode=

"http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Push"/>

<even:Expires xsi:type="xs:dateTime" xmlns:xs=

"http://www.w3.org/2001/XMLSchema">2007-04-02T22:02:19.495-04:00

</even:Expires>

<even:Filter Dialect=

"http://www.naradabrokering.org/TopicMatching">/sensor/cal</even:Filter>

<even:NotifyTo>

<add:Address>http://gf3.ucs.indiana.edu:9080/axis/services/WseSink</add:Address>

</even:NotifyTo> </even:Subscribe>

An event is carried to the subscriber by an XML document. The following XML element notifies an important activity for a sensor, located California.

<sens:sensor>

<sens:cal>

<sens:number>1</sens:number>

<sens:CurrentTime>2007-03-01T00:41:14.856-05:00</sens:CurrentTime>

<sens:Location>california</sens:Location>

<nar:Application-Content>Tracker 1 : Important activity happened</nar:Application-Content>

</sens:cal> </sens:sensor>

164

6.4.3 Environment

A computer cluster is utilized for this experiment. It contains 8 machines having the same features. They share Local Area Network to communicate each other and utilize Fedora Core release 1 (Yarrow) in Intel Xeon CPU running on 2.40GHz and 2GB

memory.

Before starting benchmarking, the initializations of the specifications are completed. Sink registers itself to the topic /sensor/cal and sensor satateful resource stores the initial information. Most importantly, the suitable massages are selected, one from WS-Eventing and one from WSRF. These messages are combined to create a new message in order to run WSRF and WS-Eventing handlers in a parallel manner. Several technical problems originating from the implementations of the specifications have been witnessed during this procedure, though. The following SOAP message is the created combined message for the experiment:

<wsewsrf:wsrf>

<wsa:To

mustUnderstand="1">http://gf4.ucs.indiana.edu:8080/wsrf/services/sensor</wsa:To>

<wsa:Action

mustUnderstand="1">http://ws.apache.org/resource/example/sensor/SensorPortType/you rWsdlRequestName</wsa:Action>

<sn:ResourceIdentifier

mustUnderstand="1">/sensor/cal/1</sn:ResourceIdentifier>

</wsewsrf:wsrf>

165 <top:Topic>/sensor/cal</top:Topic>

<add:MessageID>c3e00553-db0c-4ae0-965a-a59183ed3761</add:MessageID>

<add:From>

<add:Address>http://gf4.ucs.indiana.edu:8080/wsrf/services/sensor</add:Address>

</add:From> </wsewsrf:wse> </Header> <Body> <wsewsrf:comb> <sens:sensor> <sens:cal> <sens:number>1</sens:number> <sens:CurrentTime>2007-03-01T00:41:14.856-05:00</sens:CurrentTime>

<sens:Location>california</sens:Location>

<nar:Application-Content>Tracker 1 : Important activity happened</nar:Application-Content> </sens:cal> </sens:sensor> <wsrp:SetResourceProperties xmlns:wsrp="http://docs.oasis- open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-01.xsd" xmlns:sn="http://ws.apache.org/resource/example/sensor"> <wsrp:Update> <sn:Options>

<sn:Option>Do we need to restart this?</sn:Option>

<sn:Option>yes</sn:Option>

<sn:Option>Do we need to keep previous month data?</sn:Option>

<sn:Option>no</sn:Option>

<sn:Option>Is it necessary to inform the people if abnormal activity is observed?</sn:Option>

<sn:Option>yes</sn:Option>

</sn:Options> </wsrp:Update> </wsrp:SetResourceProperties> </wsewsrf:comb> </Body> </Envelope>

The message above notifies an important activity and updates information for a sensor stateful resource. When it is received, WS-Eventing source handler looks for the subscription manager service to find out the interested subscribers. Then, it delivers the event to the sinks, the interested subscribers. While notification is happening, WSRF

166

handler also updates the values of the states, which are kept in storage, and forwards the information with the additional data previously stored.

6.4.3.1 Deploying the specifications for Apache Axis

Specifications are, first, deployed for Apache Axis. Every single request is observed 100 times. Handlers and service endpoint utilize a single computer. The remaining components of the specifications are hosted by the individual computers in the cluster. The logical deployment is depicted in Figure 6-28.

Web Service Logic WS-RF Handler WS- Eventing Source Handler WS-Eventing Components WSRF Components

Figure 6-28: Sequential Execution of WSRF and WS-Eventing

6.4.3.2 Deploying the specifications for DHArch

The environment to execute WS- Eventing and WSRF is also created for DHArch.WS-Eventing requires individual computers for its components; Sink Source and Subscription Manager. Hence, they are located to the separate computers. Similarly, WSRF as well as NaradaBrokering are located into the individual computers in the cluster. Finally, the service endpoint is placed its location in the cluster. The deployment can be portrayed as in Figure 6-29.

167 Web Service Logic WSRF Handler WS- Eventing Source Handler WS-Eventing Components WSRF Components DHArch

Figure 6-29 : Parallel Execution of WSRF and WS- Eventing

In document DISTRIBUTED HANDLER ARCHITECTURE (Page 179-184)