使用 JBoss jBPM 进行业务流程管理的 7 种形式

  • Boris Lublinsky
  • 胡键

2008 年 11 月 18 日

话题:SOA架构

在他的那篇关于流程组件模型和 JBoss 流程定义语言(jBPM)的优秀文章之后,Tom Baeyens 趁热打铁地又推出了另一篇,通过 7 个截然不同的用例对业务流程管理(BPM)的 7 种形式进行了解释

根据 Tom 的说法:

BPM 一词已经承载过多含义,并应用于许多不同事物,最终引起了大量混淆。这些用例具体描述了 BPM 这一术语的不同解释。

第一个用例试图探索“BPM 即戒律(BPM as a discipline)”:

“BPM 即戒律”是指对描述组织内人员和系统合作方式的工作程序的分析、记录和改进。要知道到,大多数 BPM 实际是以这种方式完成的,甚至连任何形式的软件或 IT 支持都没有。MS Visio 是使用最广的业务流程记录工具之一。

这一定义与广为人知且被广泛采纳的 BPM 定义略有不同,如 Van der Aalst 及其同事的定义

BPM 是一门汇集管理和信息技术的知识,包含了方法论、技术和设计工具、颁布、控制,以及对涉及人类、组织、应用、服务、文档和其他信息源的经营性业务流程的分析。

维基百科的定义

BPM 涉及组织管理和(如果必要的话)改进业务流程的活动。所谓的业务流程管理系统(BPM 系统)将使这种活动更快更廉价地进行。BPM 系统监视业务流程的执行,以便管理器能根据数据,而不是直觉,分析和改变流程。

两个定义都强调了成熟 BPM 系统三大主要组成:流程设计、实现和监视,而最后一个则在 Tom 的定义(及剩下的用例)中完全消失了。由于无法度量的就无法改进,因此流程监视是 BPM 的基本组成。

这一用例的余下部分集中在业务流程设计,设计模型到实现模型的转换,以及保持两者的同步。说到设计,Tom 的文章只关注了 BPM 设计的一个侧面——流程的图形化表示:

原始分析图应该作为软件需求剩余部分的输入。接着,开发者应该构造一个尽量符合原始分析图的可执行流程。

尽管很难反驳这一观点,但问题是图表是否就真的代表了流程设计。更能让人接受的定义是:除了图表支持,流程设计是还具有以下特性的工具:

  • 流程验证,确保被设计流程是“可实现的”。
  • 流程模拟,通过模拟流程变更的影响,它使得流程改进以一种更加受控的方式进行。

诚然,大多数这类工具都使用的流程模型完全不同于流程执行模型,这往往使得两个模型之间的转换成为整个方法的一个弱点。尽管 Tom 的“纯分析模型和可执行流程模型之间的自动转换一般是不可行的”这一论断很容易让人接受,但是“使用一个模型完成两个目的”(jBPM 方式)并不是唯一的解决方案。例如,Oracle 的实现就提供了“部分”支持 BPMN 和 BPEL 间的双向转换。

第二个用例集中讨论了以人类交互管理(Human Interaction Management,HIM)模型为基础的非正式(Ad hoc)任务管理。在主流 BPM 实现中包含非正式协作流程无疑会扩展现有 BPM 系统的作用范围。

HIM 的故事反映了人们为一个将创建的非正式流程而创建的任务(译注:即整个流程不是预先定义好的,而是根据实际情况,由人来判断下一步的走向。换句话说是“人驱动”的流程。)。人员可以参与不同角色。使用任务管理系统跟踪这一工作有巨大的好处。首先,参与这一任务的人会很快看到整个故事的历史。其次,审计留痕的日志会自动生成。

两个联系紧密的用例,服务编配和事务异步架构,讨论了作为流程执行基础的流程活动的实现和调用。笔者完全不明白 Tom 讨论这两个模式的意图:阐述 jPDL 和 BPEL 的区别?解释技术细节?以 Java 为基础的 jPDL 诚然提供了极大的灵活性,但是 Tom 却未解释这个灵活性的代价——开发者不得不编写额外的代码。简单地说,jPDL 和 BPEL 的区别在于:BPEL 是专为实现业务流程而设计的一种领域特定语言(DSL);而 jPDL 则是一个以 Java 为基础的框架,可以构建流程或新的 DSL,包括 BPEL。结果是,BPEL 向开发者屏蔽了线程问题,而 jPDL 往往要求明确的线程控制(见用例 6)。因此,在 jPDL 和 BPEL 之间做选择,基本相当于是选择高级语言,还是选择低级语言——即灵活性和开发简化(尽管 BPEL 编程并不总是简单)之间的权衡。

最后,谈到可视化编程(用例 5),BPEL 和 jBPM 是旗鼓相当,尽管使用“命名”活动(jBPM)似乎要比使用“命名”服务要更加显得用户友好些。

并不是所有人都同意Tom 的用例很好地代表了 BPM 场景。根据 Oracle 企业管理器分部应用和中间件部门架构师 William Vambepene 的说法:

就“BPM 一词已经承载过多含义,并应用于许多不同事物,最终引起了大量混淆。”来说,Tom 是对的。但是,据我所知,增加一些别人以前从未把它们归为 BPM 这一类的用例,他是在制造更多,而不是减少,混淆。

文章虽然非常值得一读,但其重点是 jBPM 及其未来,对于 BPM 则是泛泛而谈。

查看英文原文:Seven Forms of Business Process Management with JBoss jBPM
SOA架构