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?
评论