Web Service Execution Environment (WSMX)

W3C Member Submission 3 June 2005

This version:: http://www.w3.org/submissions/2005/SUBM-WSMX-20050603/
Latest version:: http://www.w3.org/submissions/WSMX/
Editors:: Emilia Cimpian
Michal Zaremba
Authors:: Christoph Bussler (WSMX WG chair, WSMO WG co-chair)
Emilia Cimpian
Dieter Fensel (WSMO WG co-chair, WSML WG co-chair)
Juan Miguel Gomez
Armin Haller
Thomas Haselwanter
Michael Kerrigan
Adrian Mocan
Matthew Moran
Eyal Oren
Brahmananda Sapkota
Ioan Toma
Jana Viskova
Tomas Vitvar
Maciej Zaremba
Michal Zaremba

Copyright © 2005 DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the National University of Ireland, Galway, Ireland, BT, The Open University, and SAP AG. All rights reserved.
This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.

Abstract

This document provides an overview of the results achieved by the Web Service Execution Environment (WSMX) working group. The mission and goal of the WSMX working group is to define a Semantic Web services (SWSs) architecture and to provide a complete implementation based on the conceptual model of Web Service Modeling Ontology (WSMO). Through this document we advocate that to address Semantic Web services architectural requirements as defined by [SWSA, 2004], the architecture, system components, their interfaces and system execution semantics must be standardized.

WSMX is an execution environment that enables discovery, selection, mediation, invocation and interoperation of SWSs. The development process for WSMX includes establishing a conceptual model, defining its execution semantics, developing the architecture of the system, designing the software and building a working implementation of the system. The research results for WSMX provide guidelines and justification for a general SWS architecture. Deliverables of the WSMX working group define the structure of the SWS architecture, its execution semantics, mediation, discovery and invocation mechanisms, and any other functionality needed in the context of executing Semantic Web services. Work carried out by the WSMX working group, apart from its research focus, also provides a reference implementation of WSMO.

Status of this Document

By publishing this document, W3C acknowledges that DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the National University of Ireland, Galway, Ireland, BT, The Open University, and SAP AG have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

1. Introduction

In order to take full advantage of the availability of the Web as a progressive, open environment that businesses can use, and to support distributed heterogeneous applications built by different vendors, Web Service technology has been developed. Existing Web service basic technologies provide the basic functionality for discovering (UDDI), describing Web service interfaces (WSDL) and exchanging messages (SOAP) in heterogeneous, autonomous and distributed systems. In practical terms, existing Web services support operations are limited to independent calls over a network, hard wired collaborations or predefined supply chains. Web service technology or standards do not provide any functionality to specify how to include additional semantic information which would allow using and processing them without human interaction.

Systems integration based on semantically enhanced Web services is now possible. The Web Service Modeling Ontology (WSMO) working group is one of a number of research efforts currently underway world-wide developing a conceptual model, language and execution environment for SWSs. Enhancing existing Web service standards with semantic markup standardised through the WSMO working group, promotes the use of currently existing Web services standards for semantic-enabled integration.

The Web Service Execution Environment working group is the WSMO working group that provides an execution environment called WSMX for discovery, selection, mediation, invocation and interoperation of SWSs. The goal of research in WSMX is to provide an architecture for Semantic Web service based systems. WSMX is based on the conceptual model provided by Web Service Modeling Ontology which describes various aspects related to SWSs. WSMX is also a reference implementation for WSMO, providing the proof of its applicability and usefulness as well as being a vehicle for driving new projects and partnerships. The goal is to provide both a test-bed for WSMO and to demonstrate the viability of using WSMO as a model for achieving dynamic interoperation of SWSs.

The development process for WSMX includes defining its conceptual model (i.e. WSMO), modeling its execution semantics (implemented by a dynamic execution semantic engine capable of interpreting any formal definition of system behaviour provided by third parties) and designing the WSMX system architecture. The WSMX working group also defines component interfaces, designs particular components and provides their implementation.

This document provides an overview of WSMX in terms of scope, functional objectives, development approach and deliverables in relationship with WSMO.

1.1 Scope of WSMX Development

The first releases of WSMX implement a subset of WSMO and the related set of Web Service Modeling Languages (WSMLs); future releases will fully implement WSMO and use the complete set of WSML languages. The initial version of WSMX was based on a minimal set of WSMO concepts, while subsequent versions implement the complete conceptual model provided by WSMO. Already for the initial version of WSMX a complete architecture including discovery, mediation, selection and invocation components has been designed including all required supporting components enabling exchange of messages between the requesters and the providers of services. At this stage of the WSMX development, the implementation of these components has been reduced to a minimal functionality; the initial implementation of these components focused on simple implementation with clearly separated, well-defined interfaces.. With each subsequent implementation, new and more complex functionalities will be implemented. The initial functionality of WSMX allows achieving a user-specified goal by invoking a Web service described with the semantic markup, i.e., Semantic Web Services. The first version of WSMX has been available since June 2004 at the SourceForge portal.

