BPMS Watch

Roundtripping Update

October 12th, 2006

eClarus today declared they’ve cracked a tough nut in the BPMN-BPEL roundtripping problem. 

If you follow that topic, you probably know that Yi Gao of Seattle startup eClarus and Marlon Dumas of Queensland University of Technology are basically the two guys in the world who know what they’re talking about.  Way back in February, when I was still blogging on Ismael’s site, I posted on the roundtripping problem.  You can find that thread here on BPMS Watch or here at IT|Redux.

In the comment thread, Marlon responded to my post by describing some of his group’s academic work on the question. 

We have recently defined a BPMN-to-BPEL translation that can deal with BPMN graphs with arbitrary topology. In this translation, if the original graph is well-structured, the resulting BPEL code follows the structure of the original graph and everything works well. But if the BPMN graph is not structured, the translation generates rather convoluted BPEL code and the way back to BPMN would be far from easy. For those interested, see this technical report….

There are classes of models for which a reversible BPMN-to-BPEL-and-back translation is possible. We can define three such classes of models:

1) The class of “BPMN models without livelocks”: If a BPMN model (with any topology) is not “divergent”, we can translate it to BPEL using BPEL’s “event handler” feature. You don’t want to read the resulting code though, because it’s just a bunch of event handlers throwing message events at each other. This is pretty much what we show in this paper… where we explain what is meant by a model without livelocks and we give an example of a livelock.

2) The class of “Synchronising BPMN models”: We are currently working on another paper … that contains an algorithm which can determine whether a BPMN model can be translated into BPEL structured activities and control links (without using event handlers, which is what causes the mess). This algorithm could be used for the purpose that you describe: we could allow modellers to write their models as they wish, but on the background we run the algorithm and the algorithm will come back and tell you: Yes, this BPMN model can be translated to “readable BPEL”, or no it can’t.

3) The class of “Structured BPMN models”. Structured BPMN models (where every “splitting” gateway has a corresponding “joining/merging” gateway) can be easily translated into BPEL process definitions containing only BPEL structured activities. An algorithm for determining whether a BPMN process model is structured or not is not difficult to write. Some academic folks from Austria and Denmark have written such an algorithm in another paper written in “runic script”. They do not consider the full spectrum of BPMN constructs, but it could be a point of departure for tool implementors….

For the second and third classes of BPMN models mentioned above, reversible translations are possible, while for the first class of BPMN models, a reversible translation would be very difficult. Note that the first class of models is larger than the second, and the second is larger than the third.

The second class of models is fairly large, and my hunch is that it includes almost any meaningful BPMN diagram that people will be drawing out there. So in summary, there are good hopes that in a not-too-distant future, there will be some reversible BPMN-to-BPEL translations that generate readable BPEL code and cover fairly large classes of models. But there is a bumpy road ahead.

In April, eClarus announced that their tool supported roundtripping for a wide range of models, and provided a link to Yi Gao’s white paper.  At that point they admitted to having more work to do.  Today Yi Gao claims to have solved Marlon’s Class 2:

In the first release of eClarus Process Modeler we have solved the Class 2 practically, even though the translation can be fine tuned.

Class 1 can be solved using simple pattern matching.
With synchronous links, simple pattern match is not enough. We use a flow analysis technique (we call it “Static Flow Token Analysis”) to identify those links. And our tool can translate them to “readable BPEL” if it can be. If you are interested, we can discuss more offline.

Since not too many people are still following a thread dormant since last March, I’m re-posting here in hopes of advancing the discussion.  Marlon has in the past sounded skeptical about eClarus’s approach.  I for one am very interested in what eClarus has done and Marlon’s response.

Entry Filed under: BPM