ME!
链滴
作者 Charles Humble译者 张凯峰 发布于 2009年1月18日 上午3时24分
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平台最终将拥有一种标准的、先进的依赖管理方案。
转自：http://www.infoq.com/cn/news/2009/01/webbeansqa