1.2 Development Approach

WSMX follows the best practice of staged component-based software development. The initial phase was focused on constructing a rigid architecture for Semantic Web service execution using decoupled and autonomous components. Once the basic WSMX framework was in place, subsequent releases have focused on refining the individual components, improving the whole framework and providing new and additional functionality. The rationale for this incremenental approach is to provide component-based software that is both maintainable and extensible. It is important to emphasize that because of this approach, changes can be implemented gradually over time. As the conceptual model offered by WSMO and the WSML language extend over time, so will WSMX based on this flexible architecture.

1.3 Document Overview

The remainder of this document is organized as follows. In Section 2, a general overview of WSMX functionality and its components is given. Section 3 presents architecture, components interfaces, WSMX external behaviour and its execution semantics. Section 4 discusses the related systems. Finally, Section 5 presents our conclusions and further directions.

2. WSMX Functionality

WSMX in its final version will offer complete support for SWSs, providing the rationale for a complete SWS architecture. WSMX deliverables describe the SWS architecture and its components, its execution semantics, mediation, discovery and invocation mechanisms, and any other functionality compulsory in any SWS system. The functionality of WSMX can be described in terms of the aggregated functionality of all its components.

The following main components have already been designed and implemented in WSMX: Core Component, Resource Manager, Service Discovery, Service Selection, Data and Process Mediator, Communication Manager, Choreography Engine, Web Service Modeling Toolkit and Reasoner. Each of these are describedin the following subsections.

2.1 Core Component

The Core Component is the central part of WSMX, and all the other components are managed by it. All interactions between components will be coordinated through the Core Component. The business logic of the system, the events engine, the internal workflow engine, the distributed components loading, etc. will all be subcomponents of the Core Component. At this stage the Core Component is the central module of WSMX. In the future, in order to ensure increased reliability of WSMX, a clustering mechanism for distributed Core Components might be developed. For resource intensive operations, many instances of the Core Components can be instantiated on several machines to create a WSMX cluster.

2.2 Resource Manager

The Resource Manager is responsible for the management of the repositories that store definitions of any WSMO entity (Web services, goals, ontologies and mediators) and non-WSMO related objects in WSMX. Depending on the scope of data stored in the underlying registries, WSMX distinguishes registries to be local or global. Data stored in a local registry is relevant for the operation of WSMX in a particular context. In some cases individual functional components may also require local storage. On the other hand, a global registry can be shared across several domains (e.g. registries of SWS descriptions). While both stored data and accessibility to this data might differ considerably between registries, the Resource Manager remains the only entry-point for them, which means it is not possible to access any of registries directly, but only through the Resource Manager (in this way the burden of accessing any of the repositories is delegated to the Resource Manager). A component that needs to retrieve, modify or add any data in one of the repositories has to invoke the Resource Manager. The operations that need to be performed to retrieve the data and the repository that store the data remain transparent.

Currently WSMX provides five repositories: Web Service Repository, Goal Repository, Ontology Repository, Mediator Repository and Data Repository. This document also recognizes that ebXML [ebXMLRegistry] and UDDI [UDDI] repositories can be used for WSMX data persistence.

The Web Services Repository deals with semantic description of Web services, such as their capabilities (pre-conditions, post-conditions, assumptions and effects), interfaces (choreography and orchestration) and non-functional properties, both general and Web service specific. Once a Web service description has been loaded in the Repository it is available for operations such as discovery of services or monitoring of services.

The Goals Repository deals with semantic description of general goals. A WSMO Goal in most cases expresses the "wish" that a user wants to achieve. Some of the goals may be reusable and provided as templates and therefore should be published using the repository. Non-reusable or frequently updated goals should be stored at the service requester side or in a dedicated external repository. The goal repository can thus contain predefined goals constructed by domain experts, as well as user-specific goals. A tool to construct and refine goals will provide access for human users.

The Ontology Repository deals with ontologies that are stored in the registry describing the semantics of particular domains. Any component might wish to consult an ontology, but in most cases the ontologies will be used by mediator components to overcome data and process heterogeneity. The requirement for a visualization tool and a management mechanism for ontologies are known. Ontologies stored by WSMX are expressed in terms of WSML. For convenience, WSMX considers the syntactical adaptation from any ontology syntax by translating it into WSML before storage.

The Mediator Repository deals with mediators that are stored in the registry. WSMO mediators have become a standard functionality covering various approaches for data and process mediation. Mediators are stored in a repository for possible reuse by the data and process mediation components.

The Data Repository deals with a variety of system-specific data produced by the system during run-time. Also, components might generate execution state data, which should be persistent. The data repository allows us to store any system data and any component-specific data required for correct system execution.

2.3 Service Discovery

