到底谁需要BPEL？

Keith Swenson在其新文章开始对当今BPM产品中的BPEL使用情况进行了评估：

“业务流程执行语言”或“WS-BPEL4WS”是BPM领域的执行标准，这种传统看法似乎已经持续一段时间了。而同时，当今市面上的大多BPM和工作流产品即使没有使用BPEL也能顺利地工作。一些人认为那些没有实现BPEL的产品只能让它们自己陷入麻烦，而另一些人则说用BPEL不可能完成他们产品所做的事。我们该相信谁？……最近，InfoQ发布了一篇 文章，文中给出了一条用业务流程建模符号（BPMN）绘制的特殊流程场景，并详细调查了它为什么不能用BPEL实现的原因。但是，这条流程可以运行在直接执行BPMN的系统上……既然能够直接执行BPMN，这就引发了一个问题：究竟为什么要被翻译成BPEL？

据Keith所说，很多供应商和出版物将BPEL捧为“支持BPM的一种正确且唯一正确的方法”。但在现实中，有很多成功的BPM产品都是基于其他技术的。因此，潜在的用户可能会问这样的问题“BPEL适合我打算做的事情吗？”

Keith把BPEL的流行归结于以下假设，而它们往往是BPEL支持者提出的：

• 流程制定者是程序员
• 流程中的活动只需要发送、接收或转换XML数据。
• 有标准比没标准要好。

Keith对它们进行了分析，指出前两个假设是：

……在某些情况下成立；我们称之为EAI的产品分类实际上主要是由程序员配置的，并且只需要发送、接收和操作字节数据。因而对于EAI来说，BPEL可能是个合理的选择。但是，许多BPM产品都被设计成由非程序员来配置；由业务人员自己（这就是为什么我们一开始就称之为业务流程的真正原因）。允许非程序员安全可靠地绘制和执行流程的非BPEL方法是存在的。这些流程在性质上不同于程序员绘制的流程，许多熟悉EAI风格“BPM”的人却是半信半疑，但该循环论证基本上是以“流程制定者是程序员”这个假设为基础的。公平的说，一些人认为是业务人员先绘制原始流程图，程序员然后对其进行修订。但是还存在根本没有程序员的其他情况，在这些情况下，BPEL将是一个蹩脚的选择。

至于最后一个假设，Keith认为它更像是“迎合市场的产物”，而不是实际情况：

人们认为，既然绝大多数“杂志”都已证明BPEL是正确的标准，那么那些不支持BPEL的人肯定是太懒或者是想扰乱市场。遗憾的是，对于这些人来说，流程世界本质上就比他们所了解的要复杂得多；方法上的不同不只是供应商的一时心血来潮，而其实是对不同流程支持需求的恰当响应。人们应该牢记实际的需求：如果BPEL满足这个需求，那最好，但是不要盲目地假定：它肯定是放之四海而皆准的。

Keith建议用可以直接执行的、基于BPMN的流程定义取代BPEL，并且展示了Fujitsu BPM Studio是如何做到这一点的。他在文末写道：

分析师们为何一再推荐BPEL？在我看来……它除了是桎梏之外，一无是处。

在业界，BPEL和普通BPM之间的混淆似乎在加剧。在许多最基本的BPM问题上仍存在分歧：

• BPM是业务学科还是软件工程？
• 实现（自动化）业务流程是谁的责任？
• 我们是否该把目标从设计转移到无需编程的部署上？
• 维护业务流程是谁的责任？

只有通过在这些问题上取得一致,才能让我们正确地进行BPEL讨论和整个BPMN/BPEL关系讨论。

查看英文原文：BPEL: Who Needs It Anyway?