Keith Swenson revisits the nuisance of BPMN-BPEL roundtripping and casts the obvious solution - executable BPMN - in the guise of WYDIWYE, what-you-see-is-what-you-execute. I pretty much agree with Keith on this, but I have found that even though executable BPMN - as (he says) Fujitsu Interstage provides and (I would add) Lombardi, TIBCO, Appian, and others do as well - is obvously the right answer, it's sometimes not the actual answer in real life. As in... my company has standardized on BPMN for modeling and WebSphere Process Server or Oracle SOA Suite for execution. I have two clients right now who fit this bill exactly.
With one of them I have been going through the exercise of BPMN-BPEL mapping, and it's given me a much better appreciation of the problem. The problem Keith mentions is from a post by William Vambenepe who bemoans the fact that a BPMN OR-split and join in Oracle BPA Suite generates a slightly more complex looking graph in Oracle BPEL, i.e. a parallel split with an enabling XOR gate on each leg. I say to that, hey Bill, suck it up. First of all, it's not all that complex, and second, Oracle is doing the mapping for you automatically. So to imagine that that is the problem is to miss the boat on BPMN-BPEL.
In my experience, the bigger issues are these:
1. "Interleaved" flows. The Pro edition of the BPMN tool we use in our training (ITP Commerce Process Modeler for Visio) lets you switch validation modes between straight BPMN and BPEL generation. That can be an unpleasant experience, when you have a simple diagram that gives no BPMN validation errors, switch on BPEL validation and YIKES! a whole page of "interleaving" errors. The problem has to do with mixing tokens in the flow analysis. I can't explain it, but here's a simple case:
A credit application comes in. If the requested amount is high, it goes to manual approval step. If the amount is low, it goes to a rule engine that assesses risk. If risk is high, it also goes to manual approval. If risk is low, it automatically approves (omitted from the diagram) and ends. Simple, right? Yes in BPMN, but to the BPEL generator this is interleaved. The Risk=High path mixes tokens. Yeah it's all fuzzy math to me, too, but to fix it here's what you have to do:
It's essentially the same, except there's a duplicate of the approval task. Instead of the user task icon it has some other funny icon. That's called a reference task, and it means it's a copy of the original. So it clutters up the diagram but it removes the interleaving error. I wish my tool were smart enough to find and fix these automatically, but it's not.
2. Attached events. In BPMN an attached event (message, timer, or error) aborts the activity and redirects processing down the sequence flow out of the event, called the exception flow. BPMN allows the exception flow to be routed anywhere (as long is it doesn't cross subprocess or pool boundary). But not BPEL. In BPEL, the exception flow (called fault or event handler flow) has to return to the end of the activity with the attached event. Say what? Yeah really.
My tool handles this automatically, and I thought it was quite clever until I saw that the solution is published in the BPMN spec, appendix A. It works like this. BPEL creates a boolean normal completion variable and initializes it to true before the activity with the attached event. In the exception flow (handler) it changes the variable to false. Following the activity there is a switch (equivalent to XOR gateway) that enables the following activity (what BPMN calls Normal Flow) only if the variable is true. This works well as long as there are no parallel paths, no looping back to previous parts of the process, and other things BPMN allows and BPEL has a harder time with. So in many cases you still need to hand code your BPEL, and the need for hand coding is the real problem with roundtripping.
In the BPEL roundtripping debate, there was a lot of hand-wringing about whether you could automatically create "readable" BPEL from BPMN, meaning the kind of BPEL that you would hand code. From my vantage point, the bigger problem is the other direction: Is it possible to recreate the original BPMN from the autogenerated BPEL? Even accepting those nasty Reference activities, can we get back our original OR gateways and exception flows out of attached events? I doubt it. This is why BPEL will, in my view, remain a poor runtime partner for BPMN, at least for BPMN 1.x.
There is a chance the BPEL vendors now driving the BPMN 2.0 bus will force that standard to conform to the constraints of BPEL. But unless and until that happens, a BPMN "engine" remains a much better solution.