Re: BPELWS and DAML-S

Hi Monika,

Good question. DAML-S [1] and BPEL4WS [2] are somewhat complementary.  We
are preparing a document that will describe the relationship between the two
in more detail, but here is a somewhat hastily written (less exacting)
answer for now.  If you don't need the "Reviews", skip to the "Comparison"
section.

- Sheila McIlraith and Dan Mandell
Stanford University, Knowledge Systems Lab


Quick Review of DAML-S
=======================
As you know (but for the benefit of other readers) 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-84A9809EC588EF
21

[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] Anupriya Ankolekar, Frank Huch, and Katia Sycara. " Concurrent
Execution Semantics of DAML-S with Subtypes". 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




On 9/2/02 10:42:24 +0100, "Monika Solanki" <monika@dmu.ac.uk> wrote:
> BPEL4WS is the new proposed webservice standard for composition and
> DAML-S is targeted to enable automation in service composition by
> agents. Is it possible to compare the two approaches and are any such
> documnets currently available.
> 
> - Monika

Received on Thursday, 5 September 2002 19:34:56 UTC