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  and  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 .) 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
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
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
Here are some of the features that distinguish/differentiate DAML-S from
BPEL4WS. (Again this is incomplete and hastily written.)
- 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.
- 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 , 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
- 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  and WS-Transaction  to
provide a context for pre-defined transactional semantics (see summary of
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 . Any
updates will be placed in the same location.
 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.
[6.5] Concurrent Execution Semantics of DAML-S with Subtypes Anupriya
Ankolekar, Frank Huch, and Katia Sycara LNCS 2342, p. 318 ff.
By Sheila McIlraith and Dan Mandell
Knowledge Systems Lab, Stanford University
Last updated: 9/5/2002