Comments on: Marlon Dumas on BPMN-BPEL round-trip engineering http://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/ Fri, 10 Apr 2009 11:39:20 +0000 http://wordpress.com/ hourly 1 By: Marlon Dumas http://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/#comment-282 Marlon Dumas Tue, 03 Apr 2007 05:31:11 +0000 https://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/#comment-282 Hi Yi, The example that you refer to can be translated using the pattern-matching technique presented in the following paper: http://eprints.qut.edu.au/archive/00006810/01/6810.pdf 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: http://eprints.qut.edu.au/archive/00005266/01/5266.pdf 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: http://every20.wordpress.com/2007/03/18/bpmn-to-bpel-round-tripping/ Hi Yi,
The example that you refer to can be translated using the pattern-matching technique presented in the following paper:
http://eprints.qut.edu.au/archive/00006810/01/6810.pdf
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:
http://eprints.qut.edu.au/archive/00005266/01/5266.pdf
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:
http://every20.wordpress.com/2007/03/18/bpmn-to-bpel-round-tripping/

]]> By: Yi Gao http://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/#comment-157 Yi Gao Tue, 02 Jan 2007 22:50:12 +0000 https://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/#comment-157 You may see the diagram at http://www.brsilver.com/wordpress/wp-content/yigao1.gif You may see the diagram at http://www.brsilver.com/wordpress/wp-content/yigao1.gif

]]> By: Yi Gao http://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/#comment-156 Yi Gao Tue, 02 Jan 2007 22:48:05 +0000 https://pkok.wordpress.com/2006/07/11/marlon-dumas-on-bpmn-bpel-round-trip-engineering/#comment-156 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. 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.

]]>