If there's one thing that we really want to get right as Web Beans goes from Public Draft to Proposed Final draft, it's integration with the Java EE platform. Up to this point, most of the work we've been doing as an EG was focused on nailing down the programming model, the semantics of the Web Beans services, and the behavior of the Web Bean manager. We've been writing the spec to assume that Web Beans implementations should be pluggable between different Java EE containers, because this is a direction that a lot of folks in the Java EE community believe that the EE platform should move in, and because we would like Web Beans to help show the way for other specifications such as EJB, JTA and perhaps even Servlets (note that JPA and JSF already support this).
Since the release of the Public Draft, our main focus has shifted to the integration problem. Web Beans generated a bunch of controversy when the draft was circulated to the EE platform expert group and proposed by Sun for inclusion in the Web Profile. That's not surprising - Web Beans solves some very important problems that lots of people have strong opinions on. I've also had a number of more technical discussions with the EE and EJB spec leads and with the EJB expert group. A number of concerns have emerged, which we're now attempting to address.
Let me share my take on these issues, and some directions we might pursue. But first...
...some history
In the days of EJB 1.x and 2.x, a major complaint against EJB was that the programming model was too restrictive. The specification imposed many annoying, distracting and unnecessary requirements upon developers. EJB 3.0 changed all that. Gone were the most of these annoying coding restrictions. In place of verbose XML deployment descriptors, EJB 3.0 was the first Java component model to be based around the use of annotations. In place of JNDI lookups was a simple dependency injection model, which ended up being generalized at the EE 5 platform level. I was a member of the EJB 3.0 expert group, and remain proud of what we accomplished.
However, the Java EE 5 dependency injection model was criticized from the outset. Many folks, including Rod Johnson of SpringSource, argued that the lack of support for injection of Java classes which were not EJBs was a fatal flaw. (At the time I did not agree, but I've changed my mind since.) On the other hand, I was dissatisfied with the lack of a contextual lifecycle model - though, in fairness, some other DI solutions of the time, including Spring, also lacked a contextual model. I was also unhappy with the mismatch between the JSF (XML-based, contextual) dependency injection model and the platform-level (annotation-based, non-contextual) model. This mismatch made it difficult to integrate EJB components with JSF.
Most of the changes introduced in EJB 3.0 and JPA 1.0 have stood the test of time remarkably well. The EE 5 dependency injection model has not. Contextual lifecycle management is now a standard feature of dependency injection solutions including Seam, Spring and Guice. Most importantly, Guice showed us the folly of using string-based names to identify implementations of an API. And Seam showed how to simplify application development by unifying dependency management in the web and EJB tiers.
Web Beans was initiated to address these problems. The original JSR proposal complained that:
-
EJB components are not aware of the web-tier request, session and application contexts and do not have access to state associated with those contexts. Nor may the lifecycle of a stateful EJB component be scoped to a web-tier context.
-
The JSF component model is not consistent with Java EE ... dependency injection...
The JSR promised to unif[y] the two component models and enabl[e] a considerable simplification to the programming model
.
A new dependency injection model was needed: a model that provided contextual lifecycle management to transactional EE components.
Is Web Beans a component model?
In the Web Beans Early Draft, we characterized Web Beans as a component model. The specification defined two things:
- a set of restrictions that a Java class or EJB session bean must satisfy in order to be a Web Bean (principally, but not only, that it must explicitly specify @Component or another deployment type), and
- the services that would then be available to the Web Bean.
I viewed this as a unifying component model: a unification that would solve a major problem that has existed since J2EE - that the Java EE web tier has a completely different component model (actually, component models plural) to the transactional tier. It promised to tear down the wall
between the two tiers, allowing transactional components to be aware of state related to the Web request. It promised a truly uniform programming model for components concerned with orchestration of the Web request, and components concerned with managing data access (at least when JSF was used).
This turned out to be the wrong approach. The strong feedback from the EE group was that Web Beans shouldn't define a new component model. The feedback from the EE spec leads at Sun was that the services defined by Web Beans should be available to all kinds of Java EE components - not just those which satisfied our definition of a Web Bean
.
At Sun's urging, we made two changes to the specification. The first was primarily a language change. We repositioned Web Beans as a set of services, provided by a Manager analogous to the JTA TransactionManager, instead of a component model
with a Container. But this also implied two more technical changes:
- we dramatically loosened the restrictions on what objects are Web Beans, so that every EJB session bean and every JavaBean is now a Web Bean, without any requirement for explicit declaration, and
- we provided a set of SPIs to allow objects which are not JavaBeans or EJB session beans to take advantage of the services provided by the Web Bean manager.
In particular, we provided injection into Servlets and message-driven beans (objects which by nature are not injectable) and an SPI that allowed other EE technologies and thirdparty frameworks to offer their components up for injection by Web Beans, and take advantage of the Web Beans services.
This was certainly the right thing to do, and the Web Beans specification is now more powerful and less intrusive. It still promises a more uniform programming model, but a side effect of these changes was that the model became even more generally useful, and even less specific to JSF and EJB. This isn't the first time I've seen something like that happen: the EJB 3.0 expert group also produced some technology (JPA, EE 5 dependency injection) that ended up being applied more generally than was originally envisaged.
Is Web Beans still a component model?
Unfortunately, some people are still not satisfied. A number of members of the platform expert group believe that the notion of a simple Web Bean still specifies a new component model. So what, exactly, is a simple Web Bean, and why do we need them?
A simple Web Bean is nothing new. It's just a Java class. You've already written hundreds or even thousands of simple Web Beans. Every JavaBean is a simple Web Bean. All we're trying to do is allow objects which were not specifically written as EJBs to be injectable and take advantage of the Web Beans services.
A simple Web Bean has the following advantages
over an EJB session bean:
- it does not need to be explicitly declared as an EJB using a component-defining annotation or XML
- its interfaces do not need to be explicitly declared using @Local or @LocalBean
- it can be final, or have final methods
- it has a more
natural
lifecycle and concurrency model - the normal lifecycle for a Java class, instead of theenhanced
lifecycle/concurrency semantics defined by EJB - if it's a stateful object, it does not require a @Remove method
- it can take advantage of constructor injection
You can use preexisting JavaBeans and many other Java classes as simple Web Beans. As a side effect, simple Web Beans reduce the mental gap
for new Java EE users who might be, initially, scared off by the unfamiliar EJB semantics - and the rather painful requirements to explicitly designate business interfaces and add empty @Remove methods - and let these new users get started with container-managed objects more easily.
On the other hand, unlike session beans, simple Web Beans, as currently defined:
- don't have method-level transaction demarcation or security
- can't have timeouts or asynchronous methods
- can't have remote interfaces or be web service endpoints
- don't have container-managed concurrency (locks)
- don't support instance-level passivation or pooling
Therefore, in my opinion (an opinion shared the current and previous EJB spec leads), simple Web Beans don't compete with EJB as a solution for the transactional tier of the application. In fact, simple Web Beans aren't really anything new - Java EE developers already use EJBs and JavaBeans side by side. Web Beans just makes their life a little easier.
But some folks disagree. For example, one expert is worried that by providing something called a simple
Web Bean, we're encouraging people to use them instead of EJB. The risk is that developers will be guided away from the use of non-simple
EJBs. This has become a real sticking point in the EE group, and threatens to derail the whole Web Beans effort.
Of course, we're trying to work through this. One possibility is that we could move the definition of a simple Web Bean to the EJB specification, as a new EJB component type. Another possibility is to simply drop simple Web Beans from the specification, and ask everyone to write all their objects as EJBs.
Personally, I can't imagine releasing Java EE 6 with a dependency injection solution that doesn't support JavaBeans. All the other solutions in the space support both JavaBeans and EJB. EE 5 missed this boat - I don't want EE 6 to repeat the mistake. And I think that this is a case where users want to make the decision about when to use EJB. They don't want us to force a decision down their throats.
Injection of other EE resource types
A second issue raised by the EE experts is that the Web Beans specification does not currently define support for injection of all the various Java EE resource types. Specifically, Web Beans does not explicitly define injection of JDBC datasources, connections, web service endpoints, remote EJBs or persistence contexts. Of course, you can still use the existing Java EE 5 @Resource and @PersistenceContext annotations to inject Java EE resources, but then you'll miss out on the advantages of the more flexible and more typesafe model defined by Web Beans.
Well, the true situation is that injection of EE resources (or anything else at all) is already supported by Web Beans, assuming that the Java EE container calls an appropriate Web Beans SPI at initialization time. But neither the EE specification nor the Web Beans specification requires it to do so. So this is an issue that should be easy to fix.
Pluggability
We put a fair amount of effort into defining the interaction between the EE container and the Web Bean manager, for the purpose of supporting pluggable Web Bean managers. However, nothing that is currently defined imposes any new requirement upon the EE container. Unfortunately, at this point, there remain a number of open issues in the specification that can only be resolved by either:
- dropping the requirement for pluggability or
- imposing new requirements upon the EE container.
(Search for Open issue
in the Public Draft if you're interested in knowing exactly what new requirements would be imposed upon the Java EE container.)
Either of these paths is technically feasible, but one of them is a lot more work and involves a lot more coordination between the various expert groups, some of which are already struggling to meet tight deadlines. If Web Beans is required in Java EE 6, it's not clear that pluggability is truly of great value to users. Does anyone really need to switch out their Web Bean manager?
I'd love to hear from the community whether pluggability is really worth pursuing.
Packages and naming
Quite a number of people hate the name Web Beans
, which they see as obscuring the generality of the model we've defined. I view the name as more of a catchy brand than a definition of what Web Beans does. Think of Microsoft and .net
. I don't mind changing the name, but nobody has yet suggested a great alternative. For one thing, I hate acronyms, and something descriptive like Java Dependency Injection wouldn't really capture all that Web Beans does.
Independently of this objection, quite a number of people think that it would be better to package our annotations by concern rather than putting them all in the package javax.webbeans. For example, the following package layout might make better sense:
- javax.dependency - DI-related annotations: binding types, deployment types, @Initializer, @Produces, etc.
- javax.contexts - scope-related annotations, Context interface
- javax.interceptor (which already exists) - interceptor and decorator related annotations
- javax.events - @Observes, event bus interfaces
I see repackaging as a great idea.
The good news
The good news is that there's very little debate about the actual technical details of the (Guice and Seam inspired) dependency injection model in Web Beans. The feedback I'm getting from spec reviewers is uniformly positive. This gives me a lot of confidence that the more political
issues are also solvable.
What do you think?
The issues I've discussed in this post are important to all members of the Java EE community and to the future direction of the Java EE platform. I don't believe that we should be making these decisions behind closed doors
, without the involvement of users. Please speak up and let us know what you want us to do. And please take the time to learn more about Web Beans.
Sounds like some are worried that they will loose business when there is a less heavy weight and standardized alternative which doesn't require a full blown app server.
I'm all for simple Web Beans! Being able to use Java Beans in Seam is one of the reasons I like it so much, just dead simple to use.
I'm hoping that a simplified will make Java EE a bit more of a technology for the masses.
The need for a full-blown app server, and the is already resolved by the EJB 3.1 specification, via EJB Lite and embedded EJB Lite, which nobody is objecting to, so I don't see that as the motivation.
The purpose of simple Web Beans is not to replace EJB, but rather to provide a solution for problems that EJB does not currently solve.
That's certainly the goal of Web Beans :-)
When I first heard about EJB 3.1 being available in the servlet container, Java SE (unit tests), etc., I was excited. But, it was still missing powerful DI capabilities. Then I learned about WebBeans and was disappointed that it was being done as a separate component model than EJBs. I know Stateless and Stateful EJBs have a number of restrictions but they can still take advantage of the new DI features. A new type of EJB could be created (currently known as Simple WebBean) that doesn't have any of the usual EJB restrictions. It wouldn't have transactions enabled by default, wouldn't do thread pooling by default, etc. If you did this then it would feel like EJB is a full featured component model (like Spring) instead of two component models that need each other. I would not object to merging the two.
WebBeans is a spec, not an implementation, so doesn't that mean others can already create their own implementations like Hibernate did with JPA? Well, JPA does have a way for you to specify who the provider is so that is probably what you are talking about. For me this is not important because I'll just use the RI. I imagine SpringSource will need to create an implementation of WebBeans for their application platform, based on Spring framework.
I never thought Web Beans was a perfect name because they aren't just for web, and it would be great to use them in Java SE too. So, I like the re-packaging idea.
Web Beans is not, and has never been a separate component model to EJB. Even when we were characterizing Web Beans as a component model, it was a component model that encompassed EJB. Web Beans was always meant, primarily, as a great dependency injection model for EJB. Anything else Web Beans does is a bonus.
This is certainly a possibility we are pursuing. However, it's unclear whether this improves EJB (by making it more flexible and more general) or actually damages EJB (by losing focus, and confusing the semantics of EJB with defaults that depend upon the component type).
Exactly. The JPA and EJB specifications define the interaction between the JPA provider and the Java EE container, just like the Web Beans specification currently tries to define the interaction between the Web Bean manager and the EE container.
And you're sure you wouldn't want the flexibility to be able to use the Apache implementation of Web Beans in JBoss?
Yes, this appears to be the developing consensus.
I think that there should be pluggability, even if that would mean a delay. Never mind the fact that 99.5% of people will never swap providers (although you can do this with JPA, you seldom hear stories of people in the middle of a large project), there will always be those crying if they can't, hindering acceptance. Pluggability is also a huge selling argument when trying to sell open source as alternative to some middle management ;-)
Repackaging has the most utility. Stateless services might use only DI and interceptors. BPM/Workflow might use only events etc. I'm not using session beans or JSF but all 4 packages, if they were loosely coupled, look like necessary additions to Java.
I'm a paying GlassFish customer and I've never had a good reason to swap out the JSF RI for MyFaces. I've read that they have added proprietary features, which I try to avoid unless absolutely necessary. I've only ever replaced the JPA RI in GlassFish with Hibernate JPA once, when I needed features not in the RI. I love how my apps mostly don't need to include dependencies because everything they need is built in, pre-integrated and pre-configured. If I need to start adding different implementations into my apps, then that opens the door for me to give more consideration to non Java EE standards frameworks and libraries too.
So, as long as WebBeans 1.0 doesn't have any serious omissions (such as criteria API in JPA 1.0) then I can't see myself changing the provider. The other important thing is that if I want to use Seam features like security, email, pdf, etc., then adding these features to my app should not mean replacing core WebBeans RI with the same thing in my .war file. The Seam additional functionality should be separated into different .jar files.
For example:
void put(@Endoded @HttpParam("foo") String str);
@HttpParam triggers an injector. The @HttpParam injector looks at the other annotations applied to the "str" parameter and finds @Encoded and so injects an URL encoded string into the "str" parameter.
Is there a way to describe this in Web Beans?
It's not quite clear to me that javax.dependency and javax.contexts would truly be loosely coupled. The other two probably are.
I'm not exactly sure of the semantics there so it's kinda hard to answer. I'm going to chat with the JAX-RS EG leads this week, maybe you should be on the call, Bill...
In my opinion the separation between EJBs and Web Beans is artificial and hurts more than it helps. As a developer writing a new component I don't want to think but I do think , and in this line of thought a service can be transaction management, dependency injection, resource injection, AOP, etc... so why split the services into the two groups and not have a single container to provide all the services and have the services provided to all the classes according to annotations/XML which defines functionality (like @Transactional and @Remove) and not component types (like @EJB and @Component)?
Thanks for this, it's really interesting stuff.
+1 for pluggability, per Nicklas's argument. Plus you get geek points for your injection mechanism.
+1 also for the repackaging; looks to me like it was the convention with EJB3/JPA, anyway
One thing that always scares me is Portlets. Is there any talk of the touchpoints there?
But I'm not sure exactly what exists. A is by definition just something that can be injected. All EJBs are Web Beans. All JavaBeans are Web Beans. Where's the separation?
Well the reason would be to be able to choose the Quality of Implementation at the service level, instead of at the level. Just like you can today choose your JMS, JDBC or JPA provider on the basis of quality considerations, wouldn't it be nice to also be able to choose your transaction manager and dependency injection service independently of the application server?
Really, I'm just asking - I don't personally have a super-strong opinion on this....
The spec does not currently define any standard contexts in a portlet environment. That's something we should think about, thanks for that.
Note that since portlets are not a Java EE platform technology, standardized portlet support might have to wait for a future release of Web Beans.
OK, but this would not just be a delay for JSR-299, it would mean delaying the whole EE6 platform release (which includes stuff like EJB 3.1, JSF 2.0 and JAX-RS). Are you really sure that's worthwhile?
Yes, you can do that.
The doubt I have is whether we really have an appropriate mechanism for handling something like @HeaderParam("name"), where "name" is something that is essentially unbounded. It seems like you would need a producer method that can get access to metadata about the injection point. Interestingly enough this is the same thing you would need if you wanted to model logging as web beans injection, so I think this is a problem worth addressing. I guess it's as simple as passing an object representing the method/constructor parameter or Field to the producer method. I'm not quite sure what is exactly the right way to define that but it sounds doable.
Oi Gavin, In this topic became clearer the idea of the service's Web Bean manager. I'm doing my thesis for graduation about JSR 299, JBoss Seam and Java EE. I think, it is a very interesting proposal of of components, hopefully become a standard broadcast.
Other than non-standard proprietary APIs, why would I choose one vendor's implementation of WebBeans over another? I figure the only reason for multiple implementations will be some companies refusing to use the RI, like SpringSource.
Also I think if pluggabiblity is going to delay all of Java EE 6, it should definitely wait for WebBeans 1.1 or whatever the next version is. Hopefully we won't have to wait three years (Java EE 7) to see that.
The separation is in having these two separate concepts. I think the concept of EJB should be dropped in favor of Web Beans with the desired functionality. For example, if you want to make a method transactional why should you have to make the component an EJB when it can be a simple Web Bean with a @Transactional annotation?
I think the solution in this case is OSGi. Apparently the next versions of all application servers will support it and I think that all the JEE 6 functionality should be contained in OSGi bundles and you should be able to replace them with OSGi bundles of different implementations (and even not load bundles that you don't use). As I understand this is what happens in Glassfish 3 and SpringSource dm Server.
There's a hidden assumption there that is onerous. It's not. In a great many cases, all you need to do is throw a single annotation (@Stateless/@Stateful/@Singleton/@MessageDriven) on your class. Remember that EJB 3.1 drops the requirement for a local interface.
And then, look what you get for your effort:
Sure, some of this functionality could theoretically be remodeled as a set of services that are orthogonal to the EJB lifecycle model (transactions, security, probably concurrency). But from a practical point of view the actual benefits of doing this would be extremely marginal - and the costs in terms of politics and spec writing and re-educating users would be much higher. So neither I nor anyone else wants to go and start rebuilding the functionality that already exists in EJB and works just beautifully.
If I was writing Java EE from scratch today, would I design @TransactionAttribute and @RolesAllowed to be totally orthogonal services that applied to any EE component? Sure. Do we have a truly pressing need to rework this now, in Java EE6? I don't think so.
But, more to the point, practically and politically nobody who is represented in the EE group wants anybody to go replacing or competing with EJB. If Web Beans compete with EJBs, it will be Web Beans that gets cut from the EE platform, not EJB. Trust me on this.
Despite a whole lot of hype about OSGi, no, unfortunately OSGi doesn't solve this problem. There is simply no well-defined contract between the appserver and JTA, between the appserver and EJB, etc. It doesn't help me to package up my JTA transaction manager in a nice OSGi bundle if the appserver simply doesn't know anything about my proprietary bootstrap API.
Honestly, I can't think of a great reason, which is why I'm prepared to drop it, if necessary.
The phrase only really needs to exist in the spec because of the pluggability requirement. The spec defines a contract between the Web Bean Manager and the EE container. Really, a might be:
But if we dropped the pluggability requirement, we could probably write the spec to just say , meaning either the full EE container, or the EJB Lite container.
I guess I imagine that most people will get their Web Beans implementation as integrated functionality of the EE platform, or of the embedded EJB Lite container. The question is whether we should do the pluggability stuff anyway.
Nice, good luck!
The reasons I like JPA pluggability is:
1) You can use the implementation with less bugs in your favorite Container 2) #1 Gives more competition since it is easy to do 3) Allow me to test the functionality of multiple providers without changing everything else (this one might be more bound to being able to use it standalone) 4) Get access to provider specific features
#1 & #2 is my main reason pluggability would be a good thing. #3 is probably more dominant in JPA than for WebBeans - but you never know what the future will bring of innovative (bad or good) addons ;)
Should it hold up WebBeans/JEE 6 ? No, having WebBeans released with JEE 6 is more important than pluggability.
--max
Do you have any rough estimate on how long the delay would be (and where the EE6-platform is currently in relation to current schedules)?
Personally I could skip the pluggability requirement but I know there are forces that will completely ignore the technical and practical merits of the Web Beans and focus on any negatives they can get their hands on :-/
Both are pretty much un-answerable questions.
My vote is for - Simple Web Bean. - Drop Pluggability
It all goes back to usability. If Web Bean is for the mass as you intended, just keep this in mind: if it makes it easier for developer to use/adopt, it should be in; otherwise, drop it or move it out for next release.
As I remembered the first excited days when EJB 1 comes out, my enthusiastic for it dropped down more and more when I learned about the complexity and bloated things involved. I only get excited again to use EJB because of Seam and EJB 3.0 annotations. Seam makes development fun again. It needs no standard to win over the heart of developers. Managers need not be convinced to adopt the framework when they can see us whipped out Seam application as quickly as any RoR app. Everything is in the bottom line for business these days. If developers adopt Web Bean in force, it should and will become a good standard. Few people do care about some big-shot-defined standards that nobody uses.
Drop that pluggability, Gavin, and let Web Bean see the sun light as soon as possible!
I dont think that the first possibility is really that bad, why not add it to the EJB spec?
Personally I think the issues WebBeans is it trying to solve should be solved in EE 6, but are developers really waiting for yet another specification?
It´s not onerous in terms of programming effort, but I not sure if that´s the case in terms of system resources.
When I started using Seam, all my Seam components were EJBs. But then I heard some people saying that, at least in a 3 layered application, I would end up with a lot of session beans, consuming much more server resources, and it would be better if I did not make use of EJBs with Seam.
I don´t know if that´s true. But if it does make sense for Seam, wouldn´t it make sense for WebBeans?
If it's onerous in terms of system resources, there's something wrong with your appserver.
Don't believe anything people tell you about performance without verifying first, with your own performance tests! I've not noticed session beans being very significant in terms of performance, at least not in JBoss.
The danger is that it involves a lot of special casing for this new component type: lots of stuff like . This not only makes the spec harder to write and read, but it also makes EJB more confusing for users.
It may be worth doing this anyway, but there is a cost.
Exactly. I wish it weren't a spec and really got embraced (or not).
I have some faith we can get this right, though. You've already done wonders for aligning other Java EE misguided efforts. :)
Yes...web beans will make the JEE much easier. I am looking forward for the JEE 6 with lots of new features and web beans.