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

作者 Boris Lublinsky 译者 胡键 发布于 2008年11月18日 下午10时48分

社区

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

• 更早的 >