Red Hat 的 jBPM5 引入了新的 API、新的工具并支持 BPMN 2.0

近日，Red Hat 的 JBoss 部门发布了其业务流程管理系统jBPM 的5.0 版。jBPM5 包含了完全重写的API，并增加了大量的关键特性，包括对BPMN 2.0 规范的支持、面向开发者的Eclipse 工具以及面向业务用户的Web 工具。InfoQ 有幸采访到了jBPM 项目领导Kris Verlaenen 以深入了解关于此次发布的详细信息。

InfoQ：你认为架构师或开发者在何时应该放弃构建自己的状态机，转而选择 jBPM 等产品呢？

准备使用 BPM 且只需要一些简单状态机的项目可以考虑构建自己的实现，而不必使用现有的工作流引擎（比如说，他们认为工作流引擎对于其需求来说过于复杂了）。然而，人们通常会严重低估开发、支持和维护私有解决方案的代价。一开始只需要简单状态机的项目可能会随着时间的流逝需要加入越来越多的特性（想想持久化、流程仓库、图形设计器吧）；这些特性是很难独自开发出来的。 jBPM 则是多个模块的组合，核心引擎本身是轻量级的，可以嵌入到任何应用当中。如果需求随着时间的流逝而不断发展变化，那么我们可以将更多的组件轻松添加到架构中，并发挥 jBPM 的巨大潜力。由于 jBPM5 基于 Apache Software License（ASL），因此你可以随意使用、分发并修改它（甚至将其作为私有软件的一部分）；jBPM5 是基于标准的，对于集成和交互性来说提供了极大的便利。

InfoQ：Drools Flow 和 jBPM5 之间是什么关系呢？你将这两个项目合并了么？

jBPM5 合并了 jBPM 项目和 Drools Flow。Drools Flow 已经有几年的历史了，其目的是通过集成业务规则和复杂的事件处理实现灵活和可适配的业务流程并建立原型。实践已经证明，这些特性不仅是可行的，而且从长远来看，它会带来巨大的价值，能够更好地管理真实用例的复杂性。在过去几年间，这些内容已经与 jBPM 构建过程中所积累的经验很好地融合到了一起，jBPM5 就是在这个基础上出现的。但 jBPM 的愿景并没有发生变化，只不过得到了拓展。Drools Flow 将不再独立发展，最新版的 Drools 已经在使用 jBPM5 处理其流程需求了。

InfoQ：相对于工作流市场上的其他同类产品而言，jBPM5 有何优势呢？

毫无疑问，jBPM5 是目前最强大且开源的 BPMN 2 引擎之一。其核心引擎本身是轻量级、可扩展的，并且可以集成到应用当中，也可以部署为服务。jBPM5 既为开发者（可以通过其强大的 Eclipse 插件实现图形化编辑、测试与调试）服务，也为业务用户（通过基于 Web 的管理与监控工具）服务。开发者与业务用户能使用相同的语言交流，这是因为业务引擎使用了高层次、特定于领域的概念，这些概念很容易为业务用户所理解，并且隐藏了流程的实现细节。

jBPM5 不仅仅是个孤立的流程引擎，而且还作为更庞大的解决方案的一部分而存在，该解决方案可以与你的环境、服务集成到一起。为了更够处理好复杂的实际问题，jBPM5 支持动态适配和灵活的流程。最终用户可以通过整合业务流程、业务规则和复杂的事件处理来定义其业务逻辑。在一切可能的情况下，jBPM5 都使用标准来简化集成与交互，比如 BPMN 2，同时还使用了 WS-HT 实现人工任务、使用 JPA 和 JTA 实现持久化和事务。

InfoQ：此次发布有哪些关键的新特性？

毫无疑问，jBPM 5.0 的关键特性是对最新的 BPMN 2.0 规范的支持，可以建模并执行业务流程。这包括面向开发者与业务用户的基于 Eclipse 和 Web 的工具。jBPM 5.0 还引入了全新的流程仓库，改进了对领域特定流程的支持（可以在 palette 中插入自己的节点类型），对核心引擎进行了比较大的调整，使其更加灵活、适配性更强、动态性更好。最后，jBPM 5.0 还引入了其他一些新特性，比如 Business Activity Monitoring（BAM）支持、模拟、网格和 OSGi 支持等。

InfoQ：是什么促使你决定修改 5.0 版中的 API 呢？新的 API 有何优势？

