Once again, I think you’re absolutely on the right track. Class 1 is probably of little practical interest for process designers who want to import into a BPEL design tool. Solving Class 2 would be a giant step forward. Please keep us posted on your progress.

I am not surprised. I have never been a big fan of MDA…

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.

I am sorry for the “runic script” used in the technical report describing the BPMN-to-BPEL translation. This is a notation used by computer science academics, which is our initial target audience, as we want to get feedback regarding the correctness of the translation. But in the interest of bridging academia with industry, we are working on implementing the proposed translation as an open-source tool, so that tool vendors or open-source projects can pick things from there. You’re right about the lack of a standard XML serialisation of BPMN and your XPDL suggestion is a very good one. We have already started the work using an XML serialisation of the ILOG’s BPMN serialisation for which the documentation (in latin script) is publicly available. You will be right to say that this is a proprietary notation, but I can bet my dearest fifty cents that the final XML serialisation of BPMN, whether based on MOF/XMI or not, will be “isomorphic” to ILOG’s BPMN serialisation (and to other serialisations available out there). So it will be possible to define simple transformations between the standard and the “proprietary” serialisations. After all, they will hopefully be just two serialisations of the same language. The real problem is the BPMN-to-BPEL part.

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 (also in “runic script”) 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 in runic script 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.

There are some “small” glitches though when translating BPMN to BPEL: they have to do with the fact that BPMN has a notion of sub-process and BPEL does not, but this is not difficult to circunvent and it is discussed in the BPMN specification. Also, BPMN distinguishes a lot of types of events, while BPEL doesn’t, so some nuances in the BPMN model may be lost on the way down to BPEL. But we can say that these are details and they can probably be resolved.

I was previously unaware of your academic work on this topic but I think it is absolutely crucial and want to encourage you in it. I went to the paper you cite in your post, and despite the fact that it is largely written in some form of indecipherable runic script, the gist of it seems that you have discovered an iterative algorithm for turning BPMN into “readable” BPEL by analyzing basic patterns, with the caveat that there are some non-standard patterns that perhaps don’t work. The current version of your tool does not work with BPMN — alas it has no schema — but a simple XML-based list of activities and connectors. Since we mortals live in a world of tools, I might suggest as an alternative something like XPDL 2.0, which some BPMN tools can create and which provide the information your algorithm needs.

I am also interested in a class of tools, such as I imagine the Intalio BPMN Designer to be when it is finally released, where BPMN is a real-time graphical facade for BPEL code, such that if it violates BPEL it probably can’t be drawn. You might say that’s a much easier problem since it excludes lots of possible BPMN topologies, but to me it is the only one of interest since if you can’t execute it, what’s the point? Do you think for such a class of models, the reverse translation problem is significantly easier, or not?

Frankly, the problem I experienced is that behind the BPMN graphical elements, I cannot still find the correct XML document. Having tested some tools and trying to export and import the XML files, I encountered the crap files and not really the document that I can use. What about the interoperability promised by the OMG’s MDA?

The first question is one of methodology, and is more general to the whole MDA approach (not just BPMN-to-BPEL). High-level models need to be properly synchronized with lower-level views, and unless you have one-to-one mappings (which would be surprising), this is not easy to support. Two-way translations that perfectly preserve the structure of the higher-level model (in this case BPMN) are just one element of the solution. But even with tools implementing such translations, stakeholders would need to follow strict guidelines to ensure that they do not break what has been done at a higher level (BPMN) when they do modifications at the lower level (BPEL), and vice-versa. I think it will take a lot of time to get there since it entails getting people used to work in certain ways (not just technological issues, but methodological ones).

The second problem is probably solvable, but not as easy as it seems. If we restrict the structure of BPMN processes to e.g. structured ones, it is not hard to define translations that preserve the structure, so that a reverse translation that renders the original BPMN process is possible. If we lift these restrictions, things become more complex due to fundamental differences, as Tomasz points out. 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.

An implementation of an earlier version of this translation is also available at the BABEL tools page (it’s called SPM2BPEL). An improved version of the implementation incorporating the whole translation described in the technical report is underway and should be posted on the same page soon.