Overview

Service-oriented Computing aims at building future heterogeneous, distributed business applications through the use of (Web) services as building blocks.

Currently, WSDL interfaces provide only a syntactic description of services similar to IDL interfaces for software components. Consequently, the generation of composite services from black-box (viz., behaviour-less) service descriptions may (dead)lock.

BPEL is the main proposal for composing services, and it is highly promoted by the industry, yet the designer is in charge of manually selecting the services (e.g., from UDDI registries) and generating the composite one.

The Semantic Web initiative proposes ontology-aware languages such as OWL-S to automate Web service discovery, composition and monitoring. Basically, the ontology information can be used to (automatically) match service parameters, and such matches can be exploited to enhance not only service discovery but service composition and adaptation as well.

Most existing automation-oriented approaches employ A.I. techniques such as planning , still the goal is difficult to represent and the aggregation process is quite time-consuming. Furthermore, the abundance of languages to express service compositions obstructs the achievement of automated Web service aggregation, as currently, to the best of our knowledge, existing techniques do not provide means to compose services written with different service description languages.

Our long-term objective is to develop a general methodology for deploying (Web) service aggregation and adaptation middleware, capable of suitably overcoming semantic (viz., ontology) and behavioural mismatches in view of application integration within and across organisational boundaries.

SATOR is a (Web) services aggregator that, given a set of advertised service contracts together with a data-flow mapping linking service parameters, automatically generates the contract of a composite service. Service contracts include (WSDL) signature, (OWL) ontology information, as well as (YAWL) behaviour specification. The aggregation process generates the workflow of the composite from the initial workflows by suitably adding control-flow constraints among their tasks due to data-flow dependencies among parameters.

SATOR takes as inputs the YAWL behaviour specifications of the services to be aggregated, as well as the data flow mapping between them.

The result is a YAWL workflow that expresses the interplay among the aggregated services, namely all the control-flow and data-flow relationships among them.