Service Discovery is one of the most important tasks in Semantic Web Services. In simple terms, Service Discovery is the process of locating services that fulfill a user request. Mechanization of this process is part of the realization of the Semantic Web services vision. Developed to address conceptual and pragmatic issues that are involved in service discovery, WSMO Discovery provides a complete conceptual solution for the discovery problem in SWS settings. Three major steps in discovery are identified: Goal Discovery, Web Service Discovery and Service Discovery. Goal Discovery is about abstracting a concrete user goal to a pre-defined, reusable, and formalized goal. Web Service Discovery is about matching formalized goals with formalized Web Services description, selecting Web services that can potentially be used to get the desired service. Service Discovery uses the Web Services matched in the previous step to access the real services behind such Web service interfaces, finally checking what services fulfill the requester goal. Furthermore, three different approaches in Web Service Discovery can be distinguished: Keyword-based Discovery, Lightweight semantic Discovery and Heavyweight semantic Discovery.

In the Keyword-based Discovery approach, keywords from a goal description are matched against keywords from services descriptions. The goal description's keywords and service descriptions' keywords are entities defined in the underlying ontologies of the requestor, and of the providers of the service, respectively.

In the Lightweight semantic Discovery approach, controlled vocabularies that have an explicit semantic are used during the matching process. Only the desired state from the goal and the state of the services after execution are considered and modeled as a set of objects. Logics based on set theory (e.g. Description Logics) are used to determine whether a goal description matches with services descriptions.

In the Heavyweight semantic Discovery approach, relations between inputs and outputs of services and goal as well as transition states, are considered during the matching process. More expressive logics that provide rule support (e.g. F-Logic) could be used to determine whether a goal description matches with services descriptions.

The WSMX discovery component aims to implement a WSMO conceptual framework for discovery. Web Service Discovery is the main focus of current implementation of WSMX discovery. As part of current WSMX discovery, Keyword-based Discovery offers the possibility of matching a user goal against service descriptions in a syntactic way. The match can be done in different dimensions (e.g. match based on the non-functional property values of goal and services descriptions). Future implementations will provide working solutions to the other two approaches for Web Service Discovery: Lightweight semantic Discovery and Heavyweight semantic Discovery, and will address distributed discovery as well.

2.4 Service Selection

The selection of a Semantic Web service might be done in WSMX by a Service Selection component or outside of the system after presenting the service requester with the set of potential Web services satisfying its goal. When selecting Web services, one and possibly the "best" or the "optimal" Semantic Web service is to be returned from a set of satisfying matching services. To select an optimal Semantic Web service, different techniques can be applied, ranging from simple selection criteria ("always the first one") to more sophisticated techniques, such as multi-criteria selection of variants involving interactions with a service requester. Different variants of services are described by different values of parameters (non-functional properties specific to Web services), such as financial properties, reliability or security.

2.5 Data and Process Mediators

Mediation is needed when two heterogeneous entities that do not have a common basis for communication have to interact. The reason why they might not be able to communicate directly is because they use a different syntax or semantics of data (in this case data mediation being needed), or that their communication patterns mismatch (which requires the use of a process mediator).

WSMX offers distinct implementations for data and process mediation. Data mediation is based on paradigms of ontology, ontology mapping, and ontology management. Data from different sources are mediated based on their semantic similarities as expressed by their reconciled conceptualizations.

Process mediation may be needed when a requester attempts to invoke and execute a Web service of a provider. The communication pattern of the Web Service may be different from the one the requester expects, in which case one of them has to adjust to the other's communication pattern – meaning that it has to change its process execution in order to match the other parties' specifications. The adjustment of the different patterns in order to make them match is called process mediation. The process mediator provides the functionality for a runtime analysis of two given patterns, and compensates for the possible mismatches that may appear, by, for instance, generating dummy acknowledgement messages, grouping several messages into a single one, changing their order or even removing some of the messages in order to facilitate the communication between the two parties.

2.6 Communication Manager

WSMX offers invocation of selected Semantic Web services while obeying their interfaces (i.e., choreography and orchestration). The Communication Manager consists of two subcomponents: invoker and receiver. WSMX is an intermediary system located between service requesters and service providers. Communication in both directions (from service requester to service provider and vice versa) is supported by these two subcomponents. In general, invocation of services can be based on any underlying protocol of service providers (e.g. SOAP or proprietary protocols) and for this purpose an adapter framework is designed. It is the responsibility of an adapter to implement interactions with a particular service provider using communication protocols, data formats or process paterns that are different from SOAP.

2.7 Choreography Engine

The choreography of a Web service defines its published communication pattern, i.e., the way a requester can interact with it. The requestor of the service has in general its own communication pattern. Only if both match precisely a direct communication between the service requestor and provider can take place. Since the requester's communication pattern in general is different from that used by the Web service provider, the two of them will not be able to communicate directly, even if they understand the same data formats. The role of the Choreography Engine is to make sure that the requestor's communication pattern matches the provider's communication pattern. It works in close correlation with the Process Mediator in order to accommodate the possible differences between the loaded choreographies.

