This document is also available in non-normative PDF
This document identifies and describes the concepts within a Web Service Modeling Execution Environment (WSMX). By doing this, the aim is to provide not only a common vocabulary, meant to be used at different phases of this project, but also a central point of reference for the design and development team.
To identify the WSMX concepts, a detailed description of the real-world problem we intend to solve will be provided and analyzed. The concepts are identified based strictly on this description.
This document is structured in four parts. Section 1 is an introduction to the topic. Section 2 describes the real world problems. Sections 3 have the role of identifying the concepts. The last part, Section 4 contains the final conclusions.
For identifying the concepts involved in WSMX we start with a simple problem: considering that we have a certain goal, we need to identify a Web Service able to fulfil it. Each of them uses different ontologies and each of the ontologies consists of concepts and the relations between the concepts. Additionally, an ontology may use one or more mediators.
Every Web Service is described in terms of its functionality by its capability. A Web Service may also use mediators.
The goal that needs to be fulfilled may contain not only the description of the tasks the corresponding Web Service should provide, but also a list of preferences (for example, when the goal is to buy a certain book, a preference could be to buy it at the lowest price, from the most reliable Web Service).
There are two necessary steps for satisfying a goal: the discovery of all Web Services that may satisfy the goal and the selection of only one Web Service for the actual provision of the service. The first one deals with goal-capability matching, and the second one complying with the preferences. A possible problem that may occur during these two phases is the usage of different ontologies (the Web Services may use different ontologies from the requestor business partner). In this case, the requestor and the Web Services need to use mediators (the Web Service Modeling Ontology ooMediator), which in the first phase will provide the mapping between the goal and the capability, and in the second phase between the non functional properties of the Web Service and the preferences expressed by the requestor.
Analyzing the real-world problem description from the previous section, one can identify the following concepts: goal, ontology, concept (conceptDefinition), relation (relationDefinition), mediator (we are referring here only to the ooMediator), web Service, capability, and preference.
Most of these concepts are described in Web Service Modeling Ontology (WSMO), and we will keep these definition unaltered; the only exception is the concept preferences, a preference representing a constraint on one or more of the Web Service's non functional properties. A business partner may have more than one preference, for allowing the selection of the most suited Web Service – if there is more than one service that satisfies the goal, only one is choosen based on these preferences.
A preference is an instance of the WSMO axiomDefinition:
Listing 1. Preference definition
Although the preferences play an important role in the selection of the Web Service, since the selection problem is not yet addressed in the actual development of WSMX architecture and implementation, this concept will not be considered for the time being. As a consequence, the WSMX Conceptual Model represents a subset of WSMO.
This document covered an important phase in the development of a software tool: the identification of the involved concepts and of the conceptual model. The purpose of developing this conceptual model is to provide a common vocabulary and a central point of reference for the design and development team.
[Roman et al., 2004] D. Roman, H. Lausen, U. Keller (eds.): Web Service Modeling Ontology (WSMO), version 1.0 available at http://www.wsmo.org/2004/d2/v1.0/
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.
The editors would like to thank to all the members of the WSMO working group for their advices and inputs to this document.