jBPM 的早期版本并没有明确区分最终用户所使用的类以及实现之间的差别。使用一套整洁且稳定的接口，能够表明程序员应该如何与引擎进行通信是至关重要的，并且这些接口应该隐藏掉实现细节。jBPM5 还使用了我们称之为 knowledge 的 API。我们已经协调好了用于管理业务流程、业务规则和复杂事件处理的 API，这样如果你已经了解了这些技术，那么学习 jBPM5 将变得易如反掌。这样做，我们不仅可以共享 API，还可以共享大量的特性与工具，比如基于 Web 的管理控制台、调试、持久化、知识仓库等等。

nfoQ：现有的功能——比如对 Spring 的支持是否加到了 jBPM5 当中了呢？

当然了，我们肯定会向前迈进的。在合并两个项目时总是很难保证不会丢掉什么东西，但我们相信此次合并已经包含了所有的主要特性。即便 jBPM 5.0 已经发布了，我们还是在尽最大努力进行着改进。比如说，我们仍然在改进并扩充 jBPM5 文档以包含进一些之前没有的内容，如 Spring 或 OSGi 支持等等。

InfoQ：目前的工作流充满了各种标记 / 定义语言，看起来非常零碎。jBPM5 支持 BPMN 2，此外还有私有的 jPDL。与 jPDL 相比，使用 BPMN 有何好处呢？

jBPM5 关注于 BPMN 2 和流程定义语言。作为 BPMN 2.0 规范的贡献者，我们相信从长远来看，使用这个标准（而非私有的 jPDL 格式）会给你带来巨大的好处。BPMN 2 将业务流程的可视化和底层的 XML 表示进行了标准化，这极大地改进了建模工具（比如说基于 Web 和 Eclipse 的设计器）之间的交互性。BPMN 2 标准是非常可靠且可扩展的，这样在必要的时候就可以引入新的元素和属性了（但我们只在万不得已的情况下才会这么做）。在 jBPM5 中，BPMN 2 所能完成的建模要比之前的 jPDL 多不少，而且是处于更高的层次上。因此，jBPM5 不再直接支持 jPDL 的执行了，我们现在正在开发从 jPDL 迁移到 BPMN 2 的工具。

InfoQ：还有哪些语言可以用来描述工作流呢？比如说，支持 BPEL 么？

核心引擎本身使用了一个 Java POJO 模型来表示流程，这样对描述格式就没什么具体的要求了（我们甚至可以在 Java 中使用 fluent API 创建流程）。但我们将重点放在了 BPMN 2 上，将其作为流程定义语言并且使用了 XML。通用的流程引擎（即众所周知的 PVM）可以扩展以支持其他格式，但我们目前还没有确定的计划增加对其他语言的支持。能够映射到 BPMN 2.0 上的其他语言（比如说 XPDL，未来甚至还会有 BPEL 的子集）都是可以移植过来的。凭借 jBPM5 API，你还可以自己实现各种类型的流程定义并加入进来。比如说，我们开发了一个原型，可以使用相同的 API（和工具）执行并管理 BPMN 2 和 BPEL 流程，但在内部，BPEL 流程的执行是委托给 JBoss RiftSaw 项目的，该项目支持本地的 BPEL 执行。

InfoQ：要想学习 jBPM，应该从哪儿入手呢？

如果你想要获得一些实际开发经验，那么最好是通过 jbpm-installer （下载文件）上手。这会下载并安装所有必要的组件，并且通过一个简单的示例帮助你快速上手各种工具。你还可以查看 jBPM5 文档，阅读最新的博客或是观看视频。你可以在 jBPM 主页上找到各种信息的链接。

InfoQ：该项目的未来规划如何？

下一版本的发布周期是 3 个月，这意味着 jBPM 5.1 将于 5 月初发布。对于 jBPM 5.1 来说，我们打算开发一个新的基于 Eclipse 的 BPMN 2 编辑器（使用最新的技术完整支持 BPMN 2）、改进 Web Services 支持、开发一个领域特定节点或连接器的仓库（连接到现有的系统与服务上）以及对 Business Activity Monitoring（BAM）的扩展。当然了，我们欢迎其他社区的贡献，比如说文档的改进、细微的代码改进、甚至是全新的特性。

查看英文原文： Red Hat’s jBPM5 Brings a New API, New Tooling and Support for BPMN 2.0