Light Tower Example

This experiment scenario describes the orchestration of a process using the domain web service representing a tower of three light segments described in Section 5.1.1.

The equipment ontology for the light tower web service contains a simple class hierarchy, which represents the three types of light segments, and the functional data type property isOn, which links each light segment to a Boolean value representing the power state of the segment. The object property hasSegment links the sin-gle LightTower individual to the three individuals representing the light segments.

Figure 5.17 illustrates the contents of the equipment ontology.

The PC-based services are deployed by running separate Java applications. In ad-dition, four orchestration support services are deployed: Ontology Manager, which updates the semantic model hosted by the Ontology Service, Orchestration Engine, which executes the BPEL process functioning as the orchestration instructions for this scenario, and Service Monitor, which assists the Orchestration Engine in ini-tializing the partner links in the BPEL process.

The BPEL process developed for this experiment operates the light tower device so that it implements the logic of traffic lights. That is, the device continuously iterates through the four states typical to traffic lights in Finland. The BPEL process includes delays to add a fixed duration to each state. In particular, the state where only the red light is on continues for ten seconds, the state where both the yellow and red lights are on for three seconds, the state where only the green light is on for seven seconds, and the state where only the yellow light is on continues for three seconds, after which the system returns to the state where only the red light is on.

Before the Orchestration Engine begins executing the BPEL process, it uses Ser-vice Monitor to find appropriate matches for the partner links representing the aforementioned web services. The BPEL process first contains an Invoke activity to request Ontology Service to load the equipment ontology. Then, the process invokes

5. Application Experiments 102

Listing 5.2: These SPARQL/Update operations modify the equipment ontology to reflect that the green light segment is lighted.

PREFIX tower: <http://www.ontologies.com/LightTower.owl#>

SELECT ?value {

tower:RedSegment_1 tower:isOn ?value . }

Listing 5.3: This SPARQL query retrieves the current state of the red light segment.

the ScanNetwork operation of Ontology Manager to cause Ontology Manager to subscribe to all event notifications sent by the light tower service. In addition, the process sets the update rules for Ontology Manager by invoking itsSetUpdateRules operation and activates them by invoking the SetActivityState operation. In the light tower scenario, six update rules are required. While three of the rules are intended for reacting to the event that one of the light segments is activated, three are intended for reacting to the event that a segment is deactivated. Then, each time a light segment changes state, Ontology Manager receives a notification and requests the Ontology Service to update the equipment ontology accordingly. Each ontology update request contains a SPARQL/Update statement which the Ontol-ogy Service executes to modify the semantic model. For example, when the light tower service sends a notification message informing that the green segment has been lighted, Ontology Manager requests Ontology Service to execute the SPAR-QL/Update statement in Listing 5.2.

The BPEL process executed by Orchestration Engine invokes Ontology Service to determine the status of each light segment. It obtains the state information by requesting the Ontology Service to execute SPARQL SELECT queries such as the one in Listing 5.3. Then, the process requests the light tower service to activate or deactivate individual light segments so that the light tower enters the next traffic light state in the cycle.

Figure 5.18 shows a sequence diagram representing the interaction of the five web services in the experiment scenario. All of the components and relations in the figure directly correspond to the more general components in Figure 3.2. In

5. Application Experiments 103

Figure 5.18: The light tower experiment sequence corresponds to the more general pattern depicted in Figure 3.2.

this example scenario, the light tower service is the only domain web service. The initialization of Ontology Service and Ontology Manager has been omitted from the diagram because it is performed similarly as in Figure 3.2.

Similar experiments have been performed using an alternative light tower web service interface. The alternative interface contains the composite operations Set-ComplexStatus and ComplexStateChanged. The former is a request-response type operation that makes it possible to set the states of all three light segments si-multaneously, while the latter is an event notification sent by the service when the former operation has been invoked. The notification carries the new state informa-tion of all three light segments. The interface has been implemented for the light tower web service based on the S1000 controller. When the alternative interface is used, the BPEL process, which forms the execution logic of Orchestration Engine, can be modified to use the new composite request-response operation. In addi-tion, the ontology update rules must be modified, and the WSDL description of the

5. Application Experiments 104

Figure 5.19: The BPEL process invokes fewer operations when using the alternative light tower service interface.

new interface must also be enriched with semantic information through the use of SAWSDL and OWL-S. Nonetheless, creating the semantic service description is less elaborate in this case, because the number of operations, and hence the number of generated OWL-S Process descriptions, is smaller. The sequence diagram of Fig-ure 5.18 also applies to the alternative light tower service interface, except that to change the states of the light segments, only theSetComplexStatus operation needs to be invoked instead of the operations SwitchRed, SwitchYellow and SwitchGreen.

In addition, only one notification is received after invoking the operation, namely ComplexStateChanged, instead of the notifications RedStateChanged, YellowState-Changed and GreenStateChanged. Ontology Manager compares the notification to the conditions of the update rules and sends update requests to Ontology Service.

The scenario is illustrated in Figure 5.19.