书摘和采访： jBPM 开发者指南

Mauricio 的新书《 jBPM 开发者指南》对 Java 开发者提供了完整的 jBPM 编程指导，其中包含了大量的现实案例。

这本书为 Java 开发者提供了非常详细的 jBPM 导引。Mauricio 首先介绍了业务流程，业务流程管理和面向图编程，接着展示了这些概念是如何由 jBPM 来实现的。这本书展示了许多 jBPM 实现的内部细节，并对开发者如何在项目中更好的利用 jBPM 提供了实际的建议。虽然这本书主要是基于旧的 jBPM3 版本而不是最新的 jBPM4 版本而编写 的，但其中许多讨论仍是适用于这一新发布的版本的。

对于那些不仅想要理解正式的 jBPM 语法，并且还想深入了解支撑 jBPM 的架构与实现的人们来说，这本书是一个很好的起点。而 jBPM 的开发总监 Joram Barrez 对该书的书评也值得参考。

Packt Publishing 专为InfoQ 读者提供了书摘，描述了jPDL 语言的基本结构，这篇书摘是取自该书的《第4 章：jPDL 语言》。

InfoQ 对 Mauricio Salatino 进行了采访，了解该书背后的创作动机以及他个人对于 jBPM 的使用经验。.

InfoQ：当谈论主流的业务流程管理时，你没有明确的谈到业务活动监控和流程仿真。你是否认为这些是 BPM 的重要元素之一呢？

MS：是的，对于所有的 BPM 实现来说，它们都是非常重要的概念和结果。我在这本书中没有包括相关的内容，是因为这本书是专注在当开发者转变到 BPM 模式这种思维的时候所走出的第一步。我这本书尝试解释一个开发者使用任何一个 BPM 框架时所要具备的所有概念。而我们运行了业务流程之后所进行的一切信息分析的工作实际上与业务分析和数据挖掘概念紧密的联系在一起。

InfoQ：在描述 BPM 历史的时候，你写到 SOA 的引入很大程度上对 BPM 造成了混淆。你如何定义 SOA 与 BPM 之间的关系？

MS：我们可以将公共的 BPM 框架看作是编配面向对象架构内所有服务的一种粘合剂。我知道这种角度对于技术讨论来说是非常适合的。但如果我们将 BPM 作为一门学科来探讨，SOA 与 BPM 毫无关联。我们必须明智的选择词汇，而不把术语与业务上下文混淆在一起。而这正是我这本书的一个根基之一：澄清 BPM 这一学科可用于任何地方，不管是使用不同的框架，或者仅仅使用纸和笔。

InfoQ：在你的书里你将 BPEL 定义为"一种支持异构系统以 Web 服务标准进行通信的集成语言。"这是否意味着你不认为 BPEL 是与 jPDL 类似的一种流程定义语言？此外，BPEL/SCA 的绑定能简化了非 Web 服务部件的 BPEL 应用。你是否仍认为 BPEL 是纯粹面向 Web 服务的呢？

MS：我认为 BPEL 是一种编配语言。它原本被理解为一种系统编配语言。BPEL 是一种纯粹的技术语言，用于构建 BPEL 语言的语义与定义业务流程情况下的语义并不匹配。在这些业务情境中我们需要表达人们是如何进行日常工 作的；它如何实现没有关系，不管选用什么语言或者是否使用 Web 服务。

InfoQ：你的书中描述 GOP 与 OO 的区别，你提到了开发流程，三层架构等等。你认为最主要的区别是什么？

MS：再次强调，从技术层面来比较的，也许你不觉得两种范式有什么区别。但如果你想要使用流程图来表示人员的工作，你就会发现流程将能更准确地描述活动顺序。在书中我还提到，当我们使用 OO 范式的时候，要在 任何时间图形化地表示出我们的应用程序在哪里并不容易。而使用 GOP，你可以明确的看到活动是如何地实时被执行的。当你需要向经理层报告所有的工作完成时，这一点非常重要。

