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?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论