Life-Cycle Support of Semantic Web Services

by László Kovács, András Micsik and Tomás Pariente

In the frame of the INFRAWEBS project, a software toolset for creating, maintaining and executing WSMO (Web Service Modelling Ontology) services was developed. The implemented framework supports open and extensible development platforms for Semantic Web services.

The INFRAWEBS project has developed a framework that enables software and service providers to generate and establish open and extensible development platforms for Web service applications. The project was funded by the EU with participation of 12 European partners: FH Bochum, University of Innsbruck, IIT-BAS, MTA SZTAKI, NTUA, Profium SA, Sirma SAI, FUTUREtec, Atos Origin, Best-HP, Aspasia Knowledge Systems and big7.net.

The project divides the life cycle of Semantic Web services (SWS) into two different phases: design time and run time. The role of the design-time tools is to ready existing Web services for semantic deployment. During the design-time phase, various tools and editors support the creation of semantic descriptions for existing Web services.

For example, the SWS Designer (SWS-D) is a visual editor of SWS descriptions, which helps to create service descriptions for Web services by applying drag-and-drop graphical editing and case-based reasoning. The Designer contains a visual axiom editor, which makes the compilation of logical queries easier even for non-expert users.

The SWS Composer (SWS-C) is another visual tool for creating a Semantic Web service through the composition of existing WSMO-based services. It also uses a case-based memory for retrieving service composition templates quasi-similar to the service to be composed.

The resulting ontologies, goals and Semantic Web services are made accessible in a distributed registry (DSWS-R). WSML (Web Service Modelling Language) was chosen as the language for describing these semantic entities. The run-time phase involves discovery, selection and execution of the Semantic Web services. The Quality of Service (QoS) Broker component of the run-time environment collects QoS data for Semantic Web services, which are fed back into the phase of discovery and selection.

Developers of SWS-based applications use the SAM module (Service Access Middleware) as a central API to INFRAWEBS services. With the help of SAM they are able to create Java code to discover, select and execute Semantic Web services. SAM is also able to hide the WSML syntax from developers, so no WSML parser is necessary in the applications.

The discovery engine of INFRAWEBS was implemented by SZTAKI as part of the SAM module. According to the usual scenario, the discovery engine receives a WSML goal as input and must provide a list of matching Semantic Web services, possibly coupled with additional information that supports ranking and selection.

Figure 1: Overall architecture of INFRAWEBS modules.

Discovery implementation has three steps: pre-filtering, logical matching and finalizing to prepare the result. The aim of the pre-filtering step is to narrow the list of candidates using traditional text-processing (keyword matching) algorithms. This pre-filtering is supported by a structured text indexing and clustering service, which is another module of the framework. Pre-filtering is optimized for recall, so that it does not filter out possible matching candidates, yet it filters out definite non-matches using very fast textual queries.

Our implementation of semantic matching applies the unification facility of Prolog engines. Instead of matching large logical expressions, we break these expressions into small pieces using Disjunctive Normal Form (DNF), where the matching of each piece can be judged individually. This approach also provides interesting possibilities such as the comparison, ranking and explanation of service matches (or non-matches). Furthermore, we are able to handle user preferences during discovery, which is becoming an increasingly important aspect of SWS usability.

In the final step of discovery, the list of matching services is enhanced with QoS data based on past execution experience, which can be used for service selection. QoS data is collected by the QoS Monitor, a part of the Service Executor module. This Service Executor processes WSMO-based Semantic Web service descriptions using choreography and orchestration engines for executing specific rules, and performs the actual execution of the selected services.

Figure 2: Peer-to-peer architecture of the INFRAWEBS

The various tools implemented in the project are integrated by the INFRAWEBS framework, which is an enterprise service bus (ESB) connecting a peer-to-peer (P2P) network of nodes. Nodes can host Java and .NET services. Every peer can be deployed containing all or part of the INFRAWEBS stack of components. The framework hides from users the complexity of dealing with the P2P architecture.

On the other hand, the INFRAWEBS framework allows service application providers to create semantic-enabled applications based on the Semantic Web service descriptions stored in the P2P repositories. All methods provided by the components developed within the project are available through Java and Web service interfaces provided by the INFRAWEBS framework. They ensure interoperability and make the framework simple for developers to use.

INFRAWEBS reflects a novel approach to solving problems that occur during the creation and maintenance of Semantic Web services and their applications. It is based on tight integration of similarity-based and logic-based reasoning. Similarity-based reasoning is used for fast finding of approximate solutions, which are further concretized by the logic-based reasoning.

Most of the tools and the integration framework are available as open-source software at the project Web page, under LGPL license.

Link:
http://www.infrawebs.eu/

Please contact:
Tomás Pariente
ATOS Research & Innovation, Spain
Tel: +34 91 214 9321
E-mail: tomas.parienteloboatosorigin.com