Applying the Service Monitor Approach

Service Monitor automatically detects the production system services as the devices hosting them are activated. If Service Monitor is deployed after the domain services, it discovers them during the automatic discovery process included in the Service Monitor initialization phase.

The WSDL documents published by the production system services specify no OWL-S processes. Instead, the WSDL operations include SAWSDL annotations referring to SWRL rules defined in the TBox. Therefore, when Service Monitor discovers, for example, the robot service, it generates an OWL ontology containing OWL-S processes that correspond to the robot WSDL operations. The OWL-S generation approach is based on SAWSDL annotations and its details are described in Section 3.5.

For all of the robot service instances except robot 1, the OWL-S process derived from the EquipmentChangeState WSDL notification operation includes three out-put parameters, which correspond to different components of the operation outout-put message. Table 5.4 lists the output parameters, the types of their values, and their definitions.

Service Monitor derives the types for the OWL-S process parameters from the SAWSDL annotations of the XML schema type definitions used by the attributes in the WSDL operation output message. While the message schema includes a few other attributes, Service Monitor ignores them in the OWL-S derivation, since they contain no SAWSDL annotations.

While robot 1 provides no assembly operations, it enables the transport of product templates between the pallet occupying its processing location and the product template storages. Therefore, the XML schema in the robot 1 WSDL document contains no attribute indicating the performed operation, and the OWL-S process derived from the notification operation includes only the first two of the outputs

Table 5.4: TheEquipmentChangeState OWL-S process has three output parameters.

Output Name Type Description

EquipmentChangeStateOutput1 RobotStatus (OWL) The current robot sta-tus.

EquipmentChangeStateOutput2 RobotStatus (OWL) The previous robot status.

EquipmentChangeStateOutput3 Operation (OWL) The performed opera-tion.

5. Application Experiments 121 listed in Table 5.4.

Once Service Monitor has derived the OWL-S descriptions for the discovered robot services, it extracts domain model update rules from the OWL-S processes representing the robotEquipmentChangeState WSDL notification operations. Thus, for the robot 1 service, Service Monitor extracts one update rule with two conditional effects and two rule variables. The condition and effect expression language used in the OWL-S descriptions may be either SPARQL or SWRL, depending on the cur-rent Service Monitor settings. In the former case, the expressions are all SPARQL ASK queries, and therefore Service Monitor directly copies the condition expres-sions into the rule objects and translates the effect expresexpres-sions to SPARQL/Update expressions. In the sequel, however, it is assumed that Service Monitor has been configured to generate SWRL expressions.

Table 5.5 shows the condition and effect expression for the OWL-S process result representing the case that robot 1 unloads the current product template from the pallet to the output storage and loads a new template from the input storage onto the pallet. While the first table column shows the SWRL condition expression on the first row and the effect on the second row, the second table column shows the SPARQL expressions to which Service Monitor translates the condition and effect during the extraction of the update rule object models. While the SWRL expressions embedded into the OWL-S documents are expressed in XML, the table shows them as plain text for the sake of brevity. The symbol namespaces are omitted in the table except for theswrlb namespace prefix denoting the namespace of SWRL built-ins. The condition and effect expressions refer to the output parameters and the corresponding notification variables by name.

Figure 5.26 shows the Service Monitor GUI displaying goal process statuses. In the figure, only one goal process has been created, and it is currently running. The top part of the GUI window displays the number of semantic web services discovered.

In the situation displayed, the number includes the 22 domain web services as well as Ontology Service and Service Monitor itself. The lower left part of the window shows the SPARQL ASK query representing the goal to be achieved. Service Monitor has composed a solution plan consisting of a sequence of 43 web service operation invocations, of which it has already invoked the first seven. While Service Monitor executes the plan, it monitors the event notifications sent by the domain services and updates the domain model accordingly. Service Monitor proceeds to the next operation invocation in the sequence only when it detects that the previous operation has caused the expected effects on the domain model.

As the update rules used by Service Monitor are automatically derived and uned-itable, there is no need to explicitly activate Service Monitor similarly to Ontology Manager. Instead, Service Monitor is typically in an active state and reacts to event

5. Application Experiments 122

Table 5.5: Service Monitor converts result conditions and effects from SWRL to SPARQL.

SWRL Expression SPARQL Expression

(The same as the query body in the above ASK query.)

}

notifications from the domain services by applying the corresponding update rules.

5. Application Experiments 123

Figure 5.26: Service Monitor simultaneously applies ontology update rules during domain web service invocation.