This document provides answers from the WSMO working groups to aspects pointed out in the Team Comments on the W3C member submission of the Web Service Modeling Ontology WSMO, the Web Service Modeling Language WSML, and the Web Service Execution Environment WSMX, collectively referred to as the WSMO Submission, submitted on 04 April 2005 and acknowledged by the W3C on 03 June 2005.
Critical aspects in the team comments mainly concern the alignment with existing W3C technology recommendations for Semantic Web and Web Services, the concept of Mediators as an essential element for Semantic Web Services, and the provision of use cases for exemplifying the problems that our proposed technology addresses. The aim of this document is to clarify our intentions and position with respect to these comments and also provide a basis for discussion within the ongoing workshop and for further activities emerging from the ongoing workshop.
The document is structured as follows: Section 1 recalls and clarifies the objectives of WSMO, Section 2 addresses the relationship between the WSMO Submission and W3C Semantic Web technology recommendations, Section 3 covers the relationship to existing Web Service technologies in more detail, Section 4 aims at clarification of the central concept of Mediators in WSMO, and Section 5 presents Semantic Web Service technology developments and use case testing of WSMO.
The aim of the Web Service Modeling Ontology WSMO [Lausen et al., 2005] is to realize Semantic Web Service technologies for automated discovery, composition, conversation, and execution of Web Services. To this end, we identify the core elements for precise and unambiguous Semantic Web Services descriptions and define a concise ontology (WSMO) along with an appropriate description language (WSML) and the reference architecture of an execution environment for Semantic Web Services that implements the WSMO framework (WSMX). For the justification of the approach requested in the W3C team comments, we refer to the Web Service Modeling Framework WSMF [Fensel and Bussler, 2002] that explains the conceptual foundation of WSMO, WSML, and WSMX in scientific depth.
Figure 1 shows the four top level elements that we consider as the core elements for Semantic Web Service technologies: Ontologies shall provide the consensual semantic terminology definitions that serve as the data model within Semantic Web Services, since we consider ontologies as the means that facilitate seamless information exchange during Web Service usage; Goals specify the objectives that a client wants to achieve by using Web Services; Web Services carry the semantic description of capabilities (functional description) and interfaces (that describe how to consume the service and how its functionality is achieved by aggregation of other Web Services) in order to facilitate automated discovery, composition and usage; Mediators allow to handle heterogeneities between Web Services and other WSMO elements that naturally arise in open and distributed environments like the Internet.
| Figure 1. The top level elements of WSMO |
 |
