Quick Review of DAML-S
DAML-S is a DAML+OIL ontology for describing Web Services. It
represents
part of the
semantic Web initiative to provide semantics to the Web, i.e., to make
Web content unambiguously computer
interpretable. See [3]
and [4] for further
general
discussion on this
topic.
DAML-S aims to make Web
services
computer-interpretable -- described with
sufficient
information to enable
*automated* Web service discovery,
invocation, composition and execution
monitoring.
As
a DAML+OIL ontology, DAML-S has all the benefits of any
Web content
described in DAML+OIL.
It has a well-defined semantics.
It enables the
definition of Web services content vocabulary in
terms of
objects and
complex relationships between them, including
class,
subclass relations,
cardinality restrictions,
etc. (Again see
[4].) It also includes
all the
XML
typing information.
The DAML-S Ontology
comprises:
1.
ServiceProfile - This is like the
yellow page entry for a
service. It relates and
builds upon the type of content
in UDDI,
describing properties of a service
necessary for automatic
discovery, such as what the services offers, and its inputs,
outputs, and its side-effects
(preconditions and
effects)..
2. ServiceModel - Describes the
service's
process model (the control flow
and data-flow involved in
using
the service). It
is designed to
enable
automated composition and execution of services.
This is the place that
relates most closely to BPEL4WS (more on
this
below)
3. ServiceGrounding - Connects the process
model
description to
communcation-level protocols and message
descriptions in
WSDL.
Again, because DAML-S is described
in the DAML+OIL ontology
language, these
components are
annotated with classes of well-defined
types that make the
service descriptions machine-readable and
unambiguous.
Additionally, the
ontological structure of types
allows type definitions
to draw properties
from hierarchical
inheritance and relationships to
other types.
Quick Review of BPEL4WS
BPEL4WS is essentially a process
modeling language. As mentioned above, it
relates
most closely to
the ServiceModel (aka "Process Model")
component of
DAML-S.
It's designed
to enable a would-be service composer to
aggregate one or more Web
services
into a (possibly
non-deterministic) execution of one or more Web
services.
BPEL4WS
distinguishes between abstract and
executable processes. Abstract
process
may cloak internal
behavior (e.g. decision processes) as
non-deterministic
junctions, while executable processes model
the actual
behavior of the
process. Abstract processes are
useful for describing
business protocols,
while executable
processes may be compiled into
invokable
services.
Aggregated
services are modeled as directed
graphs where the nodes are
services and
the edges represent a
dependency link from one service to
another. The
runtime
semantics of the links may be specified in the BPEL4WS
document.
For example, the user may simulate Petri-Net behavior
by
stipulating that
a service may execute only after all its
parents execute
successfully.
Canonical programmatic constructs
like SWITCH, WHILE and PICK
allow
properties of inter-service
messages to direct an execution's path
through
the
graph.
For descriptions of what services do and how they
work,
BPEL4WS references
port types contained in WSDL
documents. Transitively,
then,
the
expressiveness of
service behavior and
inputs/outputs is constrained by XML
and XML schema.
A BPEL4WS
document uses these descriptions to define "roles"
within
a composition that are filled by "partners". A
service that meets the
restrictions set by a partner definition
may fill that role in a
composition.
The port-specific
information about a partner may be set at run
time,
allowing
partner roles to be filled dynamically.
BPEL4WS was
released
along with two others specs: WS-Coordination and
WS-Transaction.
WS-Coordination describes how services
can make use of
pre-defined coordination contexts to subscribe to a
particular
role in a
collaborative activity. WS-Transaction provides a
framework
for
incorporating transactional semantics into
coordinated activities. In
essence, WS-Transaction uses
WS-Coordination to extend BPEL4WS to provide
a
context for
transactional agreements between services. Different
agreements
may be described in an attempt to achieve consistent,
desirable
behavior
while respecting service
autonomy.
Comparison of
DAML-S to BPEL4WS
Clearly DAML-S and
BPEL4WS have broad and somewhat complementary objectives.
DAML-S's
ServiceProfile complements and extends ideas in UDDI.
DAML-S's
ServiceGrounding connects the application level content description of a
service
to communication level descriptions in WSDL. It is the ServiceModel
(aka ProcessModel)
in DAML-S that relates most closely to the business process
model in BPEL4WS.
Both provide a mechanism for describing a business
process model. With so
many candidate formalisms for describing a business
process (e.g., XLANG,
WSFL, BPMI, BPML, now BPEL4WS, etc.) DAML-S was
designed to be agnostic with
respect to a process model formalism. Rather,
it aimed to provide the
vocabulary and agreed upon (necessary) properties
for a process models. In
so
doing, we hoped to remain compatible with what we anticipated would
eventually
be an agreed upon standard for process modeling. If such a
standard did not come to pass, DAML-S would
provide a way of talking about
different process models, in keeping with
the approach and spirit of NIST's
PSL [5].
Here are some of the
features that distinguish/differentiate DAML-S from
BPEL4WS. (Again this is incomplete and hastily
written.)
Expressiveness:
- DAML-S is augmented with
preconditions and effects: This
enables encoding of side effects of services. This is important for WS
composition because it enables higher level reasoning about how services
may be aggragated to achieve
a particular goal while exacting particular
changes on the world.
- hierarchies, taxonomic info:
DAML-S classes may
draw
properties from inheritance and other relationships to other DAML-S
classes, thus providing for a richer
representation of an individual
service and the relationships between services.
- rich
"typing" of Web concepts: DAML+OIL enables us to define classes in
terms of their properties
ranges, and relationships to other classes.
E.g., we
can define a class called US-FAA-flight codes as a subclass of
FAA-flight codes where the location of
the airport designated by the code
is restricted to the USA.
In so doing, we can type content in terms of
these classes and reason and search
over them efficiently. DAML-S also
includes the full suite of
XML data types.
- BPEL4WS uses WSDL port type information for service
descriptions. WSDL
does not
describe side effects, pre or post-conditions of services, and
the expressiveness of service behavior
and inputs/outputs is constrained
by XML and XML schema. WSDL provides an extensibility layer which could
be
used to encode more
information about services.
Semantics:
- Currently intended
interpretation of DAML-S process model defined in 3 ways:
1. By a translation to (axiomatization
in) first-order logic
2. By
a translation to an operational semantics using Petri Nets [6], and
3. By a comparable translation to
subtype polymorphism [6.5],
where 2 and 3 are very similar.
See discussion in [6.5]. Note that the
semantics is defined by a translation because the well-
defined semantics
of DAML+OIL (the language in which the
DAML-S ontology is described) is
not sufficiently expressive to capture the intended interpretation of a
rich process model.
-
Although BPEL4WS represents the merging of XLANG and WSFL -- rooted in
Pi-calculus and Petri Nets,
respectively -- there is currently no evidence
that BPEL4WS is based on a formal semantics.
Automated
discovery, composition, and execution:
- The DAML-S ServiceProfile and
ServiceModel provide sufficient information
to enable automated discovery, composition, and execution
based on
well-defined
descriptions of a service's inputs, outputs, preconditions,
effects, and process model.
-
BPEL4WS does not provide a well-defined semantics. Partners are restricted
by structured XML content
contained in WSDL port type definitions.
Fault handling, execution
monitoring, and transactions:
- BPEL4WS defines a mechanism for catching
and handling faults similar to
common programming languages like Java. One may also define a
compensation
handler to
enable compensatory activities in the event of actions that
cannot be explicitly undone. DAML-S
does not define recovery protocols but
Petri Net translations of DAML-S descriptions may be
extended to support
them.
- Neither BPEL4WS or DAML-S directly support query mechanisms to expose
the
state of executing
processes. BPEL4WS lists this item as a Future
Direction. Petri Net translations of DAML-S descriptions may
be extended
to support
execution monitoring.
- BPEL4WS may be extended with WS-Coordination [7]
and WS-Transaction [8] to
provide a context for pre-defined transactional semantics (see summary
of
BPEL4WS, above).
The
above is a sketch of the distinctions between BPEL4WS and DAML-S. As
noted
above we are preparing a document to more thoroughly examine the
distinctions
of the two specifications. This
document appears in [9]. Any
updates will be placed in the same
location.
[1]http://www.daml.org/services/
[2]
http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
[3]
http://www.sciam.com/article.cfm?articleID=00048144-10D2-1C70-84A9809EC588EF21
[4] http://www.daml.org/2001/03/daml+oil-index
[5] http://ats.nist.gov/psl/
[6] Narayanan, S. and McIlraith, S.
``Simulation, Verification and Automated
Composition of Web Services''. To
appear in the Proceedings of the Eleventh
International World Wide Web
Conference (WWW-11), May, 2002.
http://www.daml.org/services/nar-mci-www11.ps
[6.5]
Concurrent Execution Semantics of DAML-S with Subtypes Anupriya
Ankolekar,
Frank Huch, and Katia Sycara LNCS 2342, p. 318 ff.
http://www.daml.org/services/ISWC2002-ExSem.pdf
[7]
http://www-106.ibm.com/developerworks/webservices/library/ws-coor/
[8]
http://www-106.ibm.com/developerworks/webservices/library/ws-transpec/
[9]
http://www.ksl.stanford.edu/projects/DAML/Webservices/DAMLS-BPEL.html
By Sheila McIlraith and Dan Mandell
Knowledge Systems Lab, Stanford University
{sheilam|dmandell}@stanford.edu
Last updated: 9/5/2002