到底谁需要 BPEL?

  • Boris Lublinsky
  • 胡键

2009 年 2 月 2 日

话题:SOA架构文化 & 方法

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?

SOA架构文化 & 方法