The design of the WSMO Submission based on and aligned with existing technologies and W3C recommendations as far as possible, however including proposals for enhancement where we consider these recommendations not sufficient in their current state for the specific requirements of Semantic Web service descriptions.
One essential remark on the W3C team comments is the relation of the WSMO Submission to existing W3C recommendations in the Semantic Web area, i.e. the Resource Description Framework (RDF) and the Web Ontology Language (OWL) as Semantic Web languages. This comment mainly refers to design and specification of the Web Service Modeling Language WSML. The position of WSML with respect to these two W3C recommendations is explained in further detail in the following.
It could be argued that RDFS could be used for the specification of the WSMO ontology itself. We have chosen to use OMG's Meta Object Facility [MOF] for the moment for the following reasons:
We consider the distinction between different layers of meta-modeling in MOF important and do not suggest to specify all meta-layers in one flattened RDF graph. The actual language we are using for specifying WSMO, WSML is well layered on top of RDFS.
WSML and RDFThe Web Service Modeling Language
WSML [de Bruijn and Lausen, 2005] specifies a formal language for the description of Semantic Web Services,
based on WSMO. As described in the submission in detail
(see http://www.w3.org/Submission/WSML/#sec:wsml-rdf),
WSML is layered on top of RDF and RDFS in a very similar way to how OWL Lite
and OWL DL are layered on top of RDFS. Namely, the RDF graph for a WSML description
is obtained through a translation
The relationship of WSML as the language provided for WSMX and OWL may be best explained by comparing it with the relationship of OWL and OWL-S. Similar to WSMO, WSML, and WSMX, OWL-S aims for a description framework for Semantic Web Services. In the beginning, this should be achieved by simply defining an Ontology in OWL. However, it became obvious that OWL does not provide the necessary means to actually specify important aspects of web services such as pre- and post-conditions or process aspects. Meanwhile OWL-S recommends various languages for this purpose (KIF, SWRL, and DRS) and is therefore not precisely an ontology in OWL, but tries in some sense to tweak additional semantics not expressible in OWL into an OWL ontology. This should be not understood as a critique on OWL, because OWL was not designed for being a meta-language in the sense of what we conceive necessary for SWS description. Actually, OWL-DL does not even provide very limited meta-layer abilities; for instances, it is not possible to define concepts being instances of other concepts.
Therefore, from the start the design of WSML took a radical different approach. It defined a conceptual model called WSMO and it defined a structured family of four languages to formalize this model:
In a nutshell, the underlying philosophy is to have two languages based on rules and description logic, with their intersection layered below and their union layered above. Remarkably, this core design seems to be reflected in current updates of the layer cake of the Semantic Web.
[1] It also restricts RDFS in its usage to stay compliant with the style OWL restricts the usage of RDFS.
Another aspect mentioned in the W3C team comments on the WSMO Submission is the relation to existing Web Service technologies and respective W3C recommendations which we explain in more detail in the following.
The current Web Services technology stack comprises a messaging technology for Web Services (SOAP), a service interface description language (WSDL), and a registry technology for Web Services (UDDI) which is not subject of the W3C's efforts. These technologies provide purely syntactic support for realizing and using Web Services: a system developer needs to manually retrieve a Web Service description from a UDDI registry, then manually inspect its usability by examining the WSDL description, and then implement the intended usage of the Web Service within her application. In this respect, the current Web Service technologies appear to fail the aim of support for automated Web Service usage which is one of the promises of service-orientated software architectures on the Web.
Addressing this point, the aim of Semantic Web Services is to provide more sophisticated technologies for automated Web Services usage: based on exhaustive semantic description frameworks like WSMO, intelligent mechanisms are envisioned for automated discovery, composition, conversation, and execution of Web Services. Thus, these frameworks complement existing Web Service technologies: while Semantic Web Service technologies are mainly concerned with appropriate semantic descriptions and respective technologies for reasoning on these, the current Web Service technology stack is mainly concerned with execution of Web Services; since both aspects are needed, integrated Web Service technologies need to combine semantically enabled technologies for automated Web Service discovery, composition and resolving heterogeneities in the conversations between Web Services as well as Web Service execution technologies.
The purpose of the semantic element descriptions in WSMO along with WSML as the specification language is the provision of a solid basis for semantically enabled, automated discovery, composition, and conversation determination, while WSMX realizes these as a reference implementation, including execution of Semantic Web Services and making use of the underlying technologies of the Web Services stack. Therefore, we utilize and support existing Web Service technologies by using a UDDI-based registry as the infrastructure for storing and retrieving Semantic Web Service descriptions in WSMX, and we provide a grounding to WSDL and SOAP for execution of Web Services. In the longer term, we intend to support also new Web Service execution techniques that shall overcome the deficiencies of current technologies with respect to support for ontologies and message-based communication, as we will explain below.
The W3C Web Service Glossary [Haas and Brown, 2004] defines choreography to be concerned with "the interactions of services with their users. Any user of a Web service, automated or otherwise, is a client of that service. These users may, in turn, be other Web Services, applications or human beings." Therefore, two technologies are defined in W3C working efforts: WSDL as a description language of the interface of a Web Service for consuming its functionality, and WS-CDL as a choreography description language for the global interaction protocol between two or more Web Services.
WSMO defines "Service Interfaces" as the part of a semantic description that is concerned with the interactions between a Web Service, its client, and other Web Services utilized for achieving the service functionality. A WSMO Service Interface consists of 2 notions: the Choreography interface that describes the interface of the Web Service for interaction with the client in order to consume its functionality (this corresponds to the WSDL description of a Web Service), and the Orchestration interface that describes how the Web Service interacts with other Web Services in order to achieve it functionality (this conforms to the definition of orchestration in the W3C Web Service Glossary). WSMO defines a formal description model for these Service Interfaces, which is based on ontologies for defining the content of the information interchanged and Abstract State Machines for describing the dynamics in Service Interfaces. This formal description of Service Interfaces allows to determine whether the interactions required for automated utilization of a Web Service can be achieved successfully - which to our understanding is a central challenge for realizing the promise of automated Web Service usage.
In our model, we do not aim at a description of choreographies, i.e. interaction protocol descriptions from a global perspective as supported by the WS-CDL working draft of the Web Services Choreography Working Group. The reason is that we focus on the description of their individual behavior of single service described in choreography interfaces only. We do not want to have a central control unit for executing interactions that would require such choreography descriptions as in WS-CDL, as we understand Web Service executions to happen by information interchange between Web Services in a peer-to-peer manner, not necessarily synchronously and coordinated. Nevertheless, alignment and utilization of existing technologies and language specifications for interaction-related aspects like WS-CDL and e.g. BPEL4WS is to be considered for future versions of Service Interface definitions; the primary aim of WSMO Service Interface descriptions is the definition of a sound formal description model that can be extended to prosperous technologies for execution integrating the semantic description of the interchanged information which current standards do not integrate.
The current infrastructure for executing Web services is built around WSDL descriptions for simple Web Service interfaces, WSMO provides groundings to WSDL1.1 and 2.0 [WSDL] for Web Service execution. To make a service having only a WSDL description available to an execution environment such as WSMX, a WSMO description for the service must be created. This makes the service description available to the execution environment for discovery and composition but does not solve the problem of how to link to the invokable implementation of the Web Service described by WSDL. The WSMO description must be mapped to the WSDL definition both in terms of data and behaviour. The following briefly outlines the WSMO Grounding to WSDL; the complete specification is provided in [WSMO Grounding].
There are two important aspects regarding the WSMO Grounding. The first is that the data model used to define the input and output messages for WSDL services is described using one or more XML Schemas [XML Schema] while the data model for a WSMO service is defined using the more expressive conceptual model provided by one or more WSMO ontologies. This leads to the requirement of a mapping between the instances of ontological concepts used to define the input and output messages of a WSMO service choreography and the corresponding input and output messages defined in terms of XML Schema in the WSDL service description. The second aspect of grounding is the specification of how the concepts representing the incoming and outgoing messages for the service in the WSMO choreography description can be mapped to corresponding messages in specific WSDL operations. In the WSMO service choreography model messages loosely correspond to dynamic functions in an abstract state machine that can be updated by either the service, the entity interacting with the service or both. The grounding must provide the linking of this general concept to the message paradigm of WSDL and additionally the necessary serialization details. Networking details, such as the underlying protocol (e.g. SOAP, HTTP) which should be used for passing the messages and how the XML data is encapsulated in the underlying protocol are then specified in WSDL. However, note that at the current state, we do not want to restrict ourselves to WSDL and a message oriented service paradigm, and also suggest a specific, asynchronous grounding to a SWS middleware as briefly outlined in Section 3.4 below.
Grounding WSMO Data Model to WSDLThere are three distinct activities that together facilitate grounding the data part of WSMO service descriptions to the XML Schema used by WSDL:
Lowering is required when a client using the WSMO description of a service for activities such as discovery, mediation and composition wants to make an invocation on the actual service using its WSDL interface description; lifting is required when the service responds using instances of XML data that need to be returned to the semantic client. The mapping rules can be created automatically at the same time as the generation of the ad-hoc WSMO ontology from an XML Schema.
Grounding WSMO Choreography to WSDLThe WSMO service choreography describes the external behavioral interface offered by the Web service to any potential service client. The choreography description is defined as a state machine made up of states, represented by WSMO concept instances, and the relations between them. For the purpose of marking inputs and outputs, certain concepts may be assigned one of the modes "in", "out" or "shared". The client may write (create or change) instances of concepts with modes "in" and "shared", and similarly it may read instances of concepts with modes "out" and "shared". The WSMO choreography also allows modes "controlled" and "static", but such concepts are not accessible from outside the choreography and as such they are not involved in grounding.
In WSDL, the externally visible behavioural description of a Web service is described in terms of interfaces, operations and messages. Messages can be sent and received by the service (including fault messages). Operations represent the simple exchange of messages following a specific message exchange pattern (MEP). For example, the simplest MEPs are "In-Only", which allows a single application message to be sent to the service, and "Out-Only", which symmetrically allows a single message to be sent by the service to its client. WSMO choreography annotates concepts representing messages with the mode having the value of either "in", "out" or "shared". Additionally, a WSMO choreography requires that all accessible concepts be annotated with grounding information in the value of the grounding non-functional property. There can be multiple grounding specifications that will describe the allowed values for this property and what they mean. In this specification, we describe what values the property can have to ground the concepts to WSDL messages, using the following rules:
Note: As described in Appendices A.2 and C of the WSDL Specification, the URIs for WSDL 2.0 components are created by combining the namespace URI with fragment identifiers that unambiguously identify components on any level of granularity within a WSDL file.
The communication paradigm in WSMO is not restricted to message exchanges. Communication between service requesters and service providers is described in an abstract way, to facilitate both existing Web Service standards based on message exchanges as well as other approaches. Exactly because of this abstraction, the WSMO specification might not seem to build on current Web Service standards but we do describe how current Web Service communication protocols could be used as a grounding for WSMO. On the other hand, we also envision a simpler, and more Web-like, communication paradigm for Web Services. Current Web Service standards (at least in their normative definitions) do not follow the Web paradigm of persistent publishing and reading of information. Instead they are built on point-to-point message exchanges between participants in a conversation (requester and provider of services). These point-to-point messages tightly bind participants to each other:
WSDL presumes a scenario where services can be accessed over various communication channels: a service offers a certain functionality interface at multiple endpoints. Each endpoint is bound to a concrete communication protocol. WSDL allows services to define their interface, existing of a set of operations. Each service can offer a number of endpoints, where the service interface is offered. The binding of an endpoint specifies how to access the service, i.e. which communication protocol to use. Each operation instantiates a generic message exchange pattern describing how the communication with the service proceeds by specifying the schema of each message in the exchange pattern. SOAP allows communication partners to package XML documents and to prescribe a processing model of such documents. The headers of a SOAP message can contain arbitrary meta information about the document that must (or may) be processed by receiving parties. WSDL defines two standard bindings: HTTP and SOAP/HTTP. The HTTP binding states that messages to and from a service (XML documents) are sent and received as HTTP POST and GET methods. The SOAP/HTTP binding states that messages are packaged using SOAP, which in turn uses an HTTP binding for the communication. WSDL does not prescribe the usage as SOAP as binding protocol. One can theoretically also use for example an email binding for service consumption, or a persistent message queue. SOAP in turn does not prescribe an HTTP binding; again one could theoretically use an email binding as communication protocol underlying a SOAP message exchange. However, the normative specifications only describe WSDL bindings to HTTP or to SOAP/HTTP.
Triple-space computing [Fensel 2004, Bussler 2005] addresses the limitations of message-based communication and decouples participants to a high degree. One could decouple participants to some extent inside the existing standards: WS-Addressing allows asynchronous communication over multiple HTTP channels, thereby decoupling participants in time, and XSD has the xsd:any data type, allowing arbitrary XML data to appear in a document thereby decoupling the participants in data format, but that solution is naive and not elegant. Decoupling participants in reference is not possible, since messages (with a specific addressee) are a starting point of WSDL. We believe approaches such as triple-space computing show the need to abstract from specific message-based communication, and also provision for the more Web-like approach of persistent publish and read. It is exactly because of the limitations of message-based point-to-point communication that WSMO builds on a more abstract communication paradigm. We do not limit ourselves to WSDL over HTTP or SOAP/HTTP, but also allow a persistent publish and read, that decouples the participants to a high degree. Therefore WSMO does not explicitly ground to WSDL and SOAP, but it does offer such a grounding as one possibility.
The W3C team comments mention the WSMO concept of Mediators as an essential contribution, but request more insights on techniques, architecture and definitions. The following addresses these comments with respect to the respective working drafts of the WSMO working group.
Heterogeneity is an inherent characteristic of open and distributed environments like the Internet; WSMO captures this by defining mediators as a first class citizen of Semantic Web Services. A Mediator is used as a third-party component that connects heterogeneous components and resolves possibly occurring mismatches, thereby establishing homogeneity and interoperability that is not existing a priori. We identify three levels of mediation relevant for Semantic Web Services: mediation between heterogeneous terminologies (data level), mediation between heterogeneous communication patterns (protocol level), and mediation of heterogeneous business processes, i.e. the business logic of services (process level). In order to resolve mismatches that possibly occur between the four top level elements that WSMO identifies as the core building blocks of Semantic Web Services, we differentiate four types of Mediators: OO Mediators connect and mediate heterogeneous ontologies in order to establish semantic interoperability between components that are to interact, GG Mediators connect Goals and denote their semantic interrelationship in order to allow definition of goal ontologies, WG Mediators link Web Services to Goals in order to establish usability of a Web Service for resolving a Goal if this is not given a priori, and WW Mediators mediate between Web Services that are ought to interact when interoperability is not given a priori.
The constituting description elements of WSMO Mediators are the heterogeneous components between which mismatches are to be resolved (source components), the target component that receives the mediated source components, and the mediation service that provides the facilities for resolving mismatches, consisting of the mediation definition (i.e. how mismatches are resolved in form of mapping rules or mediation patterns) and an execution facility for these (which itself is most probably a Web Service that can process the respective mediation definition). These description elements denote the general structure of WSMO mediators, which is refined in the respective mediator types as follows.
Below we outline the mediation techniques for the respective that are currently developed in WSMO working efforts, while we refer to [WSMO Mediators] for the detailed specification of WSMO mediators.
The concept of Mediators in WSMO is not restricted to specific mediation techniques, but instead in indented to be open for different implementations that fulfill the required mediation. The fact that automatic, semi-automatic or even manual methods are used for creating the mediators, is irrelevant to the WSMO mediators definition - what matters is the mediation facility they provide. Nevertheless, it is of course envisioned to develop sophisticated techniques for data, protocol, and process level mediation. The following outlines respective efforts within the Web Service Execution Environment WSMX.
Following the descriptions and the context the WSMO mediators are used in, WSMX data level mediation tackles data heterogeneity problems from an ontological perspective. Data to be mediated as well as mediated data to be delivered are both expressed in terms of ontologies. As a consequence, the mismatches are resolved at the schema level by providing alignments of the analyzed ontologies. The alignments are to be used in various mediation scenarios, described at the conceptual level by the WSMO mediators and executed by the underlining technology provided within WSMX The general approach is that different OO mediation services are defined that consist of the source components, mapping definitions that resolve terminological mismatches between the source components on basis of state-of-the-art ontology integration technologies (regarding mismatch classification and the ontology mapping language), and an execution facility for the mapping language. We refer to [WSMX Data Mediation] for detailed information on this.
WSMX process mediation is dealing with the behavioural heterogeneity, and may be needed when the requester of a service attempts to invoke and execute the corresponding Web Service. The communication pattern (expressed by the choreography) 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, and this adjustment happens in neither of the involved parties’ side, but in the WSMX Process Mediator. That is, each time a message is sent by one of the two parties involved in the conversation, the process mediator determines if the message is expected by the other party. The mediator also considers situations when only part of a message or a combination of this message with a previously received one is expected, which is done by analyzing the choreographies of the parties. The resolvable mismatches are classified in so-called mediation patterns that define generic handling of possibly occurring mismatches on the process and protocol level. We refer to [WSMX Process Mediation] for detailed specification of this.
Another aspect mentioned in the W3C team comments is information about the concrete problems addressed by WSMO, as well as on real-word use cases that demonstrate and test the respective technologies.
As stated above, the aim of WSMO and related working efforts is to develop technologies and solutions for the complete usage process of Semantic Web Services wherefore the WSMO description framework shall serve as a basis. Therefore, we develop techniques, and test and evaluate these in several real-world use cases in the course of international projects, as outlined in the following.
To our understanding, the general Semantic Web Services usage process is comprised of publication, discovery, composition, selection, mediation, and execution of Semantic Web Services. The following list contains respective WSMO technology development efforts.
We are testing and evaluating the WSMO framework as well as the developed technologies in several exhaustive, real-world use cases. While a complete overview of all use cases in given in [WSMO Use Case Modeling and Testing], we briefly list the most important use cases below along with the main aspects addressed.
Other European projects that apply, develop, and test WSMO-enabled technologies for Semantic Web Services are Knowledge Web, Semantically-Enabled Knowledge Technologies (SEKT), Adaptive Services Grid (ASG), InfraWebs, Reasoning with Web Services (RW2), and Triple Space Computing (TSC).
[Bussler 2005] C. Bussler: A Minimal Triple Space Computing Architecture, Proceedings of the 2nd WSMO Implementation Workshop, 2005.
[de Bruijn and Lausen, 2005] de Bruijn, J., Lausen, H. (Eds.): Web Service Modeling Language (WSML), W3C Member Submission 3 June 2005, available at: http://www.w3.org/Submission/WSML/.
[Lausen et al., 2005] Lausen, H., Polleres, A.; Roman, D. (Eds.): Web Service Modeling Ontology (WSMO), W3C Member Submission 3 June 2005, available at: http://www.w3.org/Submission/WSMO/.
[Fensel & Bussler, 2002] D. Fensel and C. Bussler: The Web Service Modeling Framework WSMF, Electronic Commerce Research and Applications, 1(2), 2002.
[Fensel 2004] D. Fensel: Triple-space computing: Semantic Web Services based on persistent publication of information, Proceedings of the IFIP International Conference on Intelligence in Communication Systems, INTELLCOMM 2004, Bangkok, Thailand, November 23-26, 2004.
[Haas and Brown, 2004] Haas, H., Brown, A.: Web Services Glossary. W3C Working Group Note 11 February 2004, available at: http://www.w3.org/TR/ws-gloss/.
[MOF] The Object Management Group: Meta-Object Facility, version 1.4, 2002; available at: http://www.omg.org/mof/.
[WSDL] R. Chinnici, J-J. Moreau, A. Ryman, S. Weerawarana (editors): Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft, 10 May 2005, available at http://www.w3.org/TR/wsdl20/.
[WSMO Mediators] Scharffe, F. (Ed.): WSMO Mediators. WSMO Working Draft 29 April 2005, latest version available at: http://www.wsmo.org/TR/d29/v0.1/.
[WSMX Data Mediation] Mocan, A. (Ed.): WSMX Data Mediation. WSMX Working Draft 16 May 2005, latest version available at: http://www.wsmo.org/TR/d13/d13.3/v0.2/.
[WSMX Process Mediation] Cimpian, E. (Ed.): Process Mediation in WSMX. WSMX Working Draft 16 May 2005, latest version available at: http://www.wsmo.org/TR/d13/d13.7/v0.1/.
[WSMO Discovery] Keller, U., Lara, R.; Polleres, A. (Ed.): WSMO Web Service Discovery. WSML Working Draft 12 November 2004, latest version available at: http://www.wsmo.org/2004/d5/d5.1/v0.1/.
[WSMO Discovery Engine] Lara, R.; Lausen, H. (Ed.): WSMO Discovery Engine. WSML Working Draft 26 November 2004, latest version latest version available at: http://www.wsmo.org/2004/d5/d5.2/v0.1/.
[WSMO Use Case Modeling and Testing] Stollberg, M.; Lara, R. (Ed.): WSMO Use Case Modeling and Testing. WSMO Working Draft 13 April 2005, latest version available at: http://www.wsmo.org/TR/d3/d3.2/.
[WSMO Grounding] Kopecký, J.; Roman, D.; Moran, M.; Mocan, A.: WSMO Grounding. WSMO Working Draft 29 April 2005, latest version available at: http://www.wsmo.org/TR/d24/d24.2/v0.1/.
[XMLSchema] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn (editors): XML Schema part 1: Structures, W3C Recommendation, 2001, available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.
Michael Stollberg, DERI
Axel Polleres, DERI
Dieter Fensel, DERI
Jos de Bruijn, DERI
Matthew Moran, DERI
Eyal Oren, DERI
Emilia Cimpian, DERI
Adrian Mocan, DERI
John B. Domingue, The Open University
Editing Date: June 9 2005