Nova Bonita——Bonita 4.0 发布

经过两年的开发，Bonita 项目组发布了 Bonita 4.0 （也就是 Nova Bonita）。Bonita 4.0 基于 PVM 技术，可作为一个轻量级的 BPM 产品部署，运行在 JSE 和 JEE 平台上。Nova Bonita 为 BPM 的开发和执行环境提供了一个集成的图形化环境，其中包括三个模块：

• Nova Bonita 运行时模块：Nova Bonita 流程引擎。可以通过提供 BPM 服务的丰富 API 对流程进行部署、执行和监控。
• Nova Bonita 控制台：一个 Web 2.0 图形界面，在 BPM 部署、执行和监控阶段提升用户体验。
• Nova Bonita 设计器：BPM 开发环境允许对流程、与已有系统集成的 BPM 连接器进行图形化定义。

最终的发版说明里提到：

版本 4.0 对 4.0RC3 的运行时模块进行了细微的功能增强（部署单个 XPDL 文件，活动多实例清理，日志级别调整，迭代和子流程重构，包级别和流程级别的版本化……），对设计器和控制台则进行了重大的改进和新功能添加。

InfoQ 借此机会向 Bull 的 BPM 主管 Miguel Valdes 问了几个问题，问题涉及最新版本和 Bonita 对 BPM 市场的想法。

InfoQ：Tom Baeyens（JBoss jBPM）曾描述，流程虚拟机对需要嵌入式工作流的应用来说是很理想的——对 Bonita 的用户来说，你是不是也这样认为？

肯定是的，这就是我们两年前决定建立流程虚拟机技术的原因。Bonita 4.0 现在可以嵌入到任何已有的应用中（作为 BPM 库），也可以作为传统的 BPM 服务器进行远程部署。

从这个意义上讲，Bonita 4.0 配备了一个 Eclipse 插件，可以轻松地开发 BPM 流程和相关的 Java 连接器。这个插件可以很容易地添加到开发人员的 Eclipse 开发环境中，来加速 BPM 应用的开发。Bonita 4.0 还提供了一个强大的、符合 Web 2.0 的 BPM 控制台来提升用户体验，所以说它不仅仅是针对开发人员和技术架构师的。

InfoQ：你们是否对 Bonita 4.0 如何支持工作流模式倡议的各种观点做出了评估？

我们在 Bonita 4.0 中还没有重新评估工作流模式支持，但我要说，我们在该版本中已经改进了这一点。在 4.0 中实现了 v3 中可用的主要概念和功能，除此之 外，Bonita 4.0 还进行了从无到有的重新构建。此外，我们还增加了对新功能和模式的支持（即活动的多实例）。

InfoQ：“基于模式的开源 BPM 系统评估报告”（InfoQ先前报导过）的作者提到，开源工作流产品一般更适合于开发人员，而非最终用户。你对此有什么看法呢？你觉得 Bonita 4.0 中新的设计器和控制台是否使它更易于被业务分析师理解呢？

正如 Gartner 在它们最近的 BPM Magic Quadrant 调查中指出的一样，一个成功的 BPM 部署会涉及不同的用户和不同的用户配置。不同的用户配置中包括业务分析师。这一思想与 Bonita 4.0 背后的新技术会加强这些不同用户配置间的合作。Bonita 4.0 发布的第一目标人群是开发人员和技术架构师，而分析师工具在后续版本中才会推出。

我们的下一步动作是成为针对最终用户的 BPM 开发 Studio（同时涵盖非技术用户配置和技术用户配置）。带有特定视图的简单 BPM 编辑器（“按 Visio/PowerPoint 的风格”）允许用户间的“重复”。那些视图不会特定于“每个用户配置”的基础之上（分析师、架构师、开发人员），但却基于“每个功能”（建模、执行）。主要视图（建模）将基于一个简单的“方框”和“箭头”面板，允许“方框”生成描述和文档信息。

InfoQ：你能给我们介绍一下 Bonita 4.0 中流程和包的版本化这一新特性吗？

4.0 中，我们能让用户有针对流程版本化的大量灵活性。最终用户可以部署、利用同一流程的两个或更多版本。一旦部署了一个新的版本，新实例就会接管，而进行中的实例则会使用先前的版本完成它们的执行任务。

