Page 23 -

8 W. van der Aalst et al.
no restrictions on the specification of loops, and loops are allowed to have multiple
entry and/or exit points. A consequence of this is that mapping a BPMN speci-
fication to a corresponding BPEL specification can be a less than trivial matter,
and contemporary support tools typically impose restrictions on BPMN diagrams
for the purpose of subsequent transformation to BPEL. Similar to BPEL, though
slightly better, BPMN does not make much provision for the various ways in which
human participants can be involved in the execution of a business process, and given
that BPMN does not have a formalization accepted by a standards organization, the
interpretation of some of its concepts may vary. Nonetheless, BPMN can be seen as
a move in the direction of more expressive languages, and its continued evolution
and increased adoption makes it likely to have some longevity. In recognition of this,
XPDL has been reinvented and its 2.0 incarnation is an XML serialization of BPMN.
Although not a formal standard, Event-driven Process Chains (EPCs) are a well-
known approach to process specification and the notation has been around for over
15 years. EPCs are supported by the ARIS environment, where they are used for
business process modeling and simulation. EPCs are not directly executable and
they provide a fairly minimal set of control-flow constructs. Extended EPCs aug-
ment EPCs with notations for the involvement of participants and the use of data
elements. EPCs do not have a formal foundation, though one has been defined by
Wil van der Aalst in the late nineties. As he argued that the semantics of the OR
join connector are “not clear” and “subject to multiple interpretations,” this formal-
ization does not incorporate this particular connector. It has since been argued that
there are inherent semantical problems with this concept in the presence of so-called
“vicious circles.”
Another well-known approach to process specification are the Activity Diagrams
of the Unified Modeling Language (UML). In their 1.4 incarnation, these were based
on statecharts, while in their 2.0 incarnation, their semantics was more inspired by
Petri nets. Because of the fact that UML 2.0 activity diagrams do not have a notion
that corresponds to the concept of a place in Petri nets, the link between UML
2.0 activity diagrams and Petri nets is rather complicated. This is relevant because
of two reasons. First of all, certain business scenarios mixing concurrency and
choice cannot be expressed easily. Second, there is no simple and clear semantics.
UML activity diagrams are not intended for direct execution and, although a formal
semantics for them has been defined, no formalization has been officially endorsed
by the Object Management Group (OMG), which is the standardization body behind
UML. Furthermore, it seems that in recent years UML Activity Diagrams have been
eclipsed by BPMN in the context of the specification of business processes.

1.4 The Workflow Patterns Initiative

The concept of workflow has been around for decades and can be traced back to
early work on office automation. Despite its early origins, widespread uptake of
workflow management systems in practice and the integration of this technology