Pete Muir谈Seam 3、RichFaces 4及来到Infinispan的动因

Red Hat的JBoss部门将在未来几个月内进行大量更新，包括发布新版本的Web应用框架Seam以及JSF组件库RichFaces。InfoQ有幸采访到了Red Hat的首席软件工程师Pete Muir以深入了解未来的发展变化以及他从Seam团队来到Infinispan数据网格团队的前前后后。

InfoQ：首先恭祝你来到了Infinispan团队。为什么会来到这个团队中呢？

多谢。我所遇到的大多数人，特别是软件工程师，都有这样一种工作循环周期：一开始他们非常喜欢自己所从事的项目，随着时间的不断流逝，这种热情逐渐消退。我决定寻求新的挑战，因为我深深地感觉到自己在Seam和Weld团队中的热情即将消失殆尽。Infinispan则是个很正常的选择，我曾经在硕士论文中研究过数据网格，Red Hat也在不断地增加对Infinispan的投资力度，这与公司的目标是非常一致的。

InfoQ：对于Infinispan，你有何计划呢？

从个人角度来说，我首先要从虚拟结点（virtual node）着手。Infinispan使用了一致的hash wheel以确保在分布式环境下实现确定、快速以及低代价的数据查询。然而，虽然有很多技术可以保证均匀分布（比如使用MurmurHash和一些spreader），但用户依然说拥有少量结点的数据网格并没有表现出良好的数据分布型（这会导致某些结点的过载，包括处理与数据存储），而拥有大量结点的网格却没有这个问题。虚拟结点则可以解决这个问题，因为它会在每个物理结点上提供多个节点。

Infinispan 5中还有其他很多激动人心的改进，且容我介绍两个。

首先就是已经在Alpha 2中所提供的MapReduce。从本质上来说，Infinispan提供了无限的线性内存数据的可伸缩性，但无法执行大量计算的数据网格就好比是开着法拉利，但却没有驾照一样。我们听到了来自于用户的批评之声：缺少对Big Data字段的检测、现有的分布式执行框架过于复杂；我们将精力主要放在了简化上，但却不会牺牲功能和众多的特性。感兴趣的读者可以在 Vladimir的博客上了解到关于Infinispan MapReduce的更多信息。

我们还在开发Hibernate OGM（Object-Grid Mapper）。Hibernate OGM重用了Hibernate Core引擎，但却将实体存到了Infinispan（最终是以键/值对的形式存储）而非关系数据库中。你可以像在JPA/Hibernate（同样的映射，同样的API）中一样映射并操纵实体。Hibernate OGM支持CRUD操作和大多数的JPA映射。我们还开发了查询支持，它以JP-QL的子集开始，随着时间的推移还会不断增加新的内容。该项目尚处于早期阶段，但长期的目标是支持大多数的JPA功能。感兴趣的读者可以从 http://community.jboss.org/wiki/HibernateOGMGeneralInformations检出项目并了解详细信息。如果你想尽快上手，那么请通过论坛联系Emmanuel或是Sanne。

InfoQ：我知道你将成为CDI 1.1的专家组领导，是这样的么？对于CDI 1.1来说，你有何计划呢？

我将担任CDI 1.1的专家组领导——事实上，我刚刚完成该JSR提案的首个草案，正打算在公布前收集一些反馈信息。我们认为CDI 1.0已经在社区中产生了积极的影响，很多人都能从目前的功能中实现自己需要的东西。然而，CDI 1.0还有一些小的瑕疵；总的来说分为两类——有一些是在CDI 1.0发布时我们就已经知道的了，但我们却没时间探求正确的解决方案；当然了，还有一些则是意料之外的情况。CDI 1.1旨在解决这些瑕疵，同时标准化社区所开发的大多数流行的扩展。我们并不打算增加任何新的功能。其中的一些亮点列举如下：

• 对拦截器与装饰器的全局排序，还支持以全局方式实现组件的替换。
• 用于管理内建上下文的API，这样就可以在JSF之外使用内建的对话上下文实现。
• 支持在Java EE容器外启动的嵌入式模式。
• 构造方法级别的Bean声明。
• 静态注入。
• 引入了来自于Seam Solder的@Unwraps。
• 对Portable Extensions SPI诸多细小的增强。
• 客户端控制的上下文。
• 在Java EE平台下对CDI更好的支持。
• 针对Servlet事件发送CDI事件。
• 应用生命周期事件。

