SZTAKI - Department of Distributed Systems

The main INFRAWEBS project focus and objective is the development of an application-oriented software toolset for creating, maintaining and executing WSMO-based Semantic Web Services (SWS) within their whole life cycle.

This next generation of tools and systems will enable software and service providers to build open and extensible development platforms for web service applications. These services will run on open standards and specifications, such as BPEL4WS, WSMO, WSMX, WSML, SPARQL, RDF, etc. In particular, they will be compliant with WSMO (Web Services Modelling Ontology), an initiative submitted to W3C.

The systems generated will consist of loosely-coupled and linked INFRAWEB units, with each unit providing tools and adaptable system components. Developers will be able to use these components to analyse, design and maintain WSMO-based Semantic Web services across the whole lifecycle.

These Semantic Web services offer a new dimension in collaborative work and service production, service provision and service maintenance in run-time environments.

The INFRAWEBS framework

The essential project activities are to build up software modules within an integrated framework - IIF - the Integrated Infrawebs Framework. Several functionalities are provided for the usage in design-time as well as in run-time (by service providers, service designers or service brokers). For the design-time phase they are:

• The SWS Designer, which helps designing a WSMO-based Semantic Web service from an existing non-semantic Web service using graphical editors and case-based reasoning.
• The Organizational Memory (OM), which stores and categorises non-logical representations of WSMO objects as well as additional non-semantic data (like graphical models and templates of SWS).
• The Semantic Information Router (SIR) as a metadata based content management and aggregation platform (endowed with a SPARQL query interface), used by other components to query for annotated and categorized service descriptions.
• The SWS Composer for creating a Semantic Web service through composition of existing WSMO-based SWSs. It uses a case-based memory for retrieving service composition templates quasi-similar to the orchestration interface of the service to be composed.

The run-time modules (for service consumers, service providers, service brokers) are given by:

• The Distributed Repository for effective storing and retrieving all semantic elements of the WSMO Framework: Goals, Ontologies, SWS and Mediators (written in WSML), whereas each repository consists of two parts: a local repository (storing of all WSMO objects created in the Semantic Web service Unit, and a local registry for advertising the SWSs. Repositories are connected as a peer-to-peer network and propagate SWS advertisements regularly over this network.
• The Service Access Middleware guides the applications using the INFRAWEBS framework through the steps of semantic web service usage including service discovery, selection and execution. This middleware stands as a single, intelligent access point to services offered by the INFRAWEBS framework.
• The SWS Executor module processes Semantic Web service WSMO descriptions using choreography and orchestration engines for executing specific SWS related rules.
• The QoS (Quality of Service) Broker provides functionalities for monitoring the SW service execution process by feeding back extracted metric data.
• The Security and Privacy enabler realised as an artificial "immune defence system" allowing the INFRAWEBS framework to function properly under changing conditions.

INFRAWEBS represents a novel approach to problem solving in the creation of SWS applications. It involves a tight integration of similarity-based (non-semantic) search and logic-based (semantic) reasoning.

Service Access Middleware

The Service Access Middleware provides a one-stop-shop access point as an abstraction for using SWSs. SAM can be used through a SOAP interface for the following:

• SWS discovery: the goal given by the user describes what the user wants to achieve in the form of logical expressions. A list of appropriate web services is provided for the goal.
• SWS selection: the user or the application has to select a service if there are more services available for the given goal. Each service description is enriched with additional information which may be of help during the selection phase. This information may be related to the technical performance and quality of the web service or to the quality and satisfaction with the real service (usually collected as user feedback).
• SWS execution: the selected web service is invoked. The model of the possible sequences of interactions with the user is called choreography. The invoked web service executes its communication pattern with the client (choreography), and it may also communicate with other web services (orchestration) to produce the result.

Typically logical reasoning is used to discover services matching with the user's goal. This is usually a slow, time-comsuming operation. In the INFRAWEBS project discovery combines a traditional IR-based pre-filtering step and a logic-based matching implemented in Prolog. The first step efficiently decreases the number of candidate matching services without loosing any possible good match. So in the next step only a smaller set of services has to be matched logically to the user's goal. The second step uses a matching algorithm based on Logic Programming, and it is implemented in Prolog.

A test bed is available online for the demonstration of our approach to SWS discovery at http://infrawebs.dsd.sztaki.hu.