Additionally, in case a Web service provides multiple choreographies for the same capability, the Choreography Engine has to determine the corresponding choreography for an incoming message. Probably it would be very often the case that an initial set of messages exchanges is the same in all the choreographies; in this case an instance of each of the potential choreographies must be maintained until enough messages arrives to be able to identify the right choreography. This process also includes the interaction with the Process Mediator and the logics related to the management of the results returned by the Process Mediator.

2.8 Web Services Modeling Toolkit

The Web Services Modeling Toolkit (WSMT) is a framework for the rapid creation and deployment of homogeneous tool for Semantic Web services. It enables developers of tools to focus on the tools' functionality and provides the framework within which they can be deployed and executed.

The aim of the WSMT is to encourage the development of tools for Semantic Web services and, once they have been developed, to centralize these tools in a common application. This will allow users who wish to describe and manage Semantic Web services to install a single application from which all the tools are available. An important feature of the WSMT is dynamic tool detection; this enables tools to be integrated into WSMT (as plug-ins) without the need to recompile the application. An initial set of tools includes a WSML Editor for editing WSML and publishing it to WSMO repositories, a WSMX Monitor for monitoring the state of the WSMX environment, a WSMX Mediation tool for creating mappings between ontologies and a WSMX Management tool for managing the WSMX environment.

2.9 Reasoner

Although development of a reasoner is not part of the WSMX development process, a WSML-compliant reasoner is an important component of the whole WSMX framework. The reasoner will provide reasoning services for the mapping process of mediation, as well as functionality relating to validation of a possible composition of services, or determination if a composed services in a process is executable in a given context. Also, this component will be used for finding capabilities that exactly match the requester's goal, as well as capabilities subsuming this goal.

Apart from the essential SWS functionalities that must be available with any execution environment for SWSs, such as discovery, selection, mediation, invocation or interoperation, some more specific enterprise systems functionalities are being addressed in WSMX. Some of these additional functionalities, available with later WSMX system implementations include:

As well as developing the system itself, WSMX addresses all the key properties of enterprise software. The releases of WSMX will provide functionalities like reliability, scalability and security. These are an integral part of the WSMX server.

3. WSMX Architecture

WSMX is a Service Oriented Architecture (SOA), which means that it is a software system consisting of a set of collaborating software components with well-defined interfaces that together perform a task. These components do not necessarily execute in the same address space, and not even necessarily in different address spaces on the same machine. Instead, they may very well execute on different network locations communicating over a network connection through multiple protocol stacks. This situation creates its own unique demands, born out of latency, memory access, concurrency and failure of subsystems, which the architecture must be able to cope with. All these aspects are addressed in subsequent phases during designing and implementing WSMX. SOAs differentiate themselves from other distributed systems through the concept of loose coupling brought to its extremes. Strong decoupling of the various components that realize an e-commerce application is one of the major features of WSMO. In WSMX, conceptually independent pieces of functionality have been grouped in components. Each of the WSMX components provides services – each of which is a logical unit of system code, application code, and persistency layers — in short, anything that as a unit can carry out an operation. Services are often characterized by exactly these operations that they provide to other components. Preferably services have descriptions in machine-processable meta-data. Although it is recommended to build the communication inside a Semantic Web services architecture on the event paradigm, the system components can be coordinated without events. In distributed SOA systems, communication between components can take place through events. It enables the best practice of implementation abstraction through interfaces, by which the implementation of a service must be of no concern to the client of the service. All of this together results in increased flexibility, better extensibility and dramatically improved reusability. However, it is not always easy to achieve all of these goals simultaneously, even if the right architectural decisions are taken. Scalability and proper service structuring are crucial and have to be taken into account as well.

3.1 Architecture

The WSMX architecture consists of a set of loosely-coupled components as presented in Figure 1. These can be plugged-in and plugged-out from the system. The components that are provided with the WSMX reference implementation can be easily replaced by other components, e.g., those provided by third parties.

For each component, public interfaces are defined, that can be either accessed by components provided with the reference implementation, or by components provided by independent component providers. The WSMX reference implementation provides the complete implementation of all of the components, but users of WSMX may still decide to use components provided by other providers.

In subsequent sections the interface of each of the components is presented. For detailed and the most updated descriptions of the WSMX infomodel, the reader is referred to the WSMX code base at SourceForge. As the WSMX design is still being refined, the WSMX infomodel is still subject to some future changes and extensions. The initial proposal of external components interfaces has resulted from the practical experiments carried during WSMX software implementation.

3.1.1 Core Component Interface

There is no specific interface defined for the Core Component. Although it is possible to envisage implementation of WSMX in which components communicate directly without use of the Core Component at all, it is recommended to have the Core Component coordinate and manage all other components. No any specific interface is enforced at presesent.

