I just want to highlight an excellent post by William Vambenepe on the subject of BPMN to BPEL: going to battle with one hand tied? He does a very simple experiment: draw a meaningful diagram in BPMN, in this case a fairly simple one involving an Inclusive-OR branch, and then attempt to convert this to BPEL. He does this conversion and presents the results is quite obviously a diagram that fails in fact to capture the exact meaning. He says he has no solution to this problem.
William, I have your answer, but it is kind of cheating: “WYDIWYE” The solution is to NOT convert to BPEL at all. Why can’t the engine take the BPMN diagram directly? Why does it have to be converted at all?
Think about it: if you can draw a diagram that is unambiguous and the rules are clear, why not simply transfer that entire diagram to the engine, and let the engine execute it exactly? A conversion always involves loss of information, or at best, retaining the same information, and the problems of “round-tripping” conversions are widely discussed. What would be the advantage in converting the diagram to BPEL?
Internally, the engine can convert to anything it wants. If it is internally a BPEL engine, then it can convert to its own brand of BPEL. If it is Ruby based, it can convert to Ruby. As users, why should we care what it converts to for execution?
There are a number of engines that interpret the diagram directly without needing translation. WYDIWYE: What You Draw Is What You Execute. This is exactly what Interstage BPM does, but Fujitsu is not the only BPM vendor out there that does this. (Others can chime in, please.) I often get asked: “do you convert this diagram to BPEL?” My response is “Why should we want to do that?” We send the entire diagram, unconverted, to the engine, where it is executed directly. There is no benefit I can see to stripping the process down to the executable part for giving it to an engine.
There are several clear advantages of WYDIWYE:
- The additional non-executable information (graphics, etc) as useful in order to display the running process to a user.
- If you offer on-the-fly modification, then you have the entire process to start modifying. Not possible if you have only a BPEL extraction.
- If it fails to execute the BPMN diagram that I drew, then the engine can explain to me on that diagram what is wrong. It is difficult to communicate problems back to the user if the form is changed from the original.
- You can always convert it later to BPEL if you wish, given that you have the complete diagram.
Seriously: what do you gain by converting to BPEL before giving it to the engine? BPEL strips out non-executable aspects of the BPMN diagram. Even those that claim all is preserved do not deny that often the form is changed to be unrecognizable. Also, consider that the Diagram is the Meaning in many cases.
WYDIWYE: What You Draw Is What You Execute. Why does the diagram have to be stripped down to the executable part before giving it to the engine?
Thinking Matters 
Hello Keith,
sorry for asking, I’m sure a bit of googling around the Fujitsu website would yield the answer, but well, what is the underlying format of the BPMN diagram that is executed by the Fujitsu engine ? I would imagine it’s XPDL…
I have to say I quite like the idea of focusing on the diagram (or just ‘the process definition’) and not on what the engine actually executes.
In plain programming, we don’t use decompilers very often…
John
Well, it is a very well known fact that you can’t transform any BPMN to BPEL, because both languages have a different degree of expressiveness. A common approach is to only use a limited subset of BPMN so that it can be transformed to BPEL (or any other execution language).
Of course you can directly execute BPMN, but this is at the current point no portable solution. So there is no way to ensure that Fujitsu is executing the BPMN diagram in the same way as e.g. Intalio would do. BPMN just has no clear execution semantics, or at least the execution semantics are not standardised. Here, BPEL has the clear advantage that all engines show (at least in theory) the same behaviour.
So just relying on BPMN is good as long as you don’t need a portable model which is executed in the same way on different engines.
John,
Yes, Fujitsu uses XPDL as the file format to store the BPMN diagram. Most of you know I am a strong proponent of XPDL, but the point of this post is not simply another argument for XPDL. The point I am trying to make here is that ANY format that persists the BPMN diagram one-for-one will be superior to something that purposefully strips the process down to the executable subset. I am arguing that it is clearly superior to send the complete diagram to the engine, and then the engine can do whatever conversion (compiling as you say) it needs internally.
-Keith
Pingback: BPMS Watch » More on BPMN-to-BPEL
Sebastian, thanks for the post, you bring up an important topic: the question of portability.
Clearly the holy grail is a portable language that executes on all platforms in the same way. As you point out, BPMN does not completely define the semantics in all cases (e.g. the inclusive-OR node). Also BPEL is only portable in theory. Neither will satisfy the “write-once run-anywhere” requirement of true portability.
Still, I think that translating from one not-perfectly-portable language to another not-perfectly-portable language does not improve anything. While BPMN is not perfect, it is better to leave it in that form. Bruce Silver has argued convincingly that BPMN is still the most portable universal language for BPM around.
One thing is clear however: BPEL can never be more portable than BPMN. Because the BPMN is translated to BPEL, everything that is part of the BPEL must necessarily have been part of the BPMN, and this means that the BPMN is always as least as portable as the language it translates into. Given a set of engines with exactly the same execution semantics, then you could transfer the BPMN around, and it would execute exactly the same on each machine. It may be helpful to consider the analogy of 3GL (like C++) which compiles to machine code; the C++ is always at least as portable as the machine code. If all your machines execute the same machine code, then they all will execute the same C++ as well.
While my post was not really about portability, I still see no inherent benefit of translating to BPEL.
Keith said:
> One thing is clear however: BPEL can never be more
> portable than BPMN. Because the BPMN is translated
> to BPEL, everything that is part of the BPEL must
> necessarily have been part of the BPMN, and this
> means that the BPMN is always as least as portable
> as the language it translates into.
Well, this statement is not completely true. At the current point, BPMN is not portable at all, because it has no defined and standardised execution semantics. Of course it might be possible to transfer a BPMN diagram from tool A to tool B, but there is no way you can be sure that A and B will execute it in the same way.
On the other hand you can transfer a BPEL model to different engines and it will execute in the same way. Of course there are technical problems with proprietary extensions, but that’s more a technical than a conceptual problem.
If you transform a BPMN diagram to BPEL, you define a mapping and therewith the execution semantic.
However, I agree with you that you don’t earn anything if you just want to execute your BPMN model on the engine of a single vendor. My concerns are only relevant if you are using engines from different vendors.
Hello
We have recently developed conversion hub which transfers diagrams between the variety of formats: ARIS, Microsoft Visio, Microsoft Excel,
SAP Solution manager, Casewise, XML Metadata Interchange, XPDL.
There are, in fact, many problems in conversion because we have to map complex patterns and reconstruct elements in some formats which are absent in others. We can discuss some general approaches, which we have developed recently.
We are looking to certify by official XPDL compatibility test. We have contacted XPDL officials as specified on official site. But there seems no response. Is anybody aware how exactly certification procedure looks now?
Thank You in advance. Hope it is not off topic.
Boris,
Thanks for the comment as well as the email which I have already replied to. I have been expecting to see products which will do generalized transforms between different formats. This is a natural outcome of the success of BPM in general, and the desire to reuse old assets in new products. I was not previously familiar with your product, but from the information on the web site it looks very promising.
We need to get it registered in the list of products that support XPDL!
Hello Kate,
I have had the same problem of Boris.
On 2 April 2008 I written to Nathaniel if we could use the “Powered by XPDL” brand for our tool, the bxModeller (it models diagram in BPMN and serialize it in XPDL2.0. You can find it at http://bxmodeller.eng.it). After we have posted the XPDL Interoperability Test on the bpm-research forum. So we didn’t have any response.
Please, do you can help me?
Thank You in advance. Hope it is not off topic.
Antonio
Pingback: Is the BPMN/BPEL Debate a Dead Horse? « Go Flow
I found your blog on google and read a few of your other posts. I really interested and I just added you to my Google News Reader. Keep up the good work. Look forward to reading more from you in the future.Cheer!
Pingback: BPMN-to-BPELにおける課題：最終回 « 岩田研究所
Pingback: BPMN-to-BPELにおける課題：第2回 « 岩田研究所
Pingback: BPMN-to-BPELにおける課題：第1回 « 岩田研究所
Pingback: Still think you need BPEL? | Thinking Matters