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

Community

Java

Topics

JCP Standards ,

Web Frameworks

Tags

JBoss ,

Web Beans ,

Guice ,

JBoss Seam

The Web Beans page on the Seam website describes Web Beans as:

"...a set of services for the Java EE environment that makesapplications much easier to develop. Web Beans layers an enhancedlifecycle and interaction model over existing Java component typesincluding JavaBeans and Enterprise Java Beans. As a complement to thetraditional 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
• abetter approach to binding interceptors to components, along with a newkind of interceptor, called a decorator, that is more appropriate foruse in solving business problems."

Currently in public draft review, the wide reaching potential impactof Web Beans continues to cause concern amongst some members of the JEEcommunity, and specification lead Gavin King has announced a decisionto extend the review period into February 2009 to try and address someof these worries. InfoQ talked to King to find out more:

 

InfoQ: Given that both Spring and Web Beans offer a dependencyinjection framework for Java EE, I was interested to know what you seeas the principal advantages that Web Beans has over Spring. Has anyonefrom 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 managementmodel of Seam and the type safe dependency injection model of Guice.Both Seam and Guice have also influenced the evolution of Spring, whichrecently added some limited support for contextual beans and forGuice-style binding types. However, Web Beans had the advantage ofstarting from a clean slate and so the end result is cleaner, moreelegant and more type safe overall. Web Beans also introduces a numberof innovative new notions, including decorators, stereotypes,deployment types, type safe event/observer bindings and interceptorbinding annotations, that don't exist in the other solutions. The endresult 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 solvewith an interceptor but interceptors are a very un-typesafe, unnaturalway of handling business logic.  A decorator provides a way of doinginterception that is aware of the semantics of the method that is beinginvoked and can be applied to a specific Java type.  Inother words, interceptors allow technical concerns such as transactionmanagement and security to be decoupled from business logic, whilstdecorators provide similar compartmentalisation for business concerns.

InfoQ: Why does Web Beans need an event model?

The reason for this is that we want topromote a coding approach that is loosely coupled and strongly typed;that philosophy underpins everything in the spec.  But beyond thatwe're also trying to write components that are both stateful andloosely coupled.  Stateful components can be problematic in a webcontext because of managing cached state for example - manyapplications break when a rollback occurs because the state isn't tiedto the transaction.  These sorts of issues are very hard to test forbecause they generally only occur when an application is under heavyload.  So the event model provides a way of handling these kinds ofproblems.

InfoQ: How does the Web Beans event model differ from the observer/observable pattern?

The Web Beans model differs from the Javaobserver/observable pattern in that the observer doesn't need to beaware of the observable since this sort of dependency isn't reallypractical in a Web Beans context.  The Web Beans model also supportsmessage selectors and event types - an event type is a little like aMOM topic and the message selectors are like binary types.  You cantherefore apply filtering at this level in a typesafe manner.

We're still working on some aspects of this - for instance an issuethat IBM brought up is that the current draft doesn't supply anysemantics for handling clusters, so the next draft will probably allowevents to be sent to JMS topics or queues providing an elegant way ofsending a Java object to a queue.  See this blog entry for more information.

InfoQ:  Web Beans is obviously closely associatedwith integrating JSF and EJB.  What other use cases have you consideredfor integration?

Web Beans is a dependency injectionframework.  In a sense though dependency injection is not technicallyparticularly interesting; really what DI frameworks do is offer abackbone for interactions between objects.  The DI framework is abackbone not only for interactions between application components, butalso for interactions between application components andinfrastructure. Java EE lacks APIs for integrating third partyframeworks into the environment, so today you need to layer somebackbone such as Spring or Seam in to do it.  So Web Beans is providinga 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 thesecover the majority of other cases. Firstly, web frameworks - it shouldbe really easy to integrate Web Beans with another web framework and Ibelieve it is.  Then Business Process Management engines such as JBPMor Oracle's BPM - this motivates the use of a hierarchy managementmodel. The third is that people using existing dependency injectionframeworks be they Spring, Seam, Guice or some other DI mechanism needto be able to integrate their existing code with Web Beans, and thefourth is JAX-RS.

InfoQ: So how will Web Beans affect Seam 3?

The core engine of Seam 3 will be WebBeans.  We'll then look to port the set of modules that integrate othertechnologies 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 WebBeans backbone.  I'm still thinking about how we support existing codethat uses the Seam proprietary Dependency Injection method but thinkthis will be done either via an integration layer with Seam 2 or byre-implementing this API over Web Beans.

InfoQ: I couldn't see a way of dealing with remoteEJBs?  Is that the case?  If so is this something you're planning toaddress?

Yes, one issue we need to work on for the revisedPublic Draft is providing Web Beans-style injection for all theexisting Java EE resource types, including remote references to EJBs,which has been a common feature request.

InfoQ:  A common comment about the JCP is thatcommunication between expert groups is difficult. Given that Web Beanssits across a number of specifications including both JSF and EJB, aswell as Servlets and common annotations, I was curious to know how muchof 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 stillgrappling with. I hate to say this, but the JCP is close todysfunctional when it comes to solving issues that span multiple expertgroups.

InfoQ: When the Web Beans spec was first announcedthere was a lot of discussion around how general purpose it would beand whether it should be part of the JEE spec or part of JSE 7 so itwould be usable with Swing/JavaFX and other places where a DI frameworkcould 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 APIhasn't been extended beyond its original remit?