Although at this stage the specification is under development, the interface of the Core Component is not standardized. This is subject to change in the future, as federated WSMXs are planned, where the Core Components might be distributed (in the current architecture design, the core component remains the only centralized entity of the whole system) and provided by different vendors.

In the reference implementation we use an intermediate layer of wrappers is provided in order to interface the Core Components with all the other components. To enable one component of the system to communicate with another component, its wrapper must implement the interfaces of the components with which this component communicates.

3.1.2 Resource Manager Interface

The ResourceManager is the interface for the WSMX persistent storage. The component implementing this interface is responsible for storing every data item WSMX uses. The domain model of WSMX is based on the WSMO API which is just a set of interfaces representing the data structure of WSMO. A component following the ResourceManager interface provides an implementation of those interfaces which should be used to transfer data between different WSMX component. This interface needs further extensions to enable standardized methods for preserving any non-WSMO-related data in the future.

Method Summary
`void`	`insertWebService(WebService service)()` Inserts Web service in the Resource Manager repository
`void`	`updateWebService(WebService service)()` Updates Web service in the Resource Manager repository
`WebService`	`getWebService(Long id)()` Gets Web service from the Resource Manager repository
`WebService`	`getWebService(URIRef uri)()` Gets Web service from the Resource Manager repository
`Collection <WebService>`	`getWebServices()()` Gets Web services from the Resource Manager repository
`void`	`insertGoal(Goal goal)()` Inserts Goal in the Resource Manager repository
`void`	`updateGoal(Goal goal)()` Updates Web service in the Resource Manager repository
`Identifiable`	`getIdentifiable(URIRef uri)()` Gets any WSMO Entity from the Resource Manager repository
`void`	`insertIdentifiable(Identifiable identifiable)()` Inserts any WSMO Entity from the Resource Manager repository

3.1.3 Service Discovery Interface

The WSMO discovery provides a conceptual model for service discovery that exploits WSMO formal descriptions of goals and web services. A discovery component implementing the Discovery interface provides a full implementation of discovery mechanism as defined in WSMO [Keller et al., 2004].

For keyword-based discovery a simple implementation is already available and integrated with WSMX.

Method Summary
`Collection <WebService>`	`discover(Goal goal)()` Calls discovery providing only Goal and expecting to get as result a Collection of Web services

3.1.4 Service Selection Interface

Selection defines an interface for the selection component. A business partner may have more than one preference the selection of the most suitable Web service – if there is more than one service that satisfies the goal, only one is chosen, based on these preferences.

Method Summary
`WebService`	`select(Collection<WebService> services, Preferences preferences)()` Selects Web service based on Preferences

3.1.5 Data and Process Mediators Interfaces

A DataMediator defines the interface which all the ontology-to-ontology mediators have to implement. A WSMX component implementing this interface has the role of reconciling the data heterogeneity problems that can appear during discovery, composition, selection or invocation of Web services. This interface is dedicated for the runtime phase mediation process. The run-time component implementing this interface has the role of retrieving from storage the already-created mappings (by issuing appropriate events), to transform them into rules, and finally to execute them against the incoming instances in order to obtain the target instances. Since the mappings represent the connection point between the two sub-components (design-time and run-time) one of the dependencies for the run-time component relates to the mapping storage level as well. Another crucial dependency relates to the reasoning system used for executing the rules in the final stage of the mediation process.

Method Summary
`Collection <Identifiable>`	`mediateData(URIRef sourceOntologyID, URIRef targetOntologyID, Collection<Identifiable> ontologyFragment)()` Calls the mediator and returns the mediated fragment of ontology.

ProcessMediator defines the interface that a Process Mediator has to implement. A WSMX component implementing this interface has the role of reconciling the public process heterogeneity that can appear during the invocation of Web services. That is, ensuring that the public processes of the invoker and the invoked Web service match. Since both the invoker and the Web service publish their public processes as choreographies, and the public processes are executed by sending/receiving messages, the Process Mediation Component will deal with reconciliation of message exchange patterns based on choreography.

Method Summary
`Collection <Message>`	`mediateProcess(Message incomingMessage, Choreography requesterChoreography, Choreography providerChoreography)()` During the communication between two parties, this method computes what message(s) has to be generated based on the content of an incoming message and the choreographies of the parties involved.

3.1.6 Communication Manager Interface

The Communication Manager is responsible for dealing with the protocols for sending and receiving WSML messages to and from WSMX. It consists of Invoker and Receiver interfaces. WSMX expects the contents of all messages it receives to be expressed in WSML. The Communication Manager receiver interface provides methods to accept WSML messages. The WSML messages may represent a goal to be achieved or be a message corresponding to a choreography or orchestration instance that already exists. The Communication Manager accepts the message and handles any transport and security protocols used by the message sender. The receiver interface represents also the external behaviour of the system, which is described in the Section 3.2.

Method Summary
`WSMLConfirmation`	`sendWSMLMessage(WSDLDocument wsdl, PortType portType, WSDLOperation operation,WSDLMessage message)()` Use this method to send a WSML message to a service endpoint described in a WSDL document.

