An interesting bit on the WfMC site comparing XPDL and BPEL that was highlighted in a WfMC mailing this week:
BPEL and XPDL are entirely different yet complimentary standards. BPEL is an “execution language” designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-a-vis application integration. The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to “run” the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is not an executable programming language like BPEL, but specifically a process design format that literally represents the “drawing” of the process definition. To wit, it has ‘XY’ or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPMN process diagram. For this reason, XPDL is effectively the file format or “serialization” of BPMN, as well as any non-BPMN design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)
A good distinction between the best uses of BPEL and XPDL, except for one point: very few vendors are using BPEL as an execution language; they’re using it as an interchange format, which is causing a lot of confusion about what format to use (XPDL or BPEL) to move process maps between a modelling and execution environment. As the above paragraph points out, XPDL maintains the graphical drawing information as well as the execution-specific information; it also supports everything that can be modelled in BPMN (which BPEL currently can’t).
There’s also an article by Jon Pyke of WfMC in Computer Business Review Online where he smacks them down for calling XPDL a failure in a previous article, and states that XPDL is “often incorrectly perceived to be competitive with the business process execution language, BPEL, standard”. XPDL and BPEL aren’t competing in the sense that someone would elect to use one over the other, but they are competitive in that they’re both used as interchange formats, just for different types of processes or in different tools. Unless your BPM engine actually uses BPEL as an execution language (which few do), you’re not going to go from BPMN to XPDL to BPEL and then on to your BPM engine’s proprietary execution language, because there’s no value added from an additional data transformation: you’d do BPMN=>BPEL=>[BPM engine execution language] (obviously skipping the last transformation if the native execution language is BPEL) for web services orchestration-type processes that can be described completely using BPEL, or you’d use BPMN=>XPDL=>[BPM engine execution language] (where the latter may or may not be BPEL) for the larger set of functions supported by XPDL, like human-facing steps. In many cases, the choice of XPDL or BPEL is dictated by what’s supported by the tools that you use for processes modelling; those tools intended to model processes of web services orchestrations are more likely to support BPEL, whereas those targetted at the “BPM suites” market are more likely to use XPDL.