Well I'm not sure that Web Beans would have beenpolitically viable if it had appeared to offer an alternative to EJBbut I don't believe this is a real limitation. What people are going toget for use in the SE environment is a product that provides thefunctionality of EJB Lite and Web Beans as an integrated package. Todeliver Web Beans without EJB Lite just doesn't seem to make much senseto me, since users of such a crippled product would then have to buildtheir own non-standard transaction management, persistence integration,etc. The footprint of the integrated product will in practice besmaller than something like Spring (but bigger than Guice), and willrequire a whole lot less configuration to use.

Of course, there is a certain element of thecommunity who retains an irrational fear of anything with the lettersE, J and B in it, but frankly these folks are just going to have to getover their psychological issues if they want to take advantage of WebBeans!

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 likelyto take in going beyond its stated charter of integrating JSF and EJBcomponents and believe that continued efforts in this direction couldwarrant its removal from Java EE 6. We do not believe that ourcustomers would find it easy to adopt a Java EE 6 platform that addsyet 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, criticizedthe Web Beans Early Draft on the basis that it was characterized as anew "component model". In the Public Draft we thereforere-characterized the functionality as a set of services that wereoffered to certain existing EE component types. This went part way toaddressing these criticisms, however it apparently did not go quite farenough and we have therefore extended the Public Review period for 299in order to make additional changes to the specification.

We've recently spent a bunch of time working withIBM and the other EE vendors to address their concerns. IBM has justjoined the 299 expert group and is now contributing to the developmentof the revised Public Draft. There is now agreement among the major EEvendors that 299 should be included in the EE 6 platform once certainconcerns have been addressed in the revised Public Draft due forpublication in late January. The EE platform will finally have astandard, 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环境的服务，让应用程序开发起来更加简单。WebBeans在已有的Java组件类型比如JavaBeans和企业JavaBeans之上，搭建了增强的生命周期和交互模型一层。作为针对传统JavaEE编程模型的补充，Web Beans服务提供了：

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

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

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

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

SpringSource目前并不在JSR-299专家组中。

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

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

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

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

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

WebBeans模型与Java的observer/observable模式的区别在于，观察者（observer）不需要知道被观察者，因为这类依赖在Web Beans上下文中并不实用。WebBeans模型还支持消息选择器及事件类型——一种事件类型有点像一个MOM主题，而消息选择器则像二进制类型。因此你可以以类型安全的方式在这一级别应用过滤。

我们仍在做一些这方面的工作——例如，IBM提出的一个问题是当前草案中并没有支持处理集群（cluster）的语义，因此，下一个草案或许将允许事件被发送到JMS主题或队列上，以提供一种优雅的方式将Java对象发送到一个队列。请参见这个blog以获得更多信息。

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

WebBeans是一个依赖注入框架。虽然在某种意义上依赖注入在技术上并没什么特别的；实际上DI框架所做的就是为对象之间的交互提供一个中枢。DI框架是这样一种中枢:不仅可以供应用程序组件间交互使用，还可以供应用组件和基础设施间交互使用。JavaEE缺乏把第三方框架集成进其环境的API，所以目前你需要加一层像Spring或Seam这样的中枢。而WebBeans则提供了一种标准的方式来做这件事，它是Java EE的一部分。

我们正集中于四个大的用例，我想它们覆盖到了多数用例。首当其冲的是Web框架——应该很容易把WebBeans与其它Web框架相集成，我相信这一点。其次是业务流程管理（Business ProcessManagement）引擎，比如JBPM或Oracle的BPM——它促使了分级管理模型的使用。第三是使用现有依赖注入框架（比如Spring、Seam、Guice或其他DI机制）的人们需要能够把他们的现有代码与Web Beans相集成，第四是JAX-RS。

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

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

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

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

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

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

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

我不确信如果WebBeans提供一个EJB的替代品是否可行，但我认为这不是一个真正的限制。人们在SE环境中使用的是一种提供了EJB Lite和WebBeans的集成功能包的产品。不使用EJB Lite而只用WebBeans对我来说似乎没有意义，因为使用这样一个残缺产品的用户不得不构建自己的非标准的事务管理环境、持久化集成等等。集成后产品的规模实际上会比Spring这样的东西更小（但是比Guice要大），而且不需要很多配置。

当然，在社区中也存在一种心态：非理性地恐惧任何与EJB有关的事情，不过坦率地说，如果想利用Web Beans，就不得不克服这种心理。

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

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

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

很多JCP成员，包括IBM，批评WebBeans早期草稿，认为它是一种新的“组件模型”。因此在公开草稿中，我们重新把其功能定位成一套用于现存EE组件类型的服务。这种做法部分解决了批评问题，但是很明显不够，因此我们延长了299的公开审校时间，以对规范做更多修改。

最近我们花费了很多时间与IBM和其他EE厂商一起工作以解决他们的顾虑。IBM刚刚加入了299专家组，正在致力于修订公开草稿。目前在主要EE厂商已经达成了共识——299应该包含在EE6中，只要在一月底发布的修改公开草稿中消除了他们的顾虑。EE平台最终将拥有一种标准的、先进的依赖管理方案。

转自：http://www.infoq.com/cn/news/2009/01/webbeansqa