Method Summary
`WSMLConfirmation`	`realizeGoal(WSML goal)()` Implementation of this method completely fulfills the specified goal
`Collection <WebService>`	`receiveGoal(WSML goal)()` Enables service discovery. WSMX discovers service descriptions that match the formal expression of the user's goal in WSML
`WSMLConfirmation`	`receiveMessage(WSML message)()` Enables sending a message to WSMX as part of an ongoing interaction. A service requester wishing to use WSMX registers their description including the choreographies that they support. This method is used to send a message to WSMX as part of an enactment of such a choreography.
`WSMLConfirmation`	`storeEntity(WSML entity)()` Allows for storing a WSMO description into WSMX. WSMO describes four top-level elements corresponding to ontologies, services, goals and mediators. Before instances of these elements can be used by WSMX, they first must be made known to WSMX.

3.1.7 Choreography Engine Interface

A Choreography defines how to interact with the web service in terms of exchanging messages – the so-called communication patterns.

Method Summary
`ChoreographyResult`	`executeRequestChoreography(MessagePart messagePart, WebService webService, ChoreographyID choreographyID, ConversationID conversationID)()` Executes request to choreography
`ChoreographyResult`	`executeRequestChoreography(MessagePart messagePart, ConversationID conversationID)()` Executes request to choreography

3.1.8 Web Service Modeling Toolkit Interface

The Web Services Modeling Toolkit is a new component for WSMX and we have not yet defined a standard interface for WSMT components. This is subject to change in the future.

3.1.9 Reasoner Interface

There is no agreement on a stable Resasoner interface so far. Once work on WSMO reasoner implementation will finalize, its interface will become standardized through WSMX infomodel.

3.2 External Behaviour

The functionality provided by the WSMX system as a whole can be described in terms of its entry points. Entry points are the standardized interfaces of WSMX, enabling the communication with any external entities requesting services. More details on system functionality can be found in the following section that formally specifies the desired operational behaviour of WSMX, serving not only as a reference for developers but also as a means of validation and model-checking.

In the current version of the system the execution semantics for four possible scenarios is defined each of them starting with a separate entry point. These four mandatory entry points must be available in each working instance of the system, which is WSMX-compliant. Entry points also define the required functionality of any WSMX compliant system. By selecting a given entry point the predefined execution semantics is triggered. These four obligatory entry points enabling execution of any of four available execution semantics are:

In addition to these four entry points WSMX provides an engine to support dynamic execution semantics enabling execution of any formal description of system behaviour. In this way additional functionality can be defined in the future.

The four entry points described in this section are fundamental to describing sequence diagrams, which are presented later in this document.

3.3 Execution Semantics

Execution semantics, or operational semantics, is the formal definition of the operational behaviour of a system. It describes in a formal language how the system behaves. Because the meaning of the system (to the outside world) consists of its behaviour, this formal definition is called "execution semantics".

WSMX has two functions in the complete body of WSMO: it serves both as a testbed for WSMO and as an example of its implementation. This example of implementation could, for instance, be used to demonstrate the viability of WSMO or as a reference for others who want to build their own WSMO execution environment. Unlike the WSMO work, it is clearly not prescriptive. It does not tell others how to build a WSMO execution environment. In that sense, the execution semantics described here are strictly part of the design process of WSMX. Its meaning and relevance should be found in improving either the design process or the result of this process, the actual software. A perfect design process (not just software design) should result in a design that is both an adequate response to the user's requirements and a feasible directory for the implementer who will build the end result. A design therefore serves two purposes, both to guide the builder in the work of building the system, and to certify that what will be built will satisfy the user's requirements.

Several methods exist to formally model software behaviour. These methods have different characteristics: some are more expressive than others, some are more suited for a certain problem domains than others; some methods are graphical, some are logical; some methods have tool support for modelling, for verification, for simulation or for automatic code generation and others do not. To choose a method requirements are defined initially: first of all, the method should be as expressive as needed to define the behaviour of the software. Then, as outlined before, since the main advantage of using formal methods lies in improving the developers' understanding of the system, the resulting model should be easy to understand and unambiguous in its meaning. Thirdly, the method should allow verification of certain interesting properties of the modeled system. Lastly, since some methods are better suited for modeling a particular problem domain than others, the method should be suitable for modeling our specific problem domain [Kiepuszewski, 2002].

