Web Beans (JSR299): Q&A with Specification Lead Gavin King

• 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."

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.

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.

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.
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.
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. 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.

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.

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.

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!

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.

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

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

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

SpringSource目前并不在JSR-299专家组中。每一个你用装饰器可以解决的问题，你也可以用拦截器来解决，但拦截器是非类型安全的，处理业务逻辑的方式也不够自然。装饰器提供了能够感知到正在被调用的
方法的语义的拦截方式，而且能应用到特定的Java类型上。换句话说，拦截器从技术上解决了像把交易管理和安全从业务逻辑中解耦出来这样的问题，而装饰器
是在业务的角度提供了类似的解决方案。这是因为我们想促成一种松耦合和强类型的编码方法；这种理念是该规范的基础。但是除此之外，我们还试图编写出既有状态又松耦合的
组件。由于需要管理缓存着的状态，有状态的组件可能会在Web上下文中出现问题，比如，发生回滚时许多应用都会出问题，因为状态并没有和事务绑定起来。由
于这些类型的问题通常只发生在应用程序负载很重的情况下，所以往往非常难以测试。因此，事件模型提供了一种控制这些类型问题的方式。Web
Beans模型与Java的observer/observable模式的区别在于，观察者（observer）不需要知道被观察者，因为这类依赖在
Web Beans上下文中并不实用。Web
Beans模型还支持消息选择器及事件类型——一种事件类型有点像一个MOM主题，而消息选择器则像二进制类型。因此你可以以类型安全的方式在这一级别应
用过滤。

我们仍在做一些这方面的工作——例如，IBM提出的一个问题是当前草案中并没有支持处理集群（cluster）的语义，因此，下一个草案或许将允许事件被发送到JMS主题或队列上，以提供一种优雅的方式将Java对象发送到一个队列。请参见这个blog以获得更多信息。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。Seam 3 的核心引擎将是Web
Beans。然后我们将要移植全套模块，整合JSF、JBPM、Hibernate、Drools、Groovy、Wicket和GWT这样的技术，或者
解决常见的顾虑如安全、展现PDF、email、Excel、RSS等等，把他们都移植到Web
Beans中枢上。我还在考虑如何支持那些使用Seam专有依赖注入的现有代码，是通过一个Seam 2的集成层呢还是在Web
Beans上重新实现这一API。是的，我们修订公共草案需要解决的一个问题就是为所有现有Java EE资源类型提供Web Beans风格的注入，包括远程引用EJB，它已成为一个公共特性需求。这的确是一个问题，我们也正在解决。我不得不说，当JCP在解决跨多个专家组的问题时就会失控。我不确信如果Web
Beans提供一个EJB的替代品是否可行，但我认为这不是一个真正的限制。人们在SE环境中使用的是一种提供了EJB Lite和Web
Beans的集成功能包的产品。不使用EJB Lite而只用Web
Beans对我来说似乎没有意义，因为使用这样一个残缺产品的用户不得不构建自己的非标准的事务管理环境、持久化集成等等。集成后产品的规模实际上会比
Spring这样的东西更小（但是比Guice要大），而且不需要很多配置。

当然，在社区中也存在一种心态：非理性地恐惧任何与EJB有关的事情，不过坦率地说，如果想利用Web Beans，就不得不克服这种心理。很多JCP成员，包括IBM，批评Web
Beans早期草稿，认为它是一种新的“组件模型”。因此在公开草稿中，我们重新把其功能定位成一套用于现存EE组件类型的服务。这种做法部分解决了批评
问题，但是很明显不够，因此我们延长了299的公开审校时间，以对规范做更多修改。

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