Web Beans (JSR-299): Q&A with Specification Lead Gavin King
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.