Disclaimer: the views expressed in this analysis represents the views of the authors and not necessarily the one of his employer.
Release notes
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 comment
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.
General Remarks
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.
Control Flow
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.
Data flow
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:
<DataField Id="abcPO" Name="abcPurchaseOrder" IsArray="False">
<DataType>
<ExternalReference xref="PO" location="http://abc.com/services/poService.wsdl"
namespace="poService/definitions/types"/>
</DataType>
</DataField>
<Application Id="placeOrder">
<ExternalReference location="http://abc.com/PO/services/poService.wsdl" xref="PlaceOrder"
namespace= "http://abc.com/services/poService.wsdl/definitions/portType"/> </Application>
However, XPDL does not have complete data flow capabilities like the containers of BPEL4WS which can be mapped to one another and decomposed in "parts".
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 given schema.
Transaction flow
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 demarcation.
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 organizational structure.
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.
Simulation
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.
Conclusion
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 processes only.
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.