For WSMX the execution semantics is modeled using classical Petri nets. The tool CPNTools [Rantzer et al., 2003], makes it possible to model so-called high-level Petri-nets [Aalst et al., 1994], extending classical Petri nets with hierarchy, color and time. The hierarchy feature makes it possible to decompose a transition into so-called subnets, which allows to break down a large model into smaller pieces and to model them incrementally. Timed Petri nets introduce the notion of a global time, in which every token gets a certain time-stamp; this makes it possible to describe time duration of transitions. Colored Petri nets are classical Petri nets extended with the notion of identity. The addition of color means basically that tokens can be distinguished from each other, for instance by giving every token a certain type and value. Since every token now has a certain value, every transition gives its output tokens certain values; or to put it another way, a transition now becomes a relation between the value of the input tokens and the value of the output tokens. In addition, a transition can state conditions over its input tokens, that must be satisfied before the transition can become enabled. Extending Petri nets with hierarchy does not improve their expressivity, but it does make them more concise and readable.

The execution semantics of WSMX follows the component-based paradigm. This means that the execution semantics of the complete system treats components as 'black-boxes' – decisions that take place inside those components are not medeled. For a complete model of the behaviour of the system, the execution semantics of the components needs to be taken into account.

There are four WSMX execution semantics, one for each of the entry points described in the previous section: one-way goal execution, list of Web Services fulfilling a given goal, Web service execution with choreography and store WSMO entity. These execution semantics are described in the following subsections.

3.3.1 One-Way Goal Execution

Figure 2 presents the definition of the system behaviour, given this entry point. The behaviour of some components is specified in subsequent diagrams; this is denoted by a blue rectangle underneath the transition (e.g. discovery subnet). The transitions are represented by using rectangles, and the places where the tokens can be placed by ovals.

First, a list of known_Web_Services is created by combining internally known Web services with external ones in case the service requester wants to check them too. From this list, one Web service is picked and an attempt made at matching. If necessary, mediation is requested, by placing a token in the place need_mediation. This mediation may succeed, after which the matching can continue. The mediation may also fail, after which a new Web service is needed (the chosen Web service cannot be mediated, and is useless for this goal).

The discovery process continues (with or without mediation) until a list of Web services is completed. The list of Web services is completed when a specific number of Web services is collected or if there are no more Web Services on the known_WSs list. The list of found Web services is returned as a result of the discovery process. The list will be empty if no Web services are found. This means that all the Web services have been tried for matching, but none of them is suited.

After discovery, the selection component selects the web service that best fits the user's preferences. Finally, the invocation component invokes the selected web service.

The process of discovery (Figure 3) includes matching transition. This models the range of possibilities that can occur when deciding whether a web service matches a goal. There are three possibilities here: either there is a matching (denoted by matching_ok), or there is no matching which means the discovery should retry using another web service (denoted by matching_error, new_WS_needed). The third possibility is that mediation is needed, denoted by placing a token in need mediation, and waiting until this mediation is successfully finished signaled by mediation_ok.

The discovery is (from the viewpoint of the WSMX system) a nondeterministic choice: either a discovery is found, or an error occurs or mediation is needed; this choice is made not by the WSMX system, but by the discovery component.

This nondeterministic exclusive OR is modeled by having an output place matching_out, whose token is consumed either by the matching_out_ok transition, or by the matching_out_error transition, or by the need_mediation transition.

The same pattern is repeated for modeling the other components, all of whose outcomes are nondeterministic exclusive ORs (from the viewpoint of WSMX). Both the mediation component and the selection component can either fail or succeed, from the viewpoint of WSMX. This is modeled in Figures 4 and 5.

The invocation component is modeled slightly differently, since this component retries invocation a number of times, if network time-outs or other temporary errors occur. This component is shown in Figure 6; each time an error occurs, a counter is incremented. If the counter does not exceed a certain threshold, the invocation is retried; otherwise, the invocation fails.

3.3.2 List of Web Services Fulfilling a Given Goal

In this scenario, only Discovery and Mediation components carry out their tasks. Each Web service in the WebServices[] list is already mediated to the requester's Ontology, if necessary, and has its choreography. Since the returned list of Web services is specified in the requester's ontology, the requester can understand them and choose which one should be executed. Exchange message patterns are specified by the choreography, thus both parties know what data is required, and in what order, to carry out the requested service functionality.

This execution semantics is quite relevant when a decision about which Web Service has to be executed needs to be made outside the WSMX system. This decision could be made manually, or by some Web service evaluation program.

The process of generating a list of Web services fulfilling a given Goal is depicted in Figure 7. The discovery subnet is invoked in a loop until the desired number of Web services is collected or until there are no more Web Services to discover. Finally, the list of discovered Web services is sent to the service requester.

3.3.3 Web Service Execution with Choreography

In this scenario, a communication according to the choreography previously returned, together with the Web service located and the Ontology Instance (Figure 8) takes place. As depicted in Figure 9, the first time this entry point is invoked, a new instance of choreography associated with the given Web service is created. A unique identifier is given to refer to the newly-created choreography. In the next invocation, this unique identifier is used to determine the currently processed step in the choreography.

Next, when the choreographyID is found or created, communication can be carried on. The system checks whether for a given Ontology Instance mediation is required, and subsequently performs the invocation.

