This document contains brief descriptions of the relationship between WSMO
and other selected relevant technologies.
This document is a part of the WSMO Submission.
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.
The Web Services Description Language [WSDL] is
used to describe the message formats and simple message exchanges
(operations) provided by Web services. A WSDL description of a Web service
has the following three layers:
- Abstract interface, which contains one or more operations, the simplest
units of communication with the Web service. Operations involve one or
more messages according to one of an extensible set of message exchange
patterns. The format of messages is usually specified using XML element
declarations, most often in XML Schema [XMLSchema].
- Protocol binding, which specifies how the messages contained in an
interface can be serialized on the wire for exchange over a certain
network protocol. WSDL provides two predefined options for bindings -
SOAP and HTTP.
- Service endpoints - a set of addresses together with the appropriate
bindings, where a Web service makes available a single interface.
A WSDL description of a Web service can be seen as a syntactical contract
- it specifies what formats of messages can be sent to (or by) the Web
Service and what formats of messages, if any, can be sent as replies or
faults. On the other hand, WSMO describes functional and behavioral aspects
of Web services. Specifically, where WSDL talks about what kind of data can
be exchanged, WSMO specifies what the results of those message exchanges will
be. In this regard, WSMO and WSDL are fully complementary specifications.
Work is currently ongoing on specifying the grounding of WSMO in WSDL. The
grounding will describe the concrete relationships between a WSMO description
and a WSDL description of a Web service. In particular, we envisage that WSMO
descriptions will be used for discovering and automatic composition of Web
Services, and when a Web service is discovered, the grounding to the WSDL
description will specify which WSDL interface and operation(s) will provide
the requested service and where the Web service is physically located. WSMO
grounding will also specify how an invoking agent working on the semantic
level of ontology instances should construct the XML messages described in
WSDL, so that they can be sent to the service. Similarly, the grounding will
specify the reverse process of interpreting the XML messages coming from the
service as ontology instances on the semantical level.
Future work in the WSMO family of specifications, describing semantically
the choreography interface of a Web service, will also be grounded to WSDL
and thus specify the possible ordering(s) or operation invocations on one or
more Web services.
Universal Description, Discovery and Integration [UDDI] is the name of a group of Web-based registries
that contain information about a business or other entity and its technical
interfaces (or APIs). UDDI registries are used for publishing and discovery
of Web services.
The core component of UDDI is the UDDI business registration, an XML
document used to describe a business entity and its Web services.
Conceptually, the information provided in a UDDI business registration
consists of three components: "white pages" including address, contact, and
known identifiers; "yellow pages" including industrial categorizations based
on standard taxonomies; and "green pages", the technical information about
services that are advertised by the business. Green pages include references to
Web service descriptions, as well as support for pointers to various file and
URL based discovery mechanisms if required. [UDDIWP]
UDDI discovery is based on keywords or fixed standard taxonomies, whereas
WSMO discovery uses any of the semantics included in the WSMO description of
a web service. It may be possible to register and query WSMO descriptions in
UDDI registries or it may prove advantageous that a specific WSMO repository
is created with more natural querying capabilities. This question is yet to
be investigated. Currently WSMO does not impose any registry type.
Web Services Policy Framework [WSPolicy] allows
the description of specific Web services metadata (so-called policies) used for
expressing the capabilities, requirements, and general characteristics of Web
Services.
In our position paper for the W3C Workshop on Constraints and Capabilities
for Web Services [Arroyo et al. 2004], we
introduce a classification for capabilities and constraints on Web services,
most importantly the application-dependent distinction between functional and
non-functional properties. For a meaningful use, the authors would constrain
policy assertions to describe only non-functional capabilities,
constraints/requirements and other general characteristics, i.e. policies
should not be used to describe the functional aspects.
The WS-Policy specification suite defines policies for simple general
purposes like indicating languages and specifying general message
preconditions, and more importantly an accompanying WS-Security Policy
specification also defines policies for security requirements. Because many
major companies of the IT industry either authored or support WS-Policy, we
expect to see many more practical policy assertions being published. While it
is expected that Semantic Web services will ultimately represent such policy
assertions as logical conditions, even in their XML form they can usefully
complement the Dublin Core non-functional properties currently used by
WSMO.
Web Services Business Process Execution Language [WSBPEL] is a language and metamodel for specifying
business process behavior based on Web services. Processes in WS-BPEL export
and import functionality by using Web service interfaces or using extensions
that point to other programming interfaces. WS-BPEL is meant to be used to
model the behavior of both so-called executable and abstract processes.
Executable business processes model actual behavior of a participant in a
business interaction. Business protocols, in contrast, use process
descriptions (called abstract processes) that specify the mutually visible
message exchange behavior of each of the parties involved in the protocol,
without revealing their internal behavior.
Web Services Choreography Description Language [WSCDL] is an XML-based language that describes
peer-to-peer collaborations of parties by defining, from a global viewpoint,
their common and complementary observable behavior; where ordered message
exchanges result in accomplishing a common business goal. The Web Services
Choreography specification is targeted for composing interoperable,
peer-to-peer collaborations between any type of party regardless of the
supporting platform or programming model used by the implementation of the
hosting environment.
WSMO complements the orchestration and choreography specifications:
using semantic technologies Web services can more easily be discovered and
composed into the various processes; and one step further, semantically
described placeholders can be put in the processes, for automatic
discovery of suitable Web services.
Grid computing aims to provide the computational power and data management
infrastructure necessary to support the collaboration of people, together
with data, tools and computational resources. [Foster and Kesselman, 1999] The most
common problems that Grid addresses are computationally hard and data
intensive problems in science and engineering, along with resource sharing
and virtualization in complex networks.
A closer look at Grid computing shows that it has a many points in common
with Web services. Basically both Web services and Grid computing use the
concept of service and both architectures have the same underlying design
principles provided by Service Oriented Architecture (SOA). Latest directions
in Grid and Web services (like WS-Resource Framework - WSRF) try to
provide a common base for building Web services in Grid environments. We
expect that this convergence will continue and will result in Semantic Web
Services for Grids.
Semantic Web services promise to solve the remaining problem of proper
support for machine processable semantics, as currently human intervention is
needed to actually discover, combine, and execute services. Semantic Web
Services technologies will provide a fully mechanized infrastructure for
using domain-specific Grid services.
The relationship between WSMO and OWL, including a mapping between them,
is covered extensively in the document on Web Service Modeling Language.
The Semantic Web Rule Language [SWRL] is an
extension of OWL which adds support for Datalog-style rules over OWL DL
ontologies.
Instead of arbitrary predicates, SWRL allows arbitrary OWL DL descriptions in
both the head and the body of Horn rules, where a unary predicate corresponds
with an OWL class and a binary predicate corresponds with an OWL property.
While a subset of SWRL falls inside standard Logic Programming, a
SWRL knowledge base easily goes beyond this fragment, because the
straightforward combination of rules with OWL DL axioms leads to
immediate undecidability of the language.
On the one hand, this means different expressivity than standard rule
languages restricted to Horn rules only. The advantages of common rule
languages like Datalog which provide a fragment of first order logic where efficient
reasoning support for certain tasks like query answering is the focus are lost.
Thus, SWRL is not implementable on top of efficient rule engines and does not allow
for efficient query answering.
On the other hand, the strict use of OWL atoms in SWRL rules imposes unnecessary
syntactical restrictions on first order logic which are not motivated by computational
aspects; it is not possible to use predicates with an arity higher than 2 and function symbols
are disallowed.
In contrast, WSML aims at defining strict syntactical variants:
On the lower end the intersection of a Description Logic and Horn rules
is marked by the WSML-Core variant whereas full freedom of a first order language
is available in WSML-Full on the upper end.
In between, WSML-Flight and WSML-Rule mark syntactic variants which are efficiently
implementable on top of existing deductive database and logic programming engines.
WSMO and OWL-S are the two major efforts whose purpose is to specify
semantic information for Web services in order to enable automatic service
discovery, composition and execution. However, there are substantial
differences between these approaches (cf. [Polleres & Lara, 2005]).
WSMO is based on the Web Service Modeling Framework (WSMF) which separates
the elements needed to describe services into Ontologies, Web services, Goals
and Mediators. WSML is the language used to describe all of these elements.
OWL-S facilitates the description of services in terms of four different ontologies. The
upper Service ontology links to the Profile, Service Model and Grounding
ontologies. The Profile defines some non-functional properties of the service
and exposes some of the functionality by referencing Inputs, Preconditions
and Results from the Service Model. The Service Model describes the behaviour
of the Service in terms of processes and control constructs. The Grounding
binds processes, inputs and outputs in the process model to some transport
protocol described in a WSDL document. The major concrete differences are
explained in the following paragraphs.
A first significant difference between the two approaches is that OWL-S
does not separate what the user wants from what the service provides. The
Profile ontology is used as both an advertisement for the service and as a
request to find a service. In WSMO, a Goal specifies what the user wants and
the Web service description defines what the service provides through its
capability.
In OWL-S, the non-functional properties in the Profile ontology (such as
the service name, human-readable description and contact information) are not
explicitly based on standard metadata specifications. WSMO recommends the use
of widely accepted vocabularies such as Dublin Core [DublinCore] and Friend of a Friend vocabulary [FOAF] metadata. Also, non-functional properties can be
expressed in any element in WSMO, whereas in OWL-S this is restricted to the
Profile ontology.
In OWL-S, the Service Model does not make a clear distinction between
choreography and orchestration. It is not (at least explicitly) based on any
formal model, albeit that there are external works defining the formal semantics
of OWL-S processes. The Process ontology defines Atomic, Composite and Simple
processes. In Composite processes, control constructs such as decisions,
forks and loops can be used to model a workflow. OWL-S defines only one
Service Model per service, hence there is only one way to interact with the
service. In WSMO, the choreography and orchestration are specified in the
interface of the Web service description. A choreography describes the
external visible behaviour of the service and an orchestration describes how
other services are composed in order to achieve the required functionality of
a service. Because we expect that there could be more than one way of interacting
with a particular service, WSMO allows the definition of multiple interfaces
for a single service.
To define logical expressions, OWL-S provides the choice between SWRL, DRS and KIF.
By leaving the choice of the language to be used to the user, OWL-S contributes to the
interoperability problem, rather than solving it. Furthermore, the interaction between
the inputs and outputs, which have been specified as OWL classes, and the logical expressions
in the respective languages, is not clear. Furthermore, DRS does not have a semantics associated
with it and KIF is not web-compliant. WSMO provides a family of layered logical languages (see Web Service Modeling Language) which
enables us to combine conceptual modeling with rules on only the required
expressibility level, allowing descriptions to stay more explicitly within
efficiently computable fragments.
To facilitate linkage of heterogeneous resources between one another, various
kinds of mediation are required. For example, a service might need to make
use of an ontology specified in OWL rather than WSML, requiring mediation (in
this case ontology mapping) for the purpose of describing this service in
WSMO. In our opinion mediators are a key element in describing Web services
and therefore WSMO explicitly defines them in the conceptual model. OWL-S
does not explicitly address the issue of mediation: it is considered to be
handled by the underlying infrastructure.
To summarize, OWL-S is clearly more mature in certain aspects, including
the choreography and grounding specifications. However, WSMO provides a more
complete conceptual model as it addresses aspects such as goals and
mediators.
SWSL is another recent proposal for a language for describing Semantic Web
Services. SWSL has two parts, a rules language and a process ontology. The
SWSL-Rules sublanguage is closely related to WSML-Rules. Both languages are
largely based on F-logic and they mostly share the logical expression syntax.
However, the two groups have pursued complementary goals. WSMO was focused on
the end user and developed a "conceptual syntax" for top-level descriptions
of services, which we believe might make the specifications easier to read.
WSMO also paid special attention to the issue of OWL compatibility. To this
end, we defined WSML-Core as a subset of both OWL and WSML, which will serve
as a common ground for ontology interoperability. In contrast, SWSL's focus
was on extending the functionality of their rule-based language. In
particular, SWSL-Rules supports meta-reasoning with its HiLog and reification
extensions. It also supports prioritized defaults and classical negation by
incorporating Courteous Logic Programming.
On the process description front, WSMO and SWSL are more divergent, but
they nonetheless cover complementary parts of the problem space. WSMO has
focused on describing Web service choreography through ECA rules, which are
viewed as abstract state machines. In contrast, SWSL has developed a
first-order PSL-based process ontology, which allows the description of process
orchestration as well as message exchange among processes. Further work is
needed to determine to what extent the two approaches can be combined.
The first version of the Web Service Execution Environment
(WSMX) which is part of this submission
has been available since June 2004 at the SourceForge portal.
Apart from WSMX which marks a reference architecture and implementation for a
WSMO compliant execution environment there already exist several other ready-to-use
implementations and tools for WSMO to be briefly introduced here.
The Internet Reasoning Service (IRS-III) is an infrastructure
for publishing, locating, executing and composing Semantic Web services,
organized according to the WSMO framework, developed at the Knowledge Media Institute of the Open
University, UK, within the DIP
project.
WSMO Studio is a Semantic Web
Service editor compliant with WSMO and based on SWWS Studio. The WSMO Studio will be
available as a set of Eclipse plug-ins
that will allow easy reusability and extension from 3rd parties. WSMO Studio
is being developed jointly by OntoText
Lab and DERI Innsbruck within the DIP project.
wsmo4j is a Java API and a
reference implementation for building Semantic Web services applications
compliant with WSMO. Like WSMX, it is also being developed as an Open Source
project jointly by OntoText Lab and DERI Innsbruck.
The WSML Validator is an online
service (also available as a SOAP Web service) able to validate WSML
documents in the normative syntax. It is developed by DERI Innsbruck.
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 editor 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 further like to thank Frank Leymann for his valuable
input.
[Arroyo et al. 2004] S. Arroyo
et al.: Web Service Capabilities and Constraints in WSMO, position
paper for W3C Workshop on Constraints and Capabilities for Web Services,
2004, available at http://www.w3.org/2004/08/ws-cc/wsmo-20040903
[DublinCore] S. Weibel, J.
Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for
Resource Discovery, September 1998, available at http://www.isi.edu/in-notes/rfc2413.txt.
[FOAF] D. Brickley, L. Miller:
FOAF Vocabulary Specification, available at http://xmlns.com/foaf/0.1/
[Foster and Kesselman,
1999] I. Foster and C. Kesselman: The Grid: Blueprint for a
New Computing Infrastructure, published by Morgan Kaufmann, 1999.
[Polleres & Lara,
2005] A. Polleres, R. Lara (editors): A Conceptual
Comparison between WSMO and OWL-S, WSMO Working Group working draft,
2005, available at http://www.wsmo.org/2004/d4/d4.1/v0.1/.
[SWRL] I. Horrocks, P.F.
Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean: SWRL: A Semantic
Web Rule Language Combining OWL and RuleML, 2004, available at http://www.w3.org/submissions/2004/SUBM-SWRL-20040521/
[UDDI] T. Bellwood (editor): UDDI
Version 2.04 API specification, OASIS standard available at http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm
[UDDIWP] UDDI Technical
White Paper available at http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf
[WSBPEL] Web Services Business
Process Execution Language, specification developed in OASIS WSBPEL
Technical Committee at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[WSCDL] N. Kavantzas, D. Burdett, G.
Ritzinger, T. Fletcher, Y. Lafon (editors): Web Services Choreography
Description Language, W3C Last Call Working Draft available at http://www.w3.org/TR/ws-cdl-10/
[WSDL] R. Chinnici, M. Gudgin, J-J.
Moreau, J. Schlimmer, S. Weerawarana (editors): Web Services Description
Language Part 1: Core Language, W3C Last Call Working Draft available at
http://www.w3.org/TR/wsdl20/
[WSPolicy] J. Schlimmer (editor):
Web Services Policy Framework, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policy.asp
[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/