Help

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:

  1. 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
  2. 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:

  1. 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
  2. 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 the enhanced 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.

33 comments:
 
10. Nov 2008, 23:46 CET | Link
Mikael Andersson
... encouraging people to use them instead of EJB. The risk is that developers will be guided away from the use of "non-simple" EJBs.

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 component model will make Java EE a bit more of a technology for the masses.

 
11. Nov 2008, 00:17 CET | Link
Mikael Andersson wrote on Nov 10, 2008 17:46:
... encouraging people to use them instead of EJB. The risk is that developers will be guided away from the use of "non-simple" EJBs. 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.

The need for a full-blown app server, and the heavyweightness 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.

I'm hoping that a simplified component model will make Java EE a bit more of a technology for the masses.

That's certainly the goal of Web Beans :-)

 
11. Nov 2008, 07:48 CET | Link
Ryan de Laplante | ryan(AT)ijws.com
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.

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.

I'd love to hear from the community whether pluggability is really worth pursuing.

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 see repackaging as a great idea.

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.

 
11. Nov 2008, 10:34 CET | Link
Ryan de Laplante wrote on Nov 11, 2008 01:48:
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.

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.

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.

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

I'd love to hear from the community whether pluggability is really worth pursuing.
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.

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.

For me this is not important because I'll just use the RI.

And you're sure you wouldn't want the flexibility to be able to use the Apache implementation of Web Beans in JBoss?

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.

Yes, this appears to be the developing consensus.

 
11. Nov 2008, 13:50 CET | Link
Nicklas Karlsson | nickarls(AT)gmail.com

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 just dropping in another implementation in the middle of a large project), there will always be those crying foul 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 ;-)

 
11. Nov 2008, 14:19 CET | Link
Gary Struthers | gstruthers(AT)berkeley.edu

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.

 
11. Nov 2008, 20:54 CET | Link
Ryan de Laplante
For me this is not important because I'll just use the RI.
And you're sure you wouldn't want the flexibility to be able to use the Apache implementation of Web Beans in JBoss?

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.

11. Nov 2008, 21:07 CET | Link
JAX-RS is also an annotation injection domain-specific framework targetting HTTP. One thing I found very useful in JAX-RS is to provide annotation information about the artifact you are injecting into. In other words, if you are injecting into a parameter, it is useful for the "injection factory" to get access to *all* annotations of the parameter, and not just the annotation itself. I couldn't find anything in Web Beans that allowed you to get at this information at first glance.

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?
 
11. Nov 2008, 21:19 CET | Link
all 4 packages, if they were loosely coupled, look like necessary additions to Java.

It's not quite clear to me that javax.dependency and javax.contexts would truly be loosely coupled. The other two probably are.

12. Nov 2008, 00:37 CET | Link

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

12. Nov 2008, 04:06 CET | Link
Gabriel Axel

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 what is the definition of this component? but I do think what are the services that the container should provide this component, 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)?

 
12. Nov 2008, 04:22 CET | Link

Thanks for this, it's really interesting stuff.

+1 for pluggability, per Nicklas's argument. Plus you get geek points for injecting 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?

12. Nov 2008, 04:41 CET | Link
Gabriel Axel wrote on Nov 11, 2008 22:06:
In my opinion the separation between EJBs and Web Beans is artificial and hurts more than it helps.

But I'm not sure exactly what separation exists. A Web Bean is by definition just something that can be injected. All EJBs are Web Beans. All JavaBeans are Web Beans. Where's the separation?

As a developer writing a new component I don't want to think what is the definition of this component? but I do think what are the services that the container should provide this component, 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)?

Well the reason would be to be able to choose the Quality of Implementation at the service level, instead of at the single container 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....

 
12. Nov 2008, 04:44 CET | Link
One thing that always scares me is Portlets. Is there any talk of the touchpoints there?

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.

 
12. Nov 2008, 04:46 CET | Link
Nicklas Karlsson wrote on Nov 11, 2008 07:50:
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...

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?

