Web 服务编配引擎 Apache ODE 1.2 发布了

Apache ODE（编配指导引擎）团队 7 月份宣布，它的

1.2 版发布了，其中包含了很多的新特性、改进以及缺陷修订。Apache ODE 是一个 WS-BPEL 兼容的 Web 服务编配引擎，它可以使开发人员根据以 BPEL XML 语法写成的过程描述来编配 Web 服务。

本次发布的版本中包含的主要部分如下：

• 外部变量允许业务过程变量可见，并可以直接在过程实例之外操作。举个例子来说，这种机制可以用在外部配置过程的数据库访问或者服务调用地址。
• 支持 WSDL HTTP 绑定，并提供了允许 REST 式 Web 服务调用的扩展。
• 支持两个通信层：一个基于 Axis2（Web 服务 http 传输），另一个基于 JBI 标准（使用 ServiceMix）。
• 高级端点配置，它在 Apache Axis2 通信时支持对 WS-Security 和 WS-RM 的配置。
• 一份冗长的改进与修补的列表，实现了稳定性、性能与可用性的最佳组合。

除了这些新的特性，Apache ODE 还提供如下功能：

• 对 WS-BPEL 2.0 OASIS 标准以及遗留的 BPEL4WS 1.1 供应商规范的支持。
• 给引擎提供的高层 API 允许你将任意通信层集成到内核中。
• 过程（process）热部署。
• 以编译方式转变为在命令行或者部署时提供细节分析和验证的 BPEL。
• 过程、实例与消息的管理接口。

InfoQ 采访了 Apache ODE 的副主管

Matthieu Riou ，他还是 Apache 软件基金会成员、Intalio 项目的架构师，并参与了 Apache Tuscany。关于 ODE 1.2 最重要的特性，Matthieu 解释说：

我想我们怎么称呼外部变量是件很有趣的事。传统上，编配引擎往往表现为一个黑盒，它与系统的其它部分广 泛交流，却并不提供访问它其中内容的办法。过程执行、接收消息、处理消息并将新消息发送出去。但是过去你的过程定义、执行是相当不透明的。过程处理的数据 是最明显的。特别是在数据存储为 XML 的 WS-BPEL 中，它向传统数据存储机制的映射并不是很完善。 所以这个特性使用户可以直接在自己选择的数据库表中存储过程变量。我们提供一个简单的映射工具来使你对表结构有合理的控制 能力。所以对这个映射变量的所有读写都会被数据库表返回。这是一个相当简单的特性，但是它很大程度上开启了通向报告、业务动态监测或者甚至过程数据的热修 改的可能性。

我们还计划扩展这个特性，用以支持从一个过程变量向一个 REST 式资源的映射。这样的话，一个 REST 式 Web 服务可以被一个过程直接访问和操作。

关于在 ODE 中支持 REST 式 Web 服务的意义，Matthieu 告诉 InfoQ：

我们的一个问题是 WS-BPEL 只支持 WSDL 1.1，至少迄今为止还是这样（而且我没听到任何关于要把它升级到 WSDL 2.0 的消息）。所以我们必须处理 WSDL 1.1 和它的 HTTP 绑定的支持问题，说实话，它们支持的并不多。 所以我们对它做了一点扩展，给 WSDL 1.1 HTTP 增加了一些基本的元素。例如，我们不仅仅在绑定层接受动词，在操作层也接受。这样，WSDL 端口类型可以被映射到一个资源与对 HTTP 方法的操作。注意，如果仍然可以用 HTTP 绑定支持你的用例，那就不需要任何扩展。

所有这些对 WS-* 和 REST 的纯化论者听起来都像是异端邪说，但是这样做也让你调用 REST 式 Web 服务时有一个相当清晰的思路。我们一向非常小心，从不对 HTTP 做超出 WSDL 的滥用。

尽管这样，我们还是有一个更长期的计划来扩展 ODE，使其对 REST 式体系架构的支持更加本地化。我们希望使过程符合 REST 风格，通过一个统一接口发布它们，并且我们还有大规模扩展 WS-BPEL 的计划。对此我们已经有了我们自己的规范，叫做

REST 式 BPEL ，并且我希望每个人都去看一看并提供反馈意见。

关于 SCA 和 BPEL 的集成：

事实上这个工作已经以 ODE 与 Apache Tuscany 团队合作的方式启动了。我们有一个 SCA 组合与 BPEL 过程之间交互工作的简单场景。最新的 Tuscany SCA 发布（1.2.1）就包含了带有一个 BPEL 过程应用示范的 ODE。

当被问到他们是否计划为请求 / 应答的实现而支持 WS-Addressing 时：

我们对 WS-Addressing 已经有很多支持了。对我们来说，它的价值在于可以在过程发送的 EPR 里包含关于过程实例身份的附加信息。因此，我们不需要过程的相关性来处理交互。过程实例仅仅使用包含在消息的 WS-Addressing 头部的 EPR 来互相发现。 此外，如果你的服务实现也要使用那些头部，并且在你调用服务的时候将头部提供给过程引擎，相关性就可以被彻底的避免。

Matthieu 被问到了是否有计划去实现 BPEL4People 和 WS-HumanTask，对此他回答道：

ODE 的覆盖面远远不止 WS-BPEL，它还包括编配和人类工作流。从历史上说，我们曾经更加关注 BPEL 和编配，但是我们中的一个委员（Assaf Arkin，他也参与了前面提到的 REST 式 BPEL 规范的编写）目前在做一个很酷的项目的经理，这个项目叫 Singleshot。它是在 Rails 上实 现的，用一个友好的人机界面将我们的 BPEL 引擎弥补得极为完善。 与此同时，Intalio 也有一个开源的工作流产品，叫做 Tempo，它实现了 BPEL4People 白皮书。

最 后，我们计划支持包含在 BPEL4People 中的 WS-BPEL 扩展，如同 peopleActivity。不过做这些对我们来说还不到时候。如果社区中 还有人想它发生的早一点，我们会对他致以毫无保留的感激。ODE 最令人印象深刻的一点就是它是一个 Apache 项目。正因如此，我们在一个商业友好的许可 下开发，并且我们欢迎任何类型的贡献，代码以及简单的反馈、文档、测试或者仅仅是你的热情。

随着这个新版本的发布，Apache ODE 巩固了它在基于 BPEL 的开源编配实现领域的领导地位。扩展 ODE 到一个更完整的人机交互工作流实现的工作也已经开展了。