BPMN和BPEL有可能实现往返工程吗？

　　BPMN只是为标注设定了标准。它和语义学有点关系，但还不足以生成可运行的东西。Rowley提到，对于如何将BPMN转化为可执行的东西，厂商有几种不同的选择方法。一种方法是用厂商各自的专利技术来创建BPMN示意图，但Rowley表示，这样会令开发人员局限于该技术中。

　　Rowley解释道：“如何创建基本控制流，并具有可执行性，是需要投入大量的精力。当你投入这么大的精力时，是不希望被束缚于某一种厂商的技术之中。主要的问题存在于数据。数据操作完全不是在BPMN标准的范畴之内。但如果希望工作流能顺利执行的话，这又是一个不得不考虑的问题”

　　同样，把完成的BPEL代码转化为业务人员能理解的图标也很重要。工程师擅于发现异常事件，通常能够考虑到业务人员可能忽视的工作流事件。Rowley说：“工程师可能考虑到一些执行案例，例如，万一服务宕机，或做这个工作的人被炒了。工程师们可能设计另一种工作流，不同于图标中，然后给业务人员看。这样可以促进开发者和业务分析师之间的协作。”

　　Tartu大学计算机科学研究所的软件工程教授Marlon Dumas说：“BPMN和BPEL之间的转化是需要资金推动的。其中包括授权成本、安装成本、培训成本等。此外，还要付出额外的开发努力，让研究同步进行。所以必须有实实在在的投资回报。比如，如果BPMN到BPEL的转化可以让公司不被某特定厂商绑定，就算是一种回报。不过，我还没有看到厂商热衷于BPMN和BPEL之间互操作性的推动。甚至不同的BPMN工具之间或者不同的BPEL工具之间都存在互操作性问题。”

　　BPEL和BPMN将何去何从？

　　业内人士对BPEL和BPMN的共同发展有着不同的看法。Dumas认为，BPMN仍然将继续存在，但BPEL的前景尚不明朗。

　　他说：“BPMN存在已有一段时日。至少在业务分析社区中，BPMN将持续使用。在很多进行流程再改造的大型机构中，BPMN已经取代了流程图、IDEF和EPC（事件驱动流程链）。”

　　如果厂商采用BPEL，是否将引领用户更广泛地采用BPEL？对此，Dumas持怀疑态度。

　　Weerawarana则看好BPEL的前景，业内多数厂商目前都支持BPEL。同时，他表示，BPMN将在业务分析领域继续成长。他认为这两种标准都将持续发展下去，因为它们都是自动业务执行中很有价值的组成部分。

　　“这不是两种竞争的标准谁获得控制权的问题，”Gartner的Sholler说，“而是这两种优秀的标准都只能够解决一个问题的某些部分，两者都不够简洁，不够统一。”