InfoQ：去年年底在Twitter和各大博客（比如这个）上有很多关于Weld（JSR-299，CDI参考实现）中的内存与性能问题的讨论。我知道那个时候你正在改进这些问题。现在的进展如何了？

我们已经取得了重大的进展！现在大家已经能够看到在内存使用、启动时间以及运行期性能上的改进了。度量结果表明部署时如果只有少量几个bean，那么启动时间将提高两倍，如果bean的数量非常多，那么启动时间就会提升10倍以上。无论部署时有多少个bean，内存使用都会提升了4倍。运行期性能的改进提升了40%，我们欣喜地看到Weld与其他CDI实现和DI领域的其他解决方案相比，要么不分伯仲，要么更高一筹。

这些改进都会融入到Weld 1.1.0中（包含在JBoss AS 6和GlassFish 3.1当中），我们计划对Weld 1.2（将包含在JBoss AS 7中）进行更多的改进，特别是在内存使用上。对于Weld来说，最终的目标是让每个bean占据1k内存空间。

InfoQ：据我了解，很多团队在迁移到JSF 2之前都在等待着Seam 3和RichFaces 4。我相信RichFaces 4会在下个月发布，但你知道Seam 3何时会发布么？在这期间，会向Seam 2中增加JSF 2/Facelets 2支持么？

我们同样计划在3月份完成Seam 3的开发工作。现在已经发布了 Beta 1版，其中包含了Seam 3的所有模块，列举如下：

• Seam Security，除了Java EE规范所提供的那些特性外，还增加了增强的认证与授权支持。此外，还增加了联合身份特性，可以实现与OpenID和SAML的无缝集成。
• XML Configuration，可以通过XML配置基于CDI的应用。
• Seam Faces，增加到了JSF 2的特性当中，向其他Seam模块提供了重要的JSF集成点。
• Seam Catch，向开发者提供了统一、健壮的异常处理流程。
• Seam Wicket，使用Apache Wicket实现CDI组件模型与其他Seam模块的集成。
• Seam International，为基于CDI的应用提供了本地化服务。
• Seam Remoting，这是一个基于Ajax的框架，用于从网页中直接调用CDI Bean。

我们刚刚发布了Seam 2.2.1，其主要目标是对运行JSF 1.2的JBoss AS 6上的Seam 2提供良好的支持。我们一直在讨论是为Seam 2增加JSF 2（这会延缓Seam 3的开发工作）支持还是坚持目前的JSF 1.2支持。目前，我们计划发布Seam 2.3，它会对JSF 2提供完全的支持。同时，各大社区的成员也都站了出来，创建了Seam 2.2的分支，该分支将与JSF 2协同工作，比如这个地址 https://github.com/heyoulin/seam2jsf2，我们对社区成员的努力表示由衷的谢意！

InfoQ：RichFaces 4有哪些新特性呢？

RichFaces 4是面向JSF 2中新的Ajax特性的一个版本。其主要特性列举如下：

• 完整的JSF 2.0支持与扩展。
• 真正与Bean Validation（JSR-303）或标准的JSF验证器集成的客户端验证。
• 大量经过重新设计以及优化的组件。
• 统一的dataTable设计提供了良好的灵活性和易用性。
• 支持Google App Engine。
• 高级的Ajax请求队列支持。
• 动态资源支持。

InfoQ：我想问的一个问题是：JBoss AS 6只通过了Java EE 6 Web Profile认证，为何不支持整个Java EE 6规范呢？这个举动对于EE 6市场意味着什么呢？

AS 6的目标旨在尽快通过Web Profile TCK，这样我们就能尽快使用完整的JBoss运行时进行一些新的、激动人心的技术（如CDI）开发了。由于AS 6构建在AS 5（这是完整的EE 5实现）代码基之上，因此AS 6还会包含额外的JSR。

人们不应该过于强调这一点——我们并不会背离EE，只不过想加速脚步，因为我们看到Java EE 6有很多激动人心的东西——搞定JBoss Web Profile服务器是个重要的里程碑，你会看到我们会基于此实现完整的EE 6认证，以此作为AS 7的社区路线图，然后会在今年底发布全面支持Red Hat产品的服务器。

查看英文原文：Pete Muir Discusses Seam 3, RichFaces 4, and His Move to Infinispan