Web Beans（JSR-299）：与规范领导者 Gavin King 的问答

Seam 站点上的 Web Beans 页面这样描述 Web Beans：

“……一套针对 Java EE 环境的服务，让应用程序开发起来更加简单。Web Beans 在已有的 Java 组件类型比如 JavaBeans 和企业 JavaBeans 之上，搭建了增强的生命周期和交互模型一层。作为针对传统 Java EE 编程模型的补充，Web Beans 服务提供了： - 改善有状态组件的生命周期，并绑定到定义良好的上下文上，

• 为依赖注入提供类型安全的方式，
• 通过事件通知机制进行交互，
• 一个把拦截器绑定到组件上更好的方法，并提供一个新型的拦截器，也叫装饰器（decorator），这对解决业务问题更加合适。”

目前在公开草稿预览阶段中，Web Beans 所会带来的广泛潜在的影响让 JEE 社区的成员们有所牵挂，而规范的领导者 Gavin King 也已经宣布将预览期限延至 2009 年，以此来解决人们所担心的一部分问题。InfoQ 为此采访了 King：

InfoQ：考虑到 Spring 和 Web Beans 都为 Java EE 提供了依赖注入框架，我很想知道你认为 Web Beans 比 Spring 最主要的优势在什么地方？有来自 SpringSource 的人加入到这个专家组中吗？

Web Beans 中的模型的确受到了 Spring、Guice 和 Seam 的影响。但是，最最直接的影响来自于 Seam 的上下文状态管理模型和 Guice 的类型安全依赖注入。Seam 和 Guice 也影响了 Spring 的发展，比如 Spring 最近就添加了针对上下文 bean 和 Guice 风格的绑定类型的支持。然而，Web Beans 具有“成分清白”的优势，所以最后的结果只会是更加干净，更加优雅，而且类型更加安全。Web Beans 还引入了许多创新性的思想，比如装饰器、原型、部署类型、类型安全事件 / 观察者绑定以及拦截器绑定注解，这些在其他解决方案里面是没有的。最终的结果就是更少的 XML 但更多的类型安全性。 SpringSource 目前并不在 JSR-299 专家组中。

InfoQ：装饰器和拦截器的区别是什么？

每一个你用装饰器可以解决的问题，你也可以用拦截器来解决，但拦截器是非类型安全的，处理业务逻辑的方式也不够自然。装饰器提供了能够感知到正在被调用的方法的语义的拦截方式，而且能应用到特定的 Java 类型上。换句话说，拦截器从技术上解决了像把交易管理和安全从业务逻辑中解耦出来这样的问题，而装饰器是在业务的角度提供了类似的解决方案。

InfoQ: 为什么 Web Beans 需要一个事件模型？

这是因为我们想促成一种松耦合和强类型的编码方法；这种理念是该规范的基础。但是除此之外，我们还试图编写出既有状态又松耦合的组件。由于需要管理缓存着的状态，有状态的组件可能会在 Web 上下文中出现问题，比如，发生回滚时许多应用都会出问题，因为状态并没有和事务绑定起来。由于这些类型的问题通常只发生在应用程序负载很重的情况下，所以往往非常难以测试。因此，事件模型提供了一种控制这些类型问题的方式。

InfoQ：Web Beans 的事件模型与 observer/observable 模式有什么区别？

Web Beans 模型与 Java 的 observer/observable 模式的区别在于，观察者（observer）不需要知道被观察者，因为这类依赖在 Web Beans 上下文中并不实用。Web Beans 模型还支持消息选择器及事件类型——一种事件类型有点像一个 MOM 主题，而消息选择器则像二进制类型。因此你可以以类型安全的方式在这一级别应用过滤。 我们仍在做一些这方面的工作——例如，IBM 提出的一个问题是当前草案中并没有支持处理集群（cluster）的语义，因此，下一个草案或许将允许事件被发送到 JMS 主题或队列上，以提供一种优雅的方式将 Java 对象发送到一个队列。请参见这个 blog 以获得更多信息。

InfoQ: 显然 Web Beans 与集成 JSF 和 EJB 极其相关。你们考虑过其它集成用例吗？

