Web Beans (JSR-299): Q&A with Specification Lead Gavin King
Web Beans (JSR-299): Q&A with Specification Lead Gavin King
Posted by Charles Humble on Jan 07, 2009 04:00 AM
The Web Beans page on the Seam website describes Web Beans as:
"...a set of services for the Java EE environment that makes applications much easier to develop. Web Beans layers an enhanced lifecycle and interaction model over existing Java component types including JavaBeans and Enterprise Java Beans. As a complement to the traditional Java EE programming model, the Web Beans services provide:
- an improved lifecycle for stateful components, bound to well-defined contexts,
- a typesafe approach to dependency injection,
- interaction via an event notification facility, and
- a better approach to binding interceptors to components, along with a new kind of interceptor, called a decorator, that is more appropriate for use in solving business problems."
Currently in public draft review, the wide reaching potential impact of Web Beans continues to cause concern amongst some members of the JEE community, and specification lead Gavin King has announced a decision to extend the review period into February 2009 to try and address some of these worries. InfoQ talked to King to find out more:
InfoQ: Given that both Spring and Web Beans offer a dependency injection framework for Java EE, I was interested to know what you see as the principal advantages that Web Beans has over Spring. Has anyone from SpringSource been involved with the expert group?
The model in Web Beans is influenced by Spring, Guice and Seam. However, the most direct influences are the contextual state management model of Seam and the type safe dependency injection model of Guice. Both Seam and Guice have also influenced the evolution of Spring, which recently added some limited support for contextual beans and for Guice-style binding types. However, Web Beans had the advantage of starting from a clean slate and so the end result is cleaner, more elegant and more type safe overall. Web Beans also introduces a number of innovative new notions, including decorators, stereotypes, deployment types, type safe event/observer bindings and interceptor binding annotations, that don't exist in the other solutions. The end result is much less XML and much more type safety.
SpringSource is not currently represented on the JSR-299 EG.
InfoQ: What distinguishes a decorator from an interceptor?
Every problem you can solve with a decorator you can probably solve with an interceptor but interceptors are a very un-typesafe, unnatural way of handling business logic. A decorator provides a way of doing interception that is aware of the semantics of the method that is being invoked and can be applied to a specific Java type. In other words, interceptors allow technical concerns such as transaction management and security to be decoupled from business logic, whilst decorators provide similar compartmentalisation for business concerns.
InfoQ: Why does Web Beans need an event model?
The reason for this is that we want to promote a coding approach that is loosely coupled and strongly typed; that philosophy underpins everything in the spec. But beyond that we're also trying to write components that are both stateful and loosely coupled. Stateful components can be problematic in a web context because of managing cached state for example - many applications break when a rollback occurs because the state isn't tied to the transaction. These sorts of issues are very hard to test for because they generally only occur when an application is under heavy load. So the event model provides a way of handling these kinds of problems.
InfoQ: How does the Web Beans event model differ from the observer/observable pattern?
The Web Beans model differs from the Java observer/observable pattern in that the observer doesn't need to be aware of the observable since this sort of dependency isn't really practical in a Web Beans context. The Web Beans model also supports message selectors and event types - an event type is a little like a MOM topic and the message selectors are like binary types. You can therefore apply filtering at this level in a typesafe manner.
We're still working on some aspects of this - for instance an issue that IBM brought up is that the current draft doesn't supply any semantics for handling clusters, so the next draft will probably allow events to be sent to JMS topics or queues providing an elegant way of sending a Java object to a queue. See this blog entry for more information.
InfoQ: Web Beans is obviously closely associated with integrating JSF and EJB. What other use cases have you considered for integration?
Web Beans is a dependency injection framework. In a sense though dependency injection is not technically particularly interesting; really what DI frameworks do is offer a backbone for interactions between objects. The DI framework is a backbone not only for interactions between application components, but also for interactions between application components and infrastructure. Java EE lacks APIs for integrating third party frameworks into the environment, so today you need to layer some backbone such as Spring or Seam in to do it. So Web Beans is providing a standard way of doing this which is part of Java EE.
There are four really big use cases we're focusing on and I think these cover the majority of other cases. Firstly, web frameworks - it should be really easy to integrate Web Beans with another web framework and I believe it is. Then Business Process Management engines such as JBPM or Oracle's BPM - this motivates the use of a hierarchy management model. The third is that people using existing dependency injection frameworks be they Spring, Seam, Guice or some other DI mechanism need to be able to integrate their existing code with Web Beans, and the fourth is JAX-RS.
InfoQ: So how will Web Beans affect Seam 3?
The core engine of Seam 3 will be Web Beans. We'll then look to port the set of modules that integrate other technologies that we like such as JSF, JBPM, Hibernate, Drools, Groovy, Wicket and GWT, or that solve common concerns such as security, rendering PDF, email, Excel, RSS and so on, and port these to the Web Beans backbone. I'm still thinking about how we support existing code that uses the Seam proprietary Dependency Injection method but think this will be done either via an integration layer with Seam 2 or by re-implementing this API over Web Beans.
InfoQ: I couldn't see a way of dealing with remote EJBs? Is that the case? If so is this something you're planning to address?
Yes, one issue we need to work on for the revised Public Draft is providing Web Beans-style injection for all the existing Java EE resource types, including remote references to EJBs, which has been a common feature request.
InfoQ: A common comment about the JCP is that communication between expert groups is difficult. Given that Web Beans sits across a number of specifications including both JSF and EJB, as well as Servlets and common annotations, I was curious to know how much of a problem this has been for you and how you've been dealing with it.
It's been a real problem and one that we're still grappling with. I hate to say this, but the JCP is close to dysfunctional when it comes to solving issues that span multiple expert groups.
InfoQ: When the Web Beans spec was first announced there was a lot of discussion around how general purpose it would be and whether it should be part of the JEE spec or part of JSE 7 so it would be usable with Swing/JavaFX and other places where a DI framework could be useful. However the specification has a dependency on EJB (or at least EJB Lite) which seems to limit its wider applicability. Could you tell us a bit about your thinking on this and why the API hasn't been extended beyond its original remit?
Well I'm not sure that Web Beans would have been politically viable if it had appeared to offer an alternative to EJB but I don't believe this is a real limitation. What people are going to get for use in the SE environment is a product that provides the functionality of EJB Lite and Web Beans as an integrated package. To deliver Web Beans without EJB Lite just doesn't seem to make much sense to me, since users of such a crippled product would then have to build their own non-standard transaction management, persistence integration, etc. The footprint of the integrated product will in practice be smaller than something like Spring (but bigger than Guice), and will require a whole lot less configuration to use.
Of course, there is a certain element of the community who retains an irrational fear of anything with the letters E, J and B in it, but frankly these folks are just going to have to get over their psychological issues if they want to take advantage of Web Beans!
InfoQ: IBM publicly expressed some reservations about the JCP specification when the JSR was first raised:
"We are becoming concerned with the direction that JSR 299 seems likely to take in going beyond its stated charter of integrating JSF and EJB components and believe that continued efforts in this direction could warrant its removal from Java EE 6. We do not believe that our customers would find it easy to adopt a Java EE 6 platform that adds yet another component model definition."
How much impact have IBM's concerns had on the direction of the specification?
A number of JCP members, including IBM, criticized the Web Beans Early Draft on the basis that it was characterized as a new "component model". In the Public Draft we therefore re-characterized the functionality as a set of services that were offered to certain existing EE component types. This went part way to addressing these criticisms, however it apparently did not go quite far enough and we have therefore extended the Public Review period for 299 in order to make additional changes to the specification.
We've recently spent a bunch of time working with IBM and the other EE vendors to address their concerns. IBM has just joined the 299 expert group and is now contributing to the development of the revised Public Draft. There is now agreement among the major EE vendors that 299 should be included in the EE 6 platform once certain concerns have been addressed in the revised Public Draft due for publication in late January. The EE platform will finally have a standard, state-of-the-art dependency management solution.
More information on Web Beans is available from the reference guide. A first alpha build can also be downloaded from the Seam website.
转自：http://www.infoq.com/news/2009/01/webbeansqa
下面是中文译文：
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