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

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

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

我想我们怎么称呼外部变量是件很有趣的事。传统上，编配引擎往往表现为一个黑盒，它与系统的其它部分广 泛交流，却并不提供访问它其中内容的办法。过程执行、接收消息、处理消息并将新消息发送出去。但是过去你的过程定义、执行是相当不透明的。过程处理的数据 是最明显的。特别是在数据存储为XML的WS-BPEL中，它向传统数据存储机制的映射并不是很完善。

我们的一个问题是WS-BPEL只支持WSDL 1.1，至少迄今为止还是这样（而且我没听到任何关于要把它升级到WSDL 2.0的消息）。所以我们必须处理WSDL 1.1和它的HTTP绑定的支持问题，说实话，它们支持的并不多。

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

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

我们对WS-Addressing已经有很多支持了。对我们来说，它的价值在于可以在过程发送的EPR里包含关于过程实例身份的附加信息。因此，我们不需要过程的相关性来处理交互。过程实例仅仅使用包含在消息的WS-Addressing头部的EPR来互相发现。

ODE的覆盖面远远不止WS-BPEL，它还包括编配和人类工作流。从历史上说，我们曾经更加关注 BPEL和编配，但是我们中的一个委员（Assaf Arkin，他也参与了前面提到的REST式BPEL规范的编写）目前在做一个很酷的项目的经理，这个项目叫Singleshot。它是在Rails上实 现的，用一个友好的人机界面将我们的BPEL引擎弥补得极为完善。 最 后，我们计划支持包含在BPEL4People中的WS-BPEL扩展，如同peopleActivity。不过做这些对我们来说还不到时候。如果社区中 还有人想它发生的早一点，我们会对他致以毫无保留的感激。ODE最令人印象深刻的一点就是它是一个Apache项目。正因如此，我们在一个商业友好的许可 下开发，并且我们欢迎任何类型的贡献，代码以及简单的反馈、文档、测试或者仅仅是你的热情。