Semantic Invocation Service

A central component of the solution to semantic web service discovery during process execution is the semantic invocation service (SISi). Figure7.5 sketches the architecture. It can be seen that a classical layered software architecture (see e. g. [HNS00]) is used. The architecture consists of three layers. A reference implementation of SISi1is provided as OpenSource.

The top layer consists of the “External Interface Component” exposing SISi’s function- ality to external users. It currently, only contains a “Web Service Interface Module”. This module is mostly generated code based on the Apache Axis22 _{web service framework.}

The web service interface is used by the BPEL process server to invoke SISi. SISi itself uses the web service interface module to invoke the discovered web service.

The actual application logic of SISi is available in the “Core Component”. A central “Con- troller Module” receives the semantic service discovery request and uses the “Semantic Discovery Module” to initiate the discovery. In a second step, the controller module uses the “Web Service Invocation Module” to call the discovered web service. Both modules used by the controller are rather small in the current implementation. They mainly forward

1_{http://code.google.com/p/semanticinvocationservice/}

Semantic Invocation Service (SISi)

Semantic Abstraction Component

Semantic Interface Factory Module

WSMX Adapter Module

IRS III Adapter

Module ... External Interface Component

Web Service Interface Module

Core Component

Semantic Discovery Module

Web Service Invocation Module

Controller Module

Semantic Abstraction Component

Semantic Interface Factory Module

WSMX Adapter Module

IRS III Adapter

Module ... Semantic Interface Factory Module BPEL Process Server

WSMX IRS III ...

WSMX Adapter Module

IRS III Adapter

Module ... Semantic Discovery

Module

Web Service Invocation Module

Discovered Web Service

Controller Module

Web Service Interface Module

Semantic Invocation Service (SISi) Semantic Description Input Message Output Message

Figure 7.6: Input consumed and output produced by SISi

the requests to the other components of SISi. The modules are included to ensure exten- sibility to fulfil future requirements. For example, if data mediation is needed in a future version, this can be added to the semantic discovery module without having to change the controller.

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

<wsdl:definitions name="WebServiceInterfaceWS"

targetNamespace="http://sisi.externalInterface/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://sisi.externalInterface/" xmlns:dataNs="http://sisi.externalInterface/dataTypes" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <schema xmlns="http://www.w3.org/2001/XMLSchema">

<import namespace="http://sisi.externalInterface/dataTypes"

schemaLocation="SISi_WebServiceInterface_dataTypes.xsd"/> </schema>

</wsdl:types>

<wsdl:message name="invokeSemanticWebServiceRequest">

<wsdl:part name="semanticDescription" element="xsd:string"/> <wsdl:part name="parameters" element="dataNs:hashMap"/> </wsdl:message>

<wsdl:message name="invokeSemanticWebServiceResponse"> <wsdl:part name="parameters" element="dataNs:hashMap"/> </wsdl:message>

<wsdl:portType name="WebServiceInterfaceWS"> <wsdl:operation name="invokeSemanticWebService">

<wsdl:input message="invokeSemanticWebServiceRequest"/> <wsdl:output message="invokeSemanticWebServiceResponse"/> </wsdl:operation>

</wsdl:portType> </wsdl:definitions>

Figure 7.7: WSDL definition of SISi

The bottom layer called “Semantic Abstraction Component” provides access to the se- mantic discovery components. Even though there are preliminary efforts3 _{to standardise}

3_{http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=}

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:tns="http://sisi.externalInterface/dataTypes"> <xsd:complexType name="hashMap">

<xsd:complexContent>

<xsd:extension base="map"> <xsd:sequence/>

</xsd:extension> </xsd:complexContent> </xsd:complexType>

<xsd:complexType name="map"> <xsd:sequence>

<xsd:element name="mapEntry" type="mapEntry" minOccurs="0"

maxOccurs="unbounded"/> </xsd:sequence>

</xsd:complexType>

<xsd:complexType name="mapEntry"> <xsd:sequence>

<xsd:element name="key" type="xsd:anyType"/> <xsd:element name="value" type="xsd:anyType"/> </xsd:sequence>

</xsd:complexType> </xsd:schema>

Figure 7.8: Data definition of SISi

such components in a reference architecture, the author is not aware of any widely ac- cepted standard. Therefore, an individual adapter module is required for each seman- tic discovery component to be supported. The current implementation contains only an adapter module for WSMX [HCM+05]. All adapter modules must implement the same set of interface operations so that they can be used transparently through the “Semantic In- terface Factory Module”. This approach allows great flexibility, because any specifics of the different semantic discovery components to be supported are implemented in a single module.

Figure 7.6 shows the input consumed and the output produced by SISi. In order to perform its task, SISi needs the semantic description like a WSMO goal and it needs the input message for the web service to be invoked. As a result, SISi returns the message it received from the invoked web service. As SISi cannot foresee which web service will be found and invoked, it cannot provide an operation with parameters as the discovered web service has.

The code snippet in figure7.7shows the WSDL definition of SISi and figure 7.8shows the belonging data definition of the different message parts. It can be seen that the in- put message consists of two parts – the semantic description and the message to be forwarded to the discovered web service. Currently, the type of the message part for the semantic description is only a plain string. It is unknown what type is needed for the input message of the discovered web service. Therefore, a hash map is used, which can con- tain objects of any type. The output message of SISi only consists of one message part. This message part transports the message received from the discovered and invoked web

Orchestration Engine

Web Service Engine WS3 WS2 WS1 ... SISi 1. 4. 3. 2. Process1 Reasoner 5. 6.

Figure 7.9: System architecture for semantic process execution

service back to the calling BPEL process. Again, as the format of this message is not known in advance, a hash map is used to store a collection of objects of any type.