[webbeans-dev] Re: Terminology

Scott Ferguson ferg at caucho.com
Mon Dec 22 22:20:41 EST 2008 

On Dec 22, 2008, at 10:05 AM, Michael Keith wrote:

> Again, allow me to clarify some of the issues by starting a  
> discussion that is at the heart
> of this concern. Hopefully this will help people understand more  
> about where we are coming from.
>
> One of the biggest concerns around JSR 299 is that it promotes yet  
> another component
> model in addition to EJB. This is *highly* undesirable, in fact it  
> is a very dangerous
> thing for the platform. A lot of time and effort has been put into  
> making EJB a
> competitive component model so that it can stack up to any other  
> component model
> out there.

EJB is not a complete, modern component model.  I'm surprised anyone  
is arguing that it is.

A modern component model includes the following orthogonal capabilities:
   1) configuration, i.e. specializing components with site-specific  
values
   2) component location and binding (@BindingType, JNDI)
   3) lifecycle (servlet-style, component, pooled (stateless), proxy  
(stateful), etc)
   4) aspects (including @Transaction, @Asynchronous, as well as  
decorators)
   5) packaging

EJB only attempts to solve #3 and #4, and even #3 is incomplete for  
the most basic lifecycle model.  #5 for EJB is extremely limited.

WebBeans concentrates on #1, #2, #5 and implements #4 in a  
complementary fashion to EJB.  The lifecycle for WebBeans is a single,  
simple model, which is missing from EJB.

1) configuration - specializing the components with runtime values

    EJB - none, really.  There's still no effective mechanism to  
configure an individual bean.

    WebBeans - the cleanest and most powerful configuration yet  
designed.  (Including the potential to support any JavaEE spec as a  
bean configuration, if certain changes are made.)

2) component location and binding

   EJB - JNDI, plus the ad-hoc JNDI-based tags @EJB, @Resource, etc.   
This is obsolete by two generations.  Finally, in 3.1 EJB is adopting  
naming conventions.   Yay.

   WebBeans - delightful type-based @BindingType model, benefiting  
from years of DI experiments.

3) lifecycle (this is a partition of the different styles.  Note that  
there is no overlap between EJB and WebBeans)

   A) servlet-style, multithreaded, "pojo".  Basically, the only  
lifecycle WebBeans supports.  This model is extremely powerful and  
successful in high traffic sites, as any servlet demonstrates.
   B) EJB stateless: proxy, pooled instances.  Also servlet  
SingleThreadedModel.  (Note that SingleThreadedModel  has been  
deprecated for years.)
   C) EJB stateful: proxy, single instance.  Personally, I think this  
is a conceptually weird model, whose only value is the XA  
Synchronization interface.
   D) EJB message driven beans: pooled instances again, but for a  
specific use.
   E) Singleton.  Basically a single-threaded, locked object.
   F) Entity - for historical interest

4) aspects - *note* all aspects can theoretically apply to either  
WebBeans or EJB.  The only restrictions are bureaucratic

   A) Interceptor - WebBeans and EJB
   B) Decorator - WebBeans
   C) Transaction - EJB, but possible for WebBeans
   D) security (@RunAs, etc) - EJB, but possible for WebBeans
   E) asyncronous, EJB, but possible for WebBeans
   F) @Schedule, EJB but possible for WebBeans
   G) @Lock, EJB but possible for WebBeans

5) packaging

    WebBeans - any .jar or classes
   EJB - ear or war

 From the above capabilities, the strength of the EJB spec is in its  
predefined aspects.  These are good.  The EJB component lifecycles  
have specialized uses, but the most simple, common and important is  
missing, presumably left to the WebBeans spec.

The weaknesses of EJB are in its configuration, location/binding, and  
packaging (and missing component lifecycle), but these are WebBeans  
strengths!  So the two specs complement each other, they don't  
directly complete.

> If EJB has not reached this state then it is a failing of EJB,

I'd think 10 years of failing would give a rather big hint.

-- Scott 

> and means
> that EJB should be fixed and/or modified so that it provides  
> whatever kind of component
> that people need or want. It does not warrant adding yet another way  
> to develop business
> logic components and then adding the functionality that may already  
> be, or should be, in
> the existing component model.
>
> So, with this issue as a backdrop, I think there are two things that  
> this spec can do to
> ensure that the platform is not fractured or schitzophrenic in  
> certain areas:
>
> 1) We have to ensure that this spec makes use of existing component  
> models, modifying the
> existing component model when necessary, and adding new features to  
> the model when required.
> Note that this correlates exactly with what this spec originally had  
> as its mandate -- to
> integrate existing JSF and EJB components.
>
> 2) Ensure that people understand what this spec is, what it is  
> offering, and what problems it
> is trying to solve. One thing that has become abundantly clear is  
> that when people read the
> term "web beans" they think of it as being a second/third type of  
> enterprise bean. This is only
> natural, but can be easily avoided by changing the name to be more  
> in line with the value
> that this spec has, and the domain in which it resides.
>
> So, we are really talking about more than just a name change, but a  
> name change is certainly
> a good start!
>
>> -----Original Message-----
>> From: Gavin King [mailto:gavin at hibernate.org]
>> Sent: Sunday, December 21, 2008 2:32 AM
>> To: Java Community Process JSR #299 Expert List; WebBeans; Matt  
>> Drees;
>> Scott Ferguson; Michael Keith; Jim Knutson
>> Subject: Terminology
>>
>>
>> Oracle have proposed that we remove the term "Web Bean" from the
>> specification. I'm therefore searching for alternative terminology.
>> Please let me know your opinions and suggestions.
>>
>> Here's one possibility:
>>
>> Web Bean -> injectable type
>> simple Web Bean -> injectable Java class
>> enterprise Web Bean -> injectable EJB
>>
>> Or:
>>
>> Web Bean -> contextual type
>> simple Web Bean -> contextual Java class
>> enterprise Web Bean -> contextual EJB
>>
>> Note that "contextual type" already means something in the current
>> spec, but that thing should be easy enough to rename.
>>
>> -- 
>> Gavin King
>> gavin.king at gmail.com
>> http://in.relation.to/Bloggers/Gavin
>> http://hibernate.org
>> http://seamframework.org
>>
>
>

More information about the weld-dev mailing list