Rough Draft

A Comparison of XPDL, BPML and BPEL4WS

Cape Visions 

Robert Shapiro

1                   Introduction

The Business Process Modeling Language (BPML) is representative of a new family of process definition languages intended for expressing abstract and executable processes that address all aspects of enterprise business processes, including in particular those areas important for web-based services. Microsoft’s XLANG is another member of this family, as is IBM’s Web Services Flow Language (WSFL). These latter two have now been combined in BPEL4WS.

In this paper we focus on a comparison of BPML with XPDL, the WfMC proposed standard for an XML-based process definition interchange language. Comments (in red) have been added to extend the comparison to BPEL4WS, hereafter abbreviated to BPEL.

Section 2.11.4 (Activity Details) contains brief descriptions included for the benefit of readers unfamiliar with BPML.

1.1             Objectives

Our primary objective is to clarify the differences between the BPML and XPDL (and BPEL) paradigms. We are interested in exposing what can be done with one language and cannot be done, or done only with difficulty in the other. When simple extensions are possible, we propose them.

We are also concerned about the work being done by the three standards organizations:

·         WfMC

·         OMG

·         BPMI

This effort intends to create a common modeling notation (BPMN). The comparison of BPML and XPDL should expose some of the challenges in this undertaking.

As of August, 2002, BPMN remains a BPMI activity: no significant cooperation has developed between the three organizations

In addition to BPML, on 26 June 2002, BEA Systems, Intalio, SAP and Sun announced the publication of the XML-based WSCI, a specification that:

·         Defines the behavior of Web service interfaces

·         Forms part of the ongoing Web service process flow composition efforts (often referred to as orchestration, choreography or workflow)

Incorporating many aspects of BPML, WSCI focuses on the choreography of web services. We do not explore this topic further in this paper.

There are at least three other important projects that address Business Process Management System (BPMS) issues in a Web Services context:

·         ebXML(OASIS/UN)

·         WSFL (IBM)

·         XLang (MS)

In August 2002 Microsoft/IBM released a new specification, BPEL4WS, which combines XLANG and WSFL.

It is our intent to include a discussion of functionality contained in any of these which should be part of a business process definition language, BPMN or supported by BPM simulation technology.

5/19/2001 9:14              Page 15 of 17              A Comparison of XPDL and BPML_BPEL.doc

2                   BPML/XPDL Comparison

2.1             Overview

BPML and XPDL (and BPEL) are XML-based process definition languages. They provide a formal model for expressing executable processes that addresses all aspects of enterprise business processes. They are based on significantly different paradigms.

Each paradigm utilizes activities as the basic components of process definition. In each, activities are always part of some particular process. Each has instance-relevant data, property for BPML and workflow-relevant data (data fields) for XPDL (and Containers for BPEL), which can be referred to in routing logic and expressions.

BPML is conceived of as a block-structured programming language. Recursive block structure plays a significant role in scoping issues that are relevant for declarations, definitions and process execution. Flow control (routing) is handled entirely by block structure concepts (e.g. execute all the activities in the block sequentially).

XPDL is conceived of as a graph-structured language with additional concepts to handle blocks. Scoping issues are relevant at the package and process levels. Process definitions cannot be nested. Routing is handled by specification of transitions between activities. The activities in a process can be thought of as the nodes of a directed graph, with the transitions being the edges. Conditions associated with the transitions determine at execution time which activity or activities should be executed next

BPEL is a block-structured programming language, allowing recursive blocks but restricting definitions and declarations to the top level. Within a block graph-structured flow concepts are supported to a limited extent, constrained by inheritance from previous generation workflow software (only acyclic graphs, hence no loops; some constraints on going across block boundaries; a complicated semantics for determining whether an activity actually happens).

BPML focuses on issues important in defining web services. This is reflected in several ways:

·         Activity types specifically for message interchange, event handling, compensation (in case of failure), delay.

·         Attributes to support instance correlation, extraction of parts of messages, locating service instances.

·         Support for transactions, utilizing the block structure context, exception handling and compensation.

XPDL focuses on issues relevant to the distribution of work.

·         Activity attribute specifies the resource(s) required to perform an activity. This is an expression, evaluated at execution time, which determines the resource required.

·         Activity attribute specifies the application(s) required to implement an activity.

·         These concepts together support the notion of a resource (e.g. participant), in conjunction with an application, performing the activity. The implementation of work list handlers to achieve this lies outside the domain of the process definitions.

BPEL focuses on issues important in defining web services and does this in a way which is quite similar to BPML.

2.2             Block Structured versus Directed Graph

It is not the purpose of this paper to argue the merits of these two approaches. We make two points in this regard.

·         Block structures work well in programming languages.

·         Business operations people are used to flow diagrams and other graphical notations.

It seems likely that business users of BPML and XPDL would prefer to use a GUI based, at least in part, on diagrams. We are concerned here with questions about what can be represented in one language and not the other.

Translation of blocked-structured flow control (routing) into a graph structure presents no fundamental difficulties. The reverse is more problematic. This can be facilitated by imposing a set of restrictions on the graph structure that guarantee it to be ‘well-structured’. It is likely that Business Process Management Systems that use BPML will support some type of graphical tool for process definition that imposes such restrictions. It remains to be seen whether such restrictions limit the usability of BPML. We do not pursue this topic in this paper.

BPEL attempts to offer the best of both approaches by introducing a flow construct and using links to create ‘arbitrary’ flow dependencies between the activities contained within the flow construct. However, there are constraints which rule out loops and crossing certain structural boundaries; additionally the semantics relies on a complicated formulation which tests and propagates the status of links. It is possible that a graphical front end could simplify this and be more user-friendly to the business analyst.

2.3             Definitions and Recursive Block Structure

BPML makes extensive use of block structure scoping related to definitions and declarations. Complex activities refer to activity sets which have an associated context. In the context it is possible to declare or re-declare properties, define or re-define processes (nested processes) and so forth. (Many other features are scoped by the context in which they appear, including error handling, transactions and connectors (for message handling).   Since a complex activity can appear in an activity set, this nesting is recursive.

XPDL only allows process definitions on the top level. Hence there are no nested processes. Since workflow relevant data is declared either on the top level, or within a process definition, it is limited to 2 scope levels. We make no assessment here as to whether nested process definitions are an important feature. BPEL does not support nested process definition. Furthermore, the equivalent of workflow relevant data, containers, are global in scope. (The current spec also fails to make clear whether (or how) containers are instance-specific).

In what follows we make use of two new constructs included in XPDL 1.0 beta, blockactivity and activityset. The block activity is then like the complex activities in BPML, with attributes for designating the type of complex activity and other information appropriate to defining a context for an activity set. Including data field declarations in the context would allow the same scoping possibilities as BPML. To implement nested processes, process definitions would also have to be included.

Most of the features associated with BPML complex activities could be represented in XPDL by the block activity. This construct refers by name to a set of activities that have no transitions outside the set. The construction process for the BPML all activity, for instance, would simply introduce a first and last activity within the activity set, where the first activity is an andsplit and the last activity is an andjoin. There would be a transition from the first activity to each of the activities within the block and a transition from each activity to the last activity. Other types of complex activities could be represented by transitions that implement the appropriate control logic. In the sequel we suggest an alternate approach which makes the translation from BPML to XPDL easier, but passes some of the burden onto the workflow or simulation engine that executes the XML definitions. In so doing we are not making a recommendation to change XPDL.

(The August 2002 WfMC XPDL 1.0 beta has included a version of BlockActivity and ActivitySet that can by trivially extended to implement complex activities.)

2.4             Specialized ...