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