应用JSF、Ajax和Seam开发Portlets（1/3）
.gif)
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目，怎样配置一个JSF应用去使用JBoss Portlet Bridge，以及JBoss Portlet Bridge所具备的功能。
新闻
Web服务编配引擎Apache ODE 1.2发布了
作者 Boris Lublinsky译者 王锐 发布于 2008年9月1日 上午2时56分
Apache ODE（编配指导引擎）团队7月份宣布，它的1.2版发布了，其中包含了很多的新特性、改进以及缺陷修订。Apache ODE是一个WS-BPEL兼容的Web服务编配引擎，它可以使开发人员根据以BPEL XML语法写成的过程描述来编配Web服务。
WS-BPEL是一个最初由IBM和Microsoft开发，目前由OASIS Web服务业务流程执行语言（WSBPEL）技术委员会 维护的规范。工作组成员包括IBM、BEA、Adobe、JBoss、SAP、Active.Endpoints、Tibco、WebMethods、Oracle等等。
本次发布的版本中包含的主要部分如下：
- 外部变量允许业务过程变量可见，并可以直接在过程实例之外操作。举个例子来说，这种机制可以用在外部配置过程的数据库访问或者服务调用地址。
- 支持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到一个更完整的人机交互工作流实现的工作也已经开展了。
没有回复
回复