Executable BPMN via BPEL

In a short burst of discussion about whether BPEL was a viable execution mechanism for BPMN, Keith Swenson provided an excellent example of a valid BPMN expression that could not be expressed directly in BPEL with a follow up in his blog showing that the BPMN could be directly executed using his product.

This was followed up by a spirited exchange between factions with assertions that BPEL could indeed express the business process but no definitive BPEL as far as I can tell. Alex Boisvert acknowledged a bug in the BPEL produced by Intalio Designer v5.2 but unfortunately did not describe the code that should have been produced. [[Update:ActiveVOS provides an answer in its tutorial material ]]

However, the BPMN 1.1 specification provides a couple of items for thinking around this problem.

The use of a new signal element to provide synchronisation behaviour across processes covers exactly the intent of Keith's example.

There may be situations within a Process where the flow is affected by or dependent on the activity that occurs in another
Process. These events or conditions can be referred to as milestones. The process model must be able to identify and react
to the milestone.That is, the continuation of a Process may be triggered by Signal Events, which pass the flow between
processes (see Figure 10.48 reproduced below). The type of Workflow Pattern called a Milestone.

In para 10.2.1.11 Avoiding Illegal Models and Unexpected Behavior of the BPMN specification, the authors touch on the root cause of the issue.

The situation where alternative paths cross the implicit boundary of a group of parallel paths can cause an invalid model.

If there is to be a future for BPMN to BPEL, we need an indication of what transformation needs to be done to otherwise valid BPMN to produce the intended executable.

The use of BPMN signal elements suggests that the bright people at Intalio could replace the doubtful synchronisation with whatever mechanism they are going to employ to implement signal intermediate events (not implemented in v5.2!). That is, implement it as though the BPMN looks like this ...

This then gives us a manual work around until the transformation rules can be codified into the product.

Which raises the question ... does the catch event need to be reached before the throw can be effective? Should I draw the BPMN like this? ...