The Service Monitor Approach

Service Monitor is a web service that maintains a semantic web service database. It discovers semantic web services and stores their OWL-S descriptions. Then, when

3. Methods 52 theFulfilGoal operation is invoked, Service Monitor attempts to compose the OWL-S processes and executes the composition to fulfill a production goal [84]. OWL-Similarly to Ontology Manager, Service Monitor provides both a graphical user interface and a web service interface. The former interface facilitates direct user interaction, while the latter allows Service Monitor to act as a support service for other software-based actors. In addition, Service Monitor subscribes to event notifications from semantic web services, so that it may send update requests to Ontology Service.

After detecting a semantic web service, Service Monitor automatically reads the service WSDL document and the potential OWL-S description of the service. If the WSDL operations have SAWSDL annotations referring SWRL rules, Service Monitor generates the OWL-S processes based on the SAWSDL annotations in the WSDL document. Finally, Service Monitor extracts semantic update rule object models from the generated OWL-S descriptions.

The OWL-S derivation approach is based on SAWSDL annotations. In particular, Service Monitor generates one OWL-S process for each WSDL operation, and one OWL-S Process Result for each SWRL rule in the SAWSDL annotations of the operation. The result conditions and effects are extracted from the referenced SWRL rule. Furthermore, Service Monitor can be configured to generate the condition and effect expressions using either the SPARQL or SWRL expression language. The details of the OWL-S derivation process and the associated SAWSDL annotation conventions are described in Section 3.5.

Similarly to Ontology Manager, Service Monitor also provides a ScanNetwork operation for discovering all available web services, and Service Monitor connects to an Ontology Service instance, which it attempts to maintain synchronized with the most current domain state. In addition to subscribing to event notifications from web services, Service Monitor creates an object model quite similar to the Ontology Manager update rules from those OWL-S processes corresponding to WSDL notifi-cation operations. In OWL-S, an atomic process that has only output parameters corresponds most closely to a WSDL notification operation [54]. Therefore, Service Monitor converts each such process into a set of semantic notification objects. While Service Monitor could simply use the OWL ontology model containing the OWL-S processes, querying such an ontology at run-time would be slower than accessing the Java object model. Figure 3.8 shows the structure of the extracted notification objects next to the corresponding OWL-S process ontology concepts.

Each semantic notification object groups together a set of conditions and a set of effects that are expected to realize when the conditions hold. The conditions and effects are copied from the source OWL-S process results. In addition, a notification object has a set of notification variables that correspond to the outputs of the OWL-S process. Each variable has a name, type URI, and an XSLT script that

3. Methods 53

Figure 3.8: Service Monitor extracts a notification object model from OWL-S processes representing event notifications.

specifies how to obtain the variable value from the XML content of the notification message. The type URI is copied directly from the parameterType property value of the corresponding OWL-S process output. The XSLT scripts are extracted from the OWL-S atomic process groundings.

Each semantic notification object additionally includes an identifier URI, which is a copy of the OWL-S process URI. The identifier URI is used in identifying those semantic notification objects that may be discarded when a service leaves the network.

Ontology Service can only operate on SPARQL expressions. Therefore, the con-dition expressions in the update rules are SPARQL queries, and the effect expres-sions are SPARQL/Update statements. Thus, if the OWL-S model uses SPARQL and SPARQL/Update to represent condition and effect expressions, the expressions may be copied directly into the generated rule objects. However, as SWRL is also a popular expression language and integrates well with OWL due to its XML syntax, Service Monitor contains an adapter component that translates SWRL condition ex-pressions to SPARQL ASK queries and SWRL effect exex-pressions to SPARQL/Up-date expressions, which Service Monitor then copies into the rule objects gener-ated. Since SWRL property atoms correspond quite directly to SPARQL subject-predicate-object triples, the conversion process is quite straightforward. Table 3.5 summarizes the conversion rules.

Basic SWRL can only express positive conditions and effects, which only require triples to be present in the model or add new triples into the model. Nevertheless, SWRL can be extended by defining new built-ins. Hence, negative antecedents and consequents can be formulated after defining custom built-ins called noValue and remove. The noValue built-in can occur in both conditions and effects, where

3. Methods 54

Table 3.5: SWRL atoms are converted to SPARQL triples and FILTER patterns.

SWRL Entity SPARQL Conversion

Effect atom using the noValue builtin Triple in the DELETE pattern Effect atom using the remove builtin

remove(0)

Triple in the DELETE pattern

(The triple converted from the first con-dition atom)

it either requires that there are no statements matching the argument pattern in the domain model or deletes the matching statements from the model, respectively.

Theremove built-in can only occur in effects and deletes the statements that caused the condition atom at the argument index to match. Both of the aforementioned built-ins are custom SWRL extensions inspired by the descriptions in [37].

Even when the OWL-S descriptions use SPARQL as the expression language for conditions and effects, the expressions may require some processing before they can be inserted into the update rule objects. In particular, if the effect expressions are SPARQL ASK queries, Service Monitor converts them into equivalent SPARQL/Up-date expressions, which are suitable for upSPARQL/Up-date rule effect expressions.

When Service Monitor receives a notification from a domain web service, it re-trieves the corresponding semantic notification object based on the service endpoint URI and notification action path. Then, it obtains the values of the notification variables by applying their XSTL scripts to the received notification message. Ser-vice Monitor inserts the variable names and their values into the ExecuteUpdate-WithMapping request message sent to Ontology Service. In addition, Service Mon-itor copies all of the conditional effects from the semantic notification object to the corresponding slots in the request message structure shown in Figure 3.4. When Ontology Service processes the request, it evaluates each set of condition

expres-3. Methods 55 sions with the specified variable values and executes each set of effect expressions for which the corresponding condition sets evaluate to true. Hence, depending on the current domain model state, a rule may cause no changes in the domain model even if the notification message matches the rule conditions.

While event notifications allow the passive reception of domain status updates, request-response type operations make it possible to actively poll the status of the services. Therefore, Service Monitor has recently been updated to extract similar object models from request-response type operations. However, to receive the re-sponse messages, Service Monitor must actively invoke the operations when it seems probable that the domain model is inaccurate.