随着得到改进的BPM工作流工具的出现，一些基本的基础设施工具受关注程度下降了。后者中值得关注的有业务流程执行语言（BPEL），它通常用来将业务愿景转化为在计算机上运行的东西。BPEL现在发展如何了呢？

　　今天，BPEL面临着一场针对新来者来说的难度不断爬升的战役：对BPMN（业务流程建模与注解）2.0之战。实际上，对于某些企业实践者来说，BPMN 2.0也许可以成为通往BPEL服务基础设施的路径；BPMN 2.0增加了对导出到BPEL的支持。

　　从很多方面来说，BPMN 2.0已经把对BPEL关注转移到自身身上。尽管如此，BPEL似乎已经找到了一个稳定的位置，负责为工作流集成下面的软件服务进行技术协调。其对于以人为本的BPM的重要性不那么明显了。

　　“BPEL仍然活蹦乱跳。在其自身的领域里，BPEL作为标准的建模注解手段实际上还是相当成功的，” Neil Ward-Dutton说：“客户用BPEL来为应用集成建模做注解。”Neil是流程咨询机构MWD Advisors的研究总监。

　　与此同时，“它仅适合于特定类别的建模领域这一点已经为更加广泛的实践者团体所理解，”他补充道。实际上，尽管一些角色与业务流程有关，但在今天，BPEL的天生角色十分适合于充当Web服务的协调者。

　　BPEL和工作流Web服务

　　协调者的角色是天生的。BPEL在第一代Web服务期间诞生，彼时正值众多服务于不同目的的基于XML的语言的出现。其在机器对机器的交互中的作用非常受限。这是大多数BPM应用的一个缺陷，在这些应用里面，人通常是流程固有的部分。

　　在大多数BPM系统中，人是关键角色，典型的BPEL建模并未涉及这一需求。一项建立“BPEL4people”的努力旨在解决这一缺陷。然而，许多推动BPEL的公司同时也在BPMN上发力。这里是一个更具广度的方案，也是有可能得到非程序员的开发的承诺，这能够激发经理的兴趣。从某种角度来说，BPEL4People参加聚会似乎迟到了。

　　“有些你真心想要干的事情的确就是不适合于BPEL。不过它在为工作流对Web服务进行协调方面是有价值的，” Ward-Dutton说。

　　“今天，已有的注解【语言】版图已经变得更加成熟，更多的投资商开始进一步的研究BPMN，”他补充说，此前同样是这一块领域则要碎片化得多，基本上是由供应商来主导，他们的提供工具帮助人们协调Web服务的基础设施，他说。

　　BPEL的主要用例

　　BPEL的主要用途是Web服务协调而非面向人类的活动，这一点BPM架构师和行业分析师Sandy Kemsley也表示同意。“作为一种序列化和交换格式，BPEL主要用于把BPEL作为核心执行语言的系统之间，”她在最近的一篇BPM过去5年回顾的博客中指出了这一点。

　　这带有否决BPEL的倾向。据BPM咨询机构负责人Mariano Benitez说，“BPMN 2.0现在是BPEL的‘超集’。”性能是个问题吗？Benitez说不会。“你可以对BPMN内的任何BPEL进行建模并执行，业务流程管理系统的性能应该有点类似于BPEL引擎，”他说。

　　Benitez指出，BPMN 2.0的注解、其对模型中用户的考虑，以及其执行语义和XML格式，这些都是好处。“除了没有人来干预的真正的服务协调外，我看不出用BPEL有何商业上的缘由。” Benitez如此断定。

　　BPEL4PEOPLE的能力短缺时代？

　　几年前，BPEL还得到了更多活跃供应商的支持，被视为拥有更为广阔的潜在用途。但现在情况变了，这形成了BPEL4People努力的背景，Ward-Dutton说。

　　BPEL4People增强致力于解决的“机器偏差”现在也许有点无关紧要了。其原因部分是政治性的，Ward-Dutton认为：“这会影响到哪一个供应商把投资放到哪个标准上，”他说。

　　“曾经的那些对切实推动BPEL很有帮助的基础设施供应商，现在在推动BPMN方面也下了很大的功夫，”他说。

　　与此同时，有的观察者质疑业务流程标准执行语言需求的紧迫性。尽管用户的确希望减少受到代码锁定的威胁，但却很难见到过此类移植的实际报告。回到BPMN级的描述也许也可以提供跟BPEL级一样的保证。

　　BPMN 2.0还很新，其对非技术团队成员（业务侧非程序员）的适合性仍是争论的议题。与此同时，BPEL比较狭窄的协调服务集成方面的角色似乎也没有改观。随着BPM向着涵括业务活动监控（BAM）和运营型BI迈进，这将会成为务虚的建模与务实的运行相接之处。