Web Services Challenge 2007

CEC-07 & EEE-07

Web Services

Challenge 2007

Tokyo, Japan

23-26 July 2007

Overview

Schedule & Deadlines

Student Travel Awards

Semantic Composition Description

NOTE: For information regarding changes since the 2006 competition, please read the "What's New" section below.

Semantic Representation

In the syntactic competition matching of services is based on the string equivalence of partnames of the input and output messages of a service. In the semantic competition we adopt the idea of so called Semantic Web Services that represent Web Services with a semantic description about the interface and its characteristics. Most approaches split the semantic description into two parts. The first part clarifies the interpretation about the concepts used in the particular application domain. The second part refers to a definition about the elements of a Web Service, such as defining that a Web Service features input parameters or provides specific preconditions. Several proposals exist already to standardise the semantic description about Web services, such as the semantically annotated WSDL approach (WSDL-S), the OWL Services ontology and the Web Service Modelling Ontology (WSMO).

For the semantic version of the challenge, we define a simplified version of Semantic Web Services. In 2007 WS-Challenge, the same set domain concepts is provided in two different formats, namely XML Schema as well as OWL. A simplified type hierarchy defined in XML Schema (with the same format as that provided in 2006 WS-Challenge) is provided as a common definition about the domain concepts. This type hierarchy will provide the type definitions about the input and output parameters of the considered Web services. The semantic description about the provided and required services will also use a representation that complies with the XML Schema. Consequently, we extend the matching of parameter names to the matching of parameter types defined by the XML Schema type hierarchy. Addition to the use of the XML Schema, the domain concepts will
also be described in OWL format in case some of the teams find this format more convenient to work with. Note that the matching challenge does not cover the semantic descriptions about the e.g. the service category, pre- and postconditions as provided by OWL-S or the WSMO idea.

Semantical Discovery Sample

A Web Service may have a number of input and output parameters each refering to a type related to a type system potentially providing an inheritance hierarchy. Considering that a Web Service represents a programming interface we need to consider the contravariance of types for the interfaces, which result in the following rules for a successful type match of parameters:

regarding one input of a service, the service requester must have specified a parameter type that is equivalent to or subsumed by the parameter type that the provider has specified. If the parameter type used by the invocation of the service requester does not provide the required or more special characteristics as specified by the provider, we cannot guarantee the successful execution of the service.
regarding one output of a service, the direction of the subsumes-relation is opposite to the relation specified for the inputs. For the successful execution of a service, we regard the processing of outputs as irrelevant. However, the requester has defined requirements that we need to ensure. For example, the output of a service may represent the input of its subsequent service. Thus, the output type provided by the service must be equivalent to or be subsumed by the required output from the service requester.

In other words, the new matching challenge does not consider the string equivalence of parameter names but the contravariance of types to identify successful matches. Please note also that the invocation of a Web Service represents a call of a software API. Thus, we must also consider:

that the service requester must show a successful match to all provided input-parameters with their equivalents or subsuming types. Otherwise a service call invokes an interface without setting all parameters which leads usually to a malfunction.
that the service provider must at least match all required output-parameters with their equivalent or subsuming types. Otherwise the provided service does not fulfill the requirements of the service requester by not delivering one or more required output parameters.

The type system will be encoded using XML Schema. We consider XML Schema as a lightweight way to define complex types to establish a type hierarchy. In addition, we consider the information expressed by using XML Schema as easy to parse and process. Let us consider the following type example specified based on XML Schema as follows:

  <complexType name="Address">
    <sequence>
      <element name="name" type="string" minOccurs="0"/>
      <element name="street" type="string"/>
      <element name="city" type="string"/>
    </sequence>
  </complexType>

In addition we define the following two subtypes using XML Schema:

  <complexType name="US-Address">
    <complexContent>
      <extension base="Address">
        <sequence>
          <element name="state" type="US-State"/>
          <element name="zip" type="positiveInteger"/>
        </sequence>
      </extension>
    </complexContent>
  </complexType>

and

  <complexType name="EU-Address">
    <complexContent>
      <extension base="Address">
        <sequence>
          <element name="postcode" type="EU-Postcode"/>
        </sequence>
        <attribute name="export-code"
              type="positiveInteger" fixed="1"/>
      </extension>
    </complexContent>
  </complexType>

The resulting subsumes relation is as such that the concept of Address subsumes the concepts of EU-Address and US-Address in the way that both subtypes show all characteristics of the their supertype. For this example, we consider the following as successful match:

The provided service defines Address as input. Then we can identify a successful match, if the requester defines the equivalent type (Address) or subsumed types (EU-Address and US-Address) as the inputs he uses to invoke the service.
The provided service defines one of the both types EU-Address or US-Address as output. Then a successful match is considered, if the description of required service either defines the equivalent type, depending on what is provided either EU-Address or US-Address, or a concept that subsumes the provided output type. In this case, this would the type Address.

Semantical Composition Sample

Along the lines of the Semantical Discovery Competition the composition competition can also be changed into a semantic version. Based on the matching rule defined above, the aim is to derive a minimal chain of services providing a match with the input and output parameter types of the query. To give and example, consider the following required service: a service requester seeks a service that returns an address for a given client name. Based on the Name type:

  <complexType name="Name">
    <sequence>
      <element name="Lastname" type="string" minOccurs="1"/>
      <element name="Firstname" type="string" minOccurs="1"/>
    </sequence>
  </complexType>

the following query has to be fulfilled based on the type Address introduced above:

  <WSChallenge>
    <CompositionRoutine name="composition1-20-16-10">
      <Provided> Name </Provided>
      <Resultant> Address </Resultant>
    </CompositionRoutine>
  </WSChallenge>

However, the repository does not contain such a service, but a service having an input parameter of type Name and an output parameter of type Clientid:

  <simpleType name="Clientid">
    <restriction base="string"/>
  </simpleType>

In addition, the repository contains another service having an input parameter of type Clientidand an output parameter of the desired type EU-Address. Then, the two services can be composed and provide a solution to the specified query.

Query and Solution Formats

The type definition specified in XML Schema is provided as a single file used by all WSDL files related to a particular repository. Besides of that the specification of the query and the the expected result format are equivalent except that

the part names are replaced by complex type names defined in the XML Schema file, and
the type attribute in the solution format should be now Semantic Discovery Solution and respectively.

What's New

The 2007 Web Services Challenge incorporates several new aspects:

Entries must receive requests and return results via SOAP. See the interface package page for more information.
Solution chains of WSDL files will vary in length. More specifically, there will be multiple correct answers where some solutions are longer than others. Shorter chains can be perceived as being less expensive, thus will be considered the best answer. Entries will be judged on how quickly they are able to produce the "best" result. An example query and solution are available here.
Some scenarios in the challenge will requre entries to handle branching. In 2006, all solution chains were sequential. In 2007, some scenarios may result in solutions chains that require branching and merging. Samples are forthcoming.
There will be scenarios created using OWL representations. Samples are forthcoming.