Disclaimer: the views expressed in this analysis represents the views
of the authors and not necessarily the one of his employer.
v1.0.0 11/15/02 First version
I review XPDL in the perspective of a full-fledge business
process definition language. Its authors may have had other intents, e.g. use it
as an interchange format between modeling tools or tools and engines, ...
Nevertheless, most people will try to see if XPDL can be used to model their own
processes rather than try to exchange them. This is my answer to them.
v1.0.1 12/2/02 Added this
Note that it was never the intend of the WfMC to address
requirements around B2B or EAI thought some of the constructs could be mapped to
specific technologies in these fields. Instead, the WfMC has always focused on a
special class of business process which mostly involved users and applications.
This class of process is often called workflow.
XPDL is the last but not least of the 2002 Business Process Definition Markup
Language vintage. However, unlike the Beaujolais, it is not "nouveau":
it is probably one with the oldest roots based on its WfMC heritage. One could
also argue that WSFL and hence BPEL4WS has very old roots via Prof. Roller and
Leymann which have been working on this subject for well over a decade.
I pointed many times that in the past 4 years (at least), B2B integration has
opened up the need and hopefully a market for business process engines, provided
that they are capable of dealing with the semantics of doing business. After
all, we are all talking about business process engines and not web
service ballets. So in the old tradition of the WfMC B2B semantics are missing
in action. However, some effort has been done to map modern technologies (XML
and Web Services) to the old metamodel, but don't look for the notions of
collaboration, public/private processes, partners, transaction, compensation,
transformation, even exceptions ... they are not there!
So let's take a closer look at the XPDL metamodel. Unlike other standards I
won't provide UML diagrams to illustrate the metamodel as they are nicely
provided with the specification.
A Workflow Process Definition is composed of Workflow Process Activities .
Activities are related together to form a control flow via transitions which can
be guarded by a transition. An activity can act as a join when it is the
target of multiple transitions.
It is pretty clear now that a "transition-only" control flow is not
an asset because it does not have explicit construct like (BPEL4WS) flow, while,
or switch, but also fault handlers and compensation handlers. The concept of an
Activity block has been introduced to map more easily to block-structured
languages like BPML or BPEL4WS, but in my opinion it is not enough. I think the
concept of conformance classes is also new. This concept restricts some aspects
of the net of activity-transitions (non-blocked, loop-blocked, full-blocked).
See the problem of transition-based languages is that they allow you too much
freedom like the GOTO in basic, and enhance, after a while your process starts
looking like your spaghetti plate.
"An activity represents a [unit
of work], which will be processed by a combination of resource (specified by
participant assignment) and/or computer applications (specified by application
assignment)." There are two types of activities: manual and automatic.
Because of its heritage, XPDL is the only standard which consider explicit user
interactions as part of a business process definition. This is unfortunate
that BPEL4WS and BPML does not think that user interactions are part of common
business processes. An automatic activity typically invoke an application
component. The concepts of automatic activity and application definitions is not
enough to model a real message flow (like the receive, invoke, reply and pick of
BPEL4WS) along with control flow or data flow for instance. Basically all
automatic activities are of the type "invoke" or "receive"
Unlike BPEL4WS, XPDL supports the concept of "subflow".
"In- and out-parameters permit the exchange of any
necessary workflow relevant data between calling and called process (and, where
necessary, on return)." This is again typical WfMC 1995. Nothing has
been done to extend the model for instance and establish a true collaboration
between the subflow and its parent flow. I say this, because the typical
argument of the WfMC with respect to B2B is: "initiate a subflow via the
interoperability interface, and you get B2B for free". Clearly this is
completely fallacious and shows a total misunderstanding of B2B requirements.
B2B processes collaborate in a peer-to-peer fashion, the WfMC nested and chained
model are by far insufficient.
The concept of process variables (Data field) and
Application definition can be mapped respectively to XML and Web Services. Here
is an example from the specification:
Id="abcPO" Name="abcPurchaseOrder" IsArray="False">
However, XPDL does not have complete data flow capabilities
like the containers of BPEL4WS which can be mapped to one another and decomposed
XML schema can be used in two ways, a) specify the type of
a data field, or b) a constraint on a string field which must conform to the
There is no transaction or exception semantics in XPDL. A
transition can be marked by an Exception element, to indicate that we are taking
a path because an exception happened. However, this is just an annotation. There
is no notion of fault handler, or compensation handler or transaction
Performers and participants
The WfMC, because of its traditional focus on manual activities,
and document management, had to have the concept of an activity performer. This
is a very good concept, which enables us to specify static or dynamic performers
which are identified at run-time via an organizational structure and specific
business rules (e.g. role). This concept it totally missing in the case of BPML
and only present in the message flow of BPEL4WS (only as "partner").
In addition BPEL4WS cannot express business rules which utilize an
A participant is one of the following types: "resource
set, resource, organizational unit, role, human, or system."
Unfortunately, it looks like business partners and B2B have been relegated for a
subsequent version of XPDL.
This is another interesting concept raised by the WfMC. When
process definitions becomes complex, a simulation is often needed to verify the
correct behavior of the process. XPDL offers specific simulation elements which
will fill certain values when a simulation is run with this process definition.
So in conclusion, it is clear that the WfMC has no understanding of modern
architectures which require users, systems, and partners to collaborate across
long running business processes. This is where the value of
business process engines lies at the convergence of enterprise systems,
traditional workflow (as defined by the WfMC), EAI and B2B. XPDL is focused on Workflow
I know already the comments that some of the authors or WfMC members (like
BPML) will respond to this analysis..."but you don't understand, XPDL is a
low level language which can be used to model higher level business
language". For instance, I am convinced that I could find a combination of
constructs that allow me to map to the concept of BPEL4WS:FaultHandler. By all
means, I don't need a generic language in which I can invent a new language that
I can finally use to express my business processes. The only thing I want is a
business process definition language, XPDL is not one of them.
At this point, I remain convinced that BPEL4WS will have enough momentum to
progress to the level of a full fledged business process engine after several
iterations driven by market demands, in the pure Microsoft tradition.