Marlon Dumas on BPMN-BPEL round-trip engineering

This is a copy of a very interesting answer of Marlon Dumas in the Workflow Research Forums:

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:
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:
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:…ocess-modeling/


About Panos

My name is Panos Kokkinidis and I am R&D Manager in Relational S.A., Athens, Greece.
This entry was posted in BPMN, Workflow & BPM. Bookmark the permalink.

3 Responses to Marlon Dumas on BPMN-BPEL round-trip engineering

  1. Yi Gao says:

    The fundamental technical challenge in BPMN-BPEL mapping is pattern recognition because BPMN presents a business process in graph, while BPEL is a block structured language overall. The challenge will not disappear with the evolution of both specifications if the structural disparity stays (I believe it is the case).

    Let me explain my point using the same example (figure 1.a in the paper mentioned above). If an analyst describes a business process with a discriminator pattern in word document, and hands it over to you, a BPEL developer, how are you going to implement it? You will say it is not a trivial task based on the current BPEL specification. I agree. In other words, the current BPEL specification does not support this use case well. The question is whether it is a common use case. If this use case is common, the BPEL specification will be enhanced to meet the requirement.

    The algorithm presented in some research papers using pattern matching can only handle simple cases. What we have achieved in eClarus Business Process Modeler is to handle far more complicated cases through our pattern recognition algorithm, static flow token analysis. For example, the following diagram is transformed to a “readable” BPEL flow with synchronization links.

  2. Marlon Dumas says:

    Hi Yi,
    The example that you refer to can be translated using the pattern-matching technique presented in the following paper:
    More generally, acyclic fragments of BPEL process definitions such that each activity is only executed once for each execution of the fragment, can be translated using the technique described in section 4 of the following paper:
    Clearly, we can define sophisticated pattern-matching algorithms that can translate large classes of BPMN models into BPEL process definitions. However, the fundamental problems of BPMN-to-BPEL round-tripping are yet to be resolved, including:
    1) Not every BPMN model can be translated into “readable” BPEL code, especially when the BPMN model contains structures such as the ones I mentioned in the above posting. The fact that such structures do not appear in most “real” scenarios doesn’t mean that the user can not draw such BPMN models (or even worse ones). And what will the round-tripping tool do is the user tries to translate such models? Will it simply crash? Will such BPMN models be forbidden by the tool? And if so, how can we explain to the user which BPMN models can be translated into BPEL and which ones can’t? Or how can we enforce that the user comes up only with BPMN models that the tool can effectively translate into BPEL?
    2) Even if we could translate large classes of BPMN models into BPEL code using pattern-matching, it doesn’t mean that we can round-trip. If you take the resulting BPEL code and try to trivially convert it back into BPMN, you may end up with a very different BPMN model than the original one, especially if the original BPMN model contains unstructured cycles. So same questions as above: How can we explain to the user, in simple terms, which models can be round-tripped and which models can’t? Or how can we enforce in the tool that the user is only able to design BPMN models that can actually be round-tripped? Note that round-tripping is more than just translating: it’s about being able to maintain the source and target models in sync.
    I think more work is needed in this area if we want to realise the vision of BPMN-to-BPEL round-tripping that many tool vendors (including eClarus, Oracle, etc.) are pursuing.
    And even if we had round-tripping, it is unclear that users will actually benefit from it, because BPMN models are usually designed by nusiness analysts whereas BPEL processes are defined by software analysts/developers, and the concerns addressed by these stakeholders are quite different. For a discussion on this issue, see the following post:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s