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，应该从哪儿入手呢？

\

\t如果你想要获得一些实际开发经验，那么最好是通过 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