Web Beans 是一个依赖注入框架。虽然在某种意义上依赖注入在技术上并没什么特别的；实际上 DI 框架所做的就是为对象之间的交互提供一个中枢。DI 框架是这样一种中枢: 不仅可以供应用程序组件间交互使用，还可以供应用组件和基础设施间交互使用。Java EE 缺乏把第三方框架集成进其环境的 API，所以目前你需要加一层像 Spring 或 Seam 这样的中枢。而 Web Beans 则提供了一种标准的方式来做这件事，它是 Java EE 的一部分。 我们正集中于四个大的用例，我想它们覆盖到了多数用例。首当其冲的是 Web 框架——应该很容易把 Web Beans 与其它 Web 框架相集成，我相信这一点。其次是业务流程管理（Business Process Management）引擎，比如 JBPM 或 Oracle 的 BPM——它促使了分级管理模型的使用。第三是使用现有依赖注入框架（比如 Spring、Seam、Guice 或其他 DI 机制）的人们需要能够把他们的现有代码与 Web Beans 相集成，第四是 JAX-RS。

InfoQ：Web Beans 会对 Seam 3 产生什么影响？

Seam 3 的核心引擎将是 Web Beans。然后我们将要移植全套模块，整合 JSF、JBPM、Hibernate、Drools、Groovy、Wicket 和 GWT 这样的技术，或者解决常见的顾虑如安全、展现 PDF、email、Excel、RSS 等等，把他们都移植到 Web Beans 中枢上。我还在考虑如何支持那些使用 Seam 专有依赖注入的现有代码，是通过一个 Seam 2 的集成层呢还是在 Web Beans 上重新实现这一 API。

InfoQ：我没看到处理远程 EJB 的方法？有这样的用例吗？如果有，你们有什么样的计划？

是的，我们修订公共草案需要解决的一个问题就是为所有现有 Java EE 资源类型提供 Web Beans 风格的注入，包括远程引用 EJB，它已成为一个公共特性需求。

InfoQ：关于 JCP 的一个普遍看法是专家组之间的沟通非常困难。因为 Web Beans 跨越很多规范，包括 JSF 和 EJB，还有 Servlets 和通用注解，我非常想知道，对您来说这方面存在多大问题，您又是如何处理的。

这的确是一个问题，我们也正在解决。我不得不说，当 JCP 在解决跨多个专家组的问题时就会失控。

InfoQ：当 Web Beans 规范首次发布时，人们讨论了很多它的通用性和它是否应该成为 JEE 规范或者 JSE 7 的一部分，以使它能和 Swing/JavaFX 一块使用，以及用在其他 DI 框架可以使用的地方。但是，规范依赖 EJB（或者至少是 EJB Lite），这限制了它的广泛应用性。您能分享一下这方面的看法吗，还有为什么 API 至今还没有超过最初的职责范围？

我不确信如果 Web Beans 提供一个 EJB 的替代品是否可行，但我认为这不是一个真正的限制。人们在 SE 环境中使用的是一种提供了 EJB Lite 和 Web Beans 的集成功能包的产品。不使用 EJB Lite 而只用 Web Beans 对我来说似乎没有意义，因为使用这样一个残缺产品的用户不得不构建自己的非标准的事务管理环境、持久化集成等等。集成后产品的规模实际上会比 Spring 这样的东西更小（但是比 Guice 要大），而且不需要很多配置。 当然，在社区中也存在一种心态：非理性地恐惧任何与 EJB 有关的事情，不过坦率地说，如果想利用 Web Beans，就不得不克服这种心理。

InfoQ：当 JSR 首次提出时，IBM 公开表示了对 JCP 规范的顾虑：

“我们正在担心 JSR 299 的发展方向，似乎它已经超越了集成 JSF 和 EJB 组件的设想，我们认为继续下去会导致其偏离 Java EE 6。我们相信客户不会容易地采用 Java EE 6 平台，因为又添加了一个组件模型定义。”

IBM 的顾虑对规范的发展方向有多大影响？

很多 JCP 成员，包括 IBM，批评 Web Beans 早期草稿，认为它是一种新的“组件模型”。因此在公开草稿中，我们重新把其功能定位成一套用于现存 EE 组件类型的服务。这种做法部分解决了批评问题，但是很明显不够，因此我们延长了 299 的公开审校时间，以对规范做更多修改。 最近我们花费了很多时间与 IBM 和其他 EE 厂商一起工作以解决他们的顾虑。IBM 刚刚加入了 299 专家组，正在致力于修订公开草稿。目前在主要 EE 厂商已经达成了共识——299 应该包含在 EE 6 中，只要在一月底发布的修改公开草稿中消除了他们的顾虑。EE 平台最终将拥有一种标准的、先进的依赖管理方案。

更多 Web Beans 信息可查阅参考指南。首个alpha 版可以从 Seam 网站下载。

查看英文原文： Web Beans (JSR-299): Q&A with Specification Lead Gavin King