Choreography might include miscellaneous activities. There could, for instance, be confirmation steps or decisions on the requester side included. The main goal of Choreography is to compose Web services and to execute them as the requester expects.

3.3.4 Store WSMO Entity

4. Related Systems

Implementations for SWS concepts are currently the subject of intensive research. Apart from WSMX as the reference implementation of WSMO, other implementations based on SWS concepts also exist such as IRS [Motta et al., 2003], OWL-S [OWL-S, 2004] or METEOR-S [Sheth et al., 2004]. It is the intention of WSMX to be interoperable with these systems where possible.

The main components of IRS (Internet Reasoning Server) are the IRS Server, the IRS Publisher and the IRS Client. The IRS Server holds descriptions of SWSs. The IRS Publisher links Web services to their semantic descriptions within the IRS server and generates a wrapper which allows a Web service to be invoked. An IRS user asks through the IRS Client for a task to be achieved, and accordingly the IRS server selects and invokes an appropriate Web service. Recently, IRS III has provided infrastructure for creating WSMO-based SWSs, building upon the previous implementation of IRS.

A set of disparate OWL-S tools exists [OWL-STools], but not a complete execution environment based on OWL-S concepts. For example, an OWL-S Editor allows the maintaining of OWL-S service descriptions, an OWL-S Matcher provides an algorithm for different degrees of matching for individual elements of OWL-S, an OWL-S Axis plugin advises service providers on how to provide service description using OWL Services, etc. A complete list of OWL-S tools and the description of their functionality is available at http://www.daml.org/services/owl-s/tools.html.

The main components of METEOR-S are an Abstract Process Designer, a Semantic Publication and a Discovery Engine, a Constraint Analyzer, and an Execution Environment. The Abstract Process Designer allows a user to create the control flow of the process, using BPEL constructs. The Semantic Publication and Discovery Engine provide semantic matching based on subsumption and property matching. The Constraint Analyzer dynamically selects services from candidate services, which are returned by the discovery engine. The Execution Environment performs actual late binding of services returned by the constraint analyzer and converts abstract BPEL to executable BPEL.

5. Conclusions and Further Directions

In conclusion, future versions of WSMX will be designed and developed as an execution environment for the dynamic discovery, selection, mediation, invocation and interoperation of SWSs. Through the research on WSMX, a rationale for an architecture for SWS systems is provided. A SWS architecture blueprint is provided including its execution semantics as well as any aspect that should be compulsory in any SWS-related systems. Since the initial stages a component-based architecture has been delivered, ensuring a solid foundation for later extension. All the components' design are based on the WSMO conceptual model. These components will be extended to fully support WSMO and to provide a fully-fledged enterprise system for execution of the SWS.

Acknowledgments

The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.

The editors would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this document.

The authors would like to thank to Michael Altenhofen, Manfred Hauswirth and Farrukh Najmi for their valuable inputs.

References

[Aalst et al., 1994] W.M.P. van der Aalst, K.M. van Hee, and G.J. Houben. Modelling workflow management systems with high-level Petri nets. In G. De Michelis, C. Ellis, and G. Memmi, editors, Proceedings of the second Workshop on Computer-Supported Cooperative Work, Petri nets and related formalisms, pages 31-50, 1994.

[Kiepuszewski, 2002] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2002.

[Motta et al., 2003] E. Motta, J. Domingue, L. Cabral, and M. Gaspari: IRS-II: A Framework and Infrastructure for Semantic Web Services. In 2nd International Semantic Web Conference, 2003.

[Rantzer et al., 2003] A.V. Rantzer, L.Wells, H.M. Lassen, M. Laursen, J.F. Qvortrup, M.S. Stissing, M. Westergaard, S. Christensen, and K. Jensen. Cpn tools for editing, simulating and analysing coloured petri nets. In W.M.P van der Aalst and E. Best, editors, Applications and Theory of Petri Nets 2003: 24th International Conference, ICATPN 2003, volume 2679 of Lecture Notes in Computer Science, pages 450-462. Springer-Verlag, 2003.

[SWSA, 2004] C. Bussler, M. Dean, A. Eberhart, C. Goble, M. Huhns, T. Finin, F. McCabe, J. Miguel, J. Mylopoulos, N. Sadeh, A. Sheth, M. Paolucci, S. Williams, M. Zaremba: Semantic Web Services Architecture Requirements v1.0, June 2004, available at http://www.daml.org/services/swsa/swsa-requirements.html, 2004.

[UDDI] T. Bellwood, L. Clment, and C. von Riegen (eds.): UDDI Specification Version 3.0.1. UDDI Spec Technical Committee, October 2003, available at http://uddi.org/pubs/uddi_v3.htm, 2003.

[WSDL] R. Chinnici, M. Gudgin, J. Moreaum, and S. Weerawarana (eds.): Web Services Description Language (WSDL) Version 1.2. World Wide Web Consortium, March 2003, available at http://www.w3.org/TR/wsdl20/, 2003.