12. Nov 2008, 05:50 CET | Link
This isn't a JAX-RS specific thing, I was just using it as an example to illustrate extra information I'd like to be available in @Produces methods (Sorry if the vocabulary isn't straight). In the example I gave, @HeaderParam would be a binding type. In the web beans @Produces method that generated the @HeaderParam value, I would want to know whether or not @Encoded was an additional annotation added and if so, encode the value injected. I guess the question is, can you use multiple annotations within Web Beans to decide what exactly gets injected into a param, field, or setter method? Because, IMO, @Encoded @HeaderParam("name") is much more elegant than @HeaderParam(value="name", encoded=true).
12. Nov 2008, 06:09 CET | Link

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.

 
12. Nov 2008, 09:27 CET | Link
Camila Regina Furlan | crfurlan(AT)gmail.com

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 integration of components, hopefully become a standard broadcast.

 
12. Nov 2008, 13:27 CET | Link
Ryan de Laplante

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.

12. Nov 2008, 13:27 CET | Link
Gabriel Axel
All EJBs are Web Beans. All JavaBeans are Web Beans. Where's the separation?

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?

wouldn't it be nice to also be able to choose your transaction manager and dependency injection service independently of the application server?

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.

12. Nov 2008, 14:03 CET | Link
Gabriel Axel wrote on Nov 12, 2008 07:27:
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

There's a hidden assumption there that mak[ing] a component an EJB 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:

  • non-broken concurrency management, via @Lock and friends, instead of via the totally broken and evil synchronized keyword
  • invocation via RMI, web service call, or message delivery
  • timers - including scheduled timers - and asynchronous methods
  • transaction and security demarcation at the method level
  • instance-level passivation for stateful session beans and instance-pooling for stateless session beans
  • dependency injection via Web Beans

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.

wouldn't it be nice to also be able to choose your transaction manager and dependency injection service independently of the application server?
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.

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.

 
12. Nov 2008, 14:04 CET | Link
Other than non-standard proprietary APIs, why would I choose one vendor's implementation of WebBeans over another?

Honestly, I can't think of a great reason, which is why I'm prepared to drop it, if necessary.

 
12. Nov 2008, 14:48 CET | Link
Camila Regina Furlan wrote on Nov 12, 2008 03:27:
In this topic became clearer the idea of the service's Web Bean manager.

The phrase Web Bean Manager 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 Web Bean manager might be:

  • the Java EE container, in the EE execution case
  • the embedded EJB Lite container, in the SE execution case
  • some pluggable third-party Web Beans implementation, in either case

But if we dropped the pluggability requirement, we could probably write the spec to just say container, 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.

I'm doing my thesis for graduation about JSR 299, JBoss Seam and Java EE.

Nice, good luck!

 
12. Nov 2008, 16:22 CET | Link

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

 
12. Nov 2008, 18:04 CET | Link
Nicklas Karlsson | nickarls(AT)gmail.com

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 :-/

 
12. Nov 2008, 22:51 CET | Link
Nicklas Karlsson wrote on Nov 12, 2008 12:04:
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)?

Both are pretty much un-answerable questions.

 
13. Nov 2008, 00:57 CET | Link

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!

 
13. Nov 2008, 02:52 CET | Link
stephanO
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.

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?

13. Nov 2008, 03:25 CET | Link
There's a hidden assumption there that making a component an EJB is onerous. It's not.

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?

13. Nov 2008, 04:07 CET | Link
Fabrício Lemos wrote on Nov 12, 2008 21:25:
There's a hidden assumption there that making a component an EJB is onerous. It's not. It´s not onerous in terms of programming effort, but I not sure if that´s the case in terms of system resources.

If it's onerous in terms of system resources, there's something wrong with your appserver.

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?

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.

 
13. Nov 2008, 04:11 CET | Link
stephanO wrote on Nov 12, 2008 20:52:
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. I dont think that the first possibility is really that bad, why not add it to the EJB spec?

The danger is that it involves a lot of special casing for this new component type: lots of stuff like the default transaction attribute is REQUIRED, except for simple beans. 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.

 
16. Nov 2008, 12:23 CET | Link
chris.wash@gmail.com

Exactly. I wish it weren't a niche, ghetto 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. :)

 
27. Nov 2008, 18:14 CET | Link

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.