The approach taken in eClarus is promising. However, I am afraid that this approach will break when it gets to BPMN processes where multiple instances of the same activity occur in parallel. Consider for example Figure 1(a) in page 4 of the following paper: http://eprints.qut.edu.au/archive/00002976/01/2976.pdf
You will notice that activity D may execute twice, and these two instances of activity D may occur concurrently (for example if B and C finish more or less at the same time).
Even worst, consider the example in Figure 1(c): the number of instances of D that may be active simultaneously is unbounded.
In the general case, such processes can not be mapped into BPEL structured activities, simply because BPEL structured activities can not generate multiple instances of the same activity. You can still go around a case like the one in Figure 1(a) by duplicating the path containing activity D (and assuming there is no cycle thereafter), but you’ll never manage to capture a case like Figure 1(c).
Up to now, the only way that we have found to map any BPMN diagram to BPEL is by relying on BPEL event handlers. BPEL event handlers have the characteristic that it is the only construct in BPEL 1.1, which allows an unbounded number of instances of the same activity to execute in parallel.
Of course, mapping BPMN models to BPEL defeats the purpose of getting readable models, and round-trip engineering is out of question from there on.
However, if we restrict ourselves to certain subsets of BPMN, some relatively simple algorithms can do the job, see for example: http://eprints.qut.edu.au/archive/00003615/01/3465.pdf
Using such a mapping, round-trip is achievable. This is where tools like eClarus are likely to play a role.
So in summary, don’t expect you can draw any BPMN diagram, hit the button, and get a readable BPEL def. that can then be reverted back to a BPMN model. This can only be (easily) achieved for some classes of BPMN diagrams. There are fundamental differences between BPMN and BPEL, and the mapping is far from trivial.
For some further discussions on this issue, see: http://itredux.com/blog/2006/02/03/the-nex…ocess-modeling/