在后面的版本中，我们将允许运行实例从一个版本自动迁移到另一个版本。此功能将在流程虚拟机级别添加，而且要求应用管理审批。自动迁移不能 100% 地覆盖用例，但我们对至少 70% 的用例有用还是有信心的（两个版本之间的大部分更新关注于活动和迁移的添加 / 删除操作）。

除了流程级别的版本化，Bonita 4.0 还在资源库 / 包级别提供版本化支持。资源库或包能包含一或多个流程定义，因此也可以版本化。

InfoQ：Bonita 继续提供强有力的 XPDL 支持。XPDL 的现状如何？你是否了解到 XPDL 有大量的市场需求呢？

好问题。Bonita 从其初期开始就一直对 XPDL 提供标准的支持。该标准在过去的几年里一直在发展，以涵盖像流程、流程通信、事件支持这些尚缺的功能，特别是它已成为绘制 BPMN 符号的语法。请注意，前十名商业 BPM 供应商中有七家都支持 XPDL。

我不会参与“什么是最好的 BPM 标准”这一争论，因为我真的认为这并不是用户关心的问题。用户只是寻求功能、性能、部署、稳定性……而有时一些供应商却忽略的这一点:-) 标准确实很重要，作为供应商，你也必须遵循这些标准，但这却不是主要的差异化。

这是我们决定创建流程虚拟机（PVM）技术的原因之一。除了其它关键的功能外，PVM 允许支持多个标准。我们已经在 Bonita 4.0 中添加了对 XPDL 的支持，我们很快会在 Orchestra 4.0 中发布 BPEL 2.0 扩展（同样由 Bonita 团队开发），JBoss 目前也在增加对 JPDL 的支持。

PVM 技术是语言无关的，我认为这一点很棒，尤其是如果在今后几年里出现新的标准！

InfoQ：商业供应商 Intalio 最近撰稿说 BPEL 已经“赢得了标准之战”。你对此有何看法？

这仅仅是一个“哗众取宠”的帖子。我始终认为，如果有不同的流程语言，这可能意味着其中的每一个都针对某一特定的需求。不过在处理 BPM 时，我并不认为 BPEL 是促进业务人员和技术人员之间合作最好的流程语言，主要是因为 BPEL 创建时并没有考虑这一点，而它是为了编排 Web Services 才创建的。

跟其它供应商一样，Intalio 将 BPMN+BPEL 推为 BPM 的“解决方案”。他们在复杂的转换上花费了大量的时间和金钱，却不能满足 100% 的用例（它仅仅是尝试用 Intalio BPMN 设计器定义一个非结构化的图，并浏览下生成的 BPEL 文件:-)）

另一个明显的例子是使用 BPMN 与 BPEL 和 BPEL4People 扩展来处理人类交互的复杂性。你认为对最终用户来说，通过将功能步骤分解为多个技术步骤，在流程中定义一个用户交互步骤（又名任务）是不是清晰的呢？

如果你使用 Intalio 编辑器，这就是确实发生的：你必须将流程中的一个功能步骤（一个任务）分解为四个不同的步骤：其中两个在“可执行池”中定义（其中一个会生成 BPEL 代码），另外两个在“非可执行池”中定义。你认为这种方法对用户友好吗？来吧，伙计！

InfoQ：你认为 BPM 在 SOA 中扮演什么角色？

这个时候 BPEL 对我来说更有意义。在一个基于 SOA 的架构中，可以利用独立的 BPEL 引擎由 BPEL 流程处理服务编排，或者在一个 ESB 解决方案的上下文中处理服务编排。这将是 Orchestra 4.0 的首要目标。

BPM 不仅仅是 SOA 的关键一部分。还有许多应用，其中纯粹的 BPM 方法仍然要比仅仅在应用中编写代码有用，这是 Bonita 4.0 的主要目标。

InfoQ：以后有在 Bonita 中集成规则引擎功能的计划吗？

有。规则引擎已可以插入到 Bonita 4.0 中。角色 / 组、用户、IS 连接器（Hooks）之间的映射（Bonita Mappers）可以与规则引擎交互。在下一个版本中，我们会集成规则引擎来提供这一功能的开箱即用。

规则支持在迁移情形下也很有用。对于此，Bonita 4.0 目前使用脚本语言，并提供了一个迁移情形的图形化编辑器，但我们还计划增加对规则的支持。

可在这里下载Bonita 4.0，它在LGPL 许可下发布。

查看英文原文： Nova Bonita - Bonita 4.0 Released.