Active Endpoints' Alex Neihaus points me to a post by his CTO Michael Rowley entitled "Which is simpler: BPMN or BPEL?" I'm groaning before I even read it, because I know where Michael is headed. Right off a cliff, in my view.
Their product ActiveVOS is one of the first to support BPMN 2.0 diagrams, but they use it to create BPEL. Such a use was actually anticipated by the developers of BPMN 2.0 - IBM, Oracle, and SAP - all of which have been shipping BPEL engines for some time. So that's not such a big deal, and Michael doesn't really need to defend doing it. Saying it's a "simpler" way to go than executable BPMN 2.0, however, is a stretch.
Simpler for whom? When you sort it all out, he's actually saying BPEL is simpler for an engine vendor because it doesn't have overlapping or alternative constructs like BPMN does. No one would argue with that, but who cares? No engine vendor is going to support every possible BPMN 2.0 element and attribute called out in the metamodel. And I'm not saying just in the first release. Not ever. In that sense, BPMN 2.0 is not a self-contained execution language like BPEL is.
However, for process modelers, and even for executable process designers, there's no way BPEL execution makes BPMN modeling "simpler." That's because the subset of BPMN supported with BPEL execution excludes the very features that make BPMN attractive to business-oriented modelers in the first place: things like freeform looping back to a previous step in the flow. BPEL is inherently block oriented, like a computer program, while BPMN is inherently graph oriented, like a flowchart.
In the BPEL mapping section of BPMN 2.0, the spec describes "basic mapping" of block-oriented BPMN. Then follows a section on "extended mapping" where the BPMN does not conform to BPEL's natural block structure. The spec essentially says here engine vendors are on their own, noting "in many cases there is no preferred single mapping of a particular block, but rather, multiple WS-BPEL patterns are possible to map that block to."
Freeform loopbacks are a prime example. They typically describe what BPEL calls "interleaved loop" structures. To map these to BPEL, the BPMN spec says the following:
The looping section of the Process, where the loops first merge back (upstream) into the flow until all paths have merged back to Normal Flow, shall be separated from the main WSBPEL process into a set of derived processes that will spawn each other until all the looping conditions are satisfied.The section of the process that is removed will be replaced by a (one-way) invoke to spawn the process, followed by a receive to accept the message that the looping sections have completed and the main process can continue.In other words, just to support freeform routing in the diagram, a single BPMN process must be split into multiple BPEL processes that signal to each other through messages. Is this simpler? No I don't think so.
Over the past year, engineers at Oracle and IBM have been making changes to their process engines precisely to break out of the BPEL box, not just to better handle BPMN constructs like OR gateways, boundary events, and sequence flow loopbacks, but ad-hoc behavior as well. If BPEL were adequate to execute processes the way business wants to model them, it would have become the BPM runtime standard. It hasn't.