I should have known that disputing Michael Rowley's contention that mapping BPMN to BPEL was "simpler" than a straight BPMN 2.0 solution would invite a further response. Two, actually, one from Michael and another from Frank Leymann. Hmmm. In a room with those two, I'm at best the third smartest guy. But unlike the "stacker-bashing" flame wars of 2008, their points are well stated and sort of illuminating. Anyway I can't resist taking another shot.
I tried to let Michael off the hook the first time by suggesting maybe he meant a hybrid BPMN-BPEL solution was simpler for engine vendors. But no, he says he means simpler for process modelers! OK, I'm thinking of three products: Oracle's BPA Suite (BPMN) mapped to BPEL Designer through their Blueprint intermediary notation. No way that's simpler. I think Oracle would be the first to admit it, and Oracle BPM 11gR1 will put the nail in that one. How about IBM's WebSphere Modeler's quasi-BPMN mode with "direct deploy", i.e. avoiding a stop in WID's BPEL editor? Closer to "simple" I guess, but the direct deploy is just to a test environment that outputs design bugs to be fixed in WID. I can hear the stacker-bashing competitors snickering from here: that's simple? OK how about Michael's own ActiveVOS? I just saw a beta demo a couple months back -- maybe it's changed -- but that was a BPMN 2.0 diagram with the node names changed to BPEL. Now why would you want to do that? His argument would have a lot more power if he just kept the BPMN names and hid the BPEL execution language under the covers. You only keep the BPEL nomenclature if the diagram is secondary to the XML, the BPEL language. So I guess he means this is "simpler" to BPEL developers, not mainstream process modelers. OK, I'll concede that point.
Both Michael and Frank take me to task for saying that BPEL is block oriented while BPMN is graph oriented. Yes we know BPEL does support the flow/link construct in addition to the more frequently used sequence block construct, but it still has those restrictions - no freeform loopbacks, no "interleaving." Try explaining what interleaved topologies means to a typical BPMN modeler. He presents a BPMN diagram that would probably give interleaving errors in my BPMN tool if I tried to export to BPEL, but it works in ActiveVOS because they use eClarus's more-intelligent-than-the-others' BPEL mapping algorithms. But even there Michael admits that some diagrams still require a workaround. Again, I think it fails the "simplicity" test.
Frank Leymann's post is more interesting, I think. Frank was one of IBM's original BPM gurus. He jumps in to defend BPEL as today's BPM runtime standard, says I'm flat wrong to deny that. I guess among all the BPM runtime standards BPEL is the most widely adopted, I'll agree with that. But among all BPMS platforms? BPEL is the runtime of just a few. Most BPMSs today have proprietary runtimes. That's a plain fact.
But here is where Frank gets to the heart of the BPMN-BPEL issue:
We are faced with the following problem: How can we bridge the gap between BPEL (an execution language with rigor operational semantics) and BPMN (a visual language with informal semantics).... One possible way to solve this problem is to standardize a visual representation for BPEL... But the problem is that BPMN contains quite a number of constructs that... have no direct correspondence in BPEL. Thus, BPEL extensions would be needed to support [them]... but extending BPEL is time consuming (see the recent BPEL4People extensions) while BPMN users want to see a solution ?soon?.
The other way to solve the problem ? the way that has been taken ? is to move BPMN forward... to make transforming BPMN process models to BPEL much easier. The fundamental enhancements of BPMN 2.0 [now] enable this....
From a BPEL perspective the current situation is as follows: A subset of BPMN 2.0 is ?isomorphic? to BPEL. As a consequence, BPMN 2.0 encompasses a visual modeling language for BPEL ? this subset can be naturally transformed to BPEL and executed in a BPEL engine. From an architectural point of view, a tool supporting this BPMN subset is a layer on top of BPEL engines.... From a BPMN 2.0 perspective,... BPMN 2.0 is a process modeling language with an operational semantics [influenced] by BPEL... Thus, it is now possible to build an engine that directly supports BPMN 2.0 ? without the intermediate step of generating BPEL. What he fails to explain is that the subset of BPMN that is isomorphic to BPEL is not a subset of BPMN elements or shapes in the diagram palette. It's a subset of BPMN diagram topologies. We're back to that same problem of explaining interleaved loops to a business process analyst. A tool that prevents modelers from drawing the problem patterns is probably going to enforce some kind of block structure, like the BPEL drawing tools do today. Alternatively, they can let the modeler have at it and then give the BPEL validation errors at the end.
The answer is just so obvious to me... and I think to Frank as well. He even says it right there: "It is possible to build an engine that directly supports BPMN 2.0 without the intermediate step of generating BPEL." Duh. Oracle and IBM, two of the biggest BPEL vendors, essentially designed BPMN 2.0 with that specific intention. I'll grant the obvious: Neither Oracle BPM 11g or IBM BPM v7 are shipping yet. But when they are, it's hard to see BPEL as the simpler path forward.