InfoQ：在你的书中描述了几种实现决策句柄（decision handlers）的方案，包括决策句柄（decision handlers），表达式，等等。开发者在什么样的场合使用它们你有什么建议吗?

MS：在复杂的场景中我总是推荐使用决策句柄（decision handler）实现。这可让我们使用诸如 JBoss Drools（一个接口引擎）这样的复杂工具来将传播流程执行的责任委派下去。责任的外部化将会使你的流程更容易维护并且保持其焦点。

InfoQ： 你在书中写到“记住 jBPM 是一个框架，而不是 BPM 引擎。它工作的方式与这一概念相去甚远”，但只给出了一个例子——持久化（它工作的方式又正好跟 BPM 引擎相似）。你能不能说明一下 jBPM 与 BPM 引擎的不同？

MS：jBPM，如同其它的 BPM 框架一样（OSWorkflow，Drools Flow 等等），是无状态的框架。我们不需要有一个庞大的机器和重量级的服务器运行在它们里面。每个想要使用业务流程的应用会在其自己所掌控的内存片段里 执行。对于长时间运行的流程，唯一的要求是一个可维护所有中间状态的数据库。通常，刚接触这一类框架的用户会认为他们将要在专门的机器上安装一个中心化的 业务流程引擎，但对于 jBPM 而言恰恰相反。我们只需要一个数据库来处理长时间运行的流程。

InfoQ： 尽管 jBPM 为用户表格定义提供了基本的支持，你在书中没有提及这一点。你是否不建议使用它？

MS：我通常建议定义和使用你自己创建的屏幕。这将提升用户交互和你的开发流程。基本上可以说这是因为你的 UI 开发者不需要去学习一种新技术，他们可以运用所熟知的东西，然后使用 jBPM API 来填充 UI 层所需要的所有信息。

InfoQ：你的书中也没有提及 jBPM 管理控制台。你觉得它是有用吗？

MS：我认为它仅对那些想要测试他们定义的流程的开发者而言有用。对于业务样例和生产环境我则一点 也不推荐。如同我在前一个问题里所提到的那样，我认为创建你自己的管理工具和为你的终端用户开发定制的 UI 才是良好的选择。

InfoQ：在人工任务（human task）里，你没有讨论用户指派（assignment）的泳道（swimlane），这样做的原因是什么?

MS：并非如此，我不得不删减一部分内容，否则这本书可能有上千页。泳道是一个重要的概念，但随着 BPMN2 这样的标准出现，解释 jBPM3 当中的泳道这样的概念可能会对采用新标准的人们带来误导。我试图只阐释会被应用到这一框架新版本当中的概念。这也是我在初始的章节宣扬创建你自己的 BPM 框架的原因之一。

InfoQ：你描述了在 jBPM 中处理信息的 2 种方式——对象变量和基本变量。对于什么时候两者之间某个更适用，你能提供一点帮助决策的参考吗？

MS：解释这两种处理信息的方式，其目的是给予用户其在特定情况解决问题提供决策的灵活性。以我个人经验，我注意到人们在已经有现有的使用 JPA 或 Hibernate 进行持久化的实体定义的数据模型时，通常会选择使用对象。所有的流程控制变量（通常是布尔标识）都会以普通的基本变量类型来保存。从高层次的规则来看，我通常会说：

• 若是流程控制变量，则使用基本类型变量
• 若是领域特定信息（文档，人员，票据），则使用对象类型变量

InfoQ：你在书中描述了超级状态节点（Super state）和流程状态节点（Process state）。能否提供何时使用它们的参考意见？

MS：这很容易，“流程状态”节点让你可以创建非常高层次的流程。其定义可以被分解为更详细和低层次的流程然后再链接到一起。“超级状态”节点可以让你在同一个流程定义里对你的活动进行分组并有序地组织到一个逻辑组和阶段里。有了超流程状态节点你可以查询你所等待的流程阶段是哪一部分。

查看英文原文： Book Excerpt and Interview: jBPM Developer Guide 。

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。