[webbeans-dev] Re: Terminology

[Gavin King]

I dont think we need to get into a debate over which of EJB|web beans  
is a superior "component model", since they are highly, highly  
complementary technologies, and because its become clear to me over  
the past few months that people mean very, very different things when  
they use the term "component model".

What is important is that the terminology we use emphasises to  
developers how complementary these specifications are, helps them  
understand exactly what problems are intended to be solved by each,  
and makes it utterly seamless to use the to specifications at once.

 From that point of view, what terminology emphasizes the specific  
problems that are solved by the 299 spec? "injectable type" or  
"contextual type" make sense to me, but perhaps there is something  
better. (It sounds like Scott would like something that emphasises the  
configurability.)

Sent from my iPhone

On Dec 24, 2008, at 9:04 AM, Scott Ferguson <ferg at caucho.com> wrote:

>
> On Dec 23, 2008, at 10:31 AM, Michael Keith wrote:
>
>>
>> Scott,
>>
>> I tried to explain why the name of this spec was problematic. I  
>> provided
>> some background that the underlying issue that an additional  
>> component model
>> layer was being introduced, and that we needed to try to resolve  
>> that problem.
>
> We all want a standard JavaEE component model.
>
> 1) Is EJB the current JavaEE component model?  No.  Sun presented  
> EJB to the Java community and it was rejected.  Further versions  
> were also rejected.  In their anger and frustration, independent  
> developers created their own, successful component model named  
> Spring.  Spring is the current de facto component model, not EJB.
>
> 2) Should EJB be offered yet again as the JavaEE component model?  I  
> presented abstract criteria for evaluating component models, and the  
> new EJB draft falls short on the most critical requirements:  
> configuration and binding.  So, no, EJB should not be offered as the  
> JavaEE component model.
>
> 3) Will Sun offer EJB again as the JavaEE component model?  That's a  
> bureaucratic question.  Based on past history, yes, Sun will offer  
> EJB again as the component model regardless of technical merits or  
> public demand.
>
>> What you came back with was a bunch of reasons why the EJB  
>> component model was inferior
>> to the web beans component model, and that EJB is essentially a  
>> failure and "not a complete,
>> modern component model" (which I am tempted to debate with you  
>> about, but have resisted
>> because it is really entirely beside the point).
>
> If we are to have a standard JavaEE component model, I'd personally  
> like it to be the best one possible.  That's not beside the point.   
> That is the point.
>
> If you honestly believe EJB's configuration, binding, and packaging  
> is superior to WebBeans as a component model, please do give your  
> reasons.  We all want the best model possible.
>
> -- Scott
>
>>
>>
>>>> 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.
>>
>> You obviously think that EJB is in a failed state as a component  
>> model so I
>> am just wondering why you think web bean components should replace  
>> EJB components
>> in "modern" applications, anyway? What right does web beans have to  
>> become the
>> new "modern" component model? Because it's newer? Because it's  
>> better?
>>
>>> -----Original Message-----
>>> From: Scott Ferguson [mailto:ferg at caucho.com]
>>> Sent: Monday, December 22, 2008 10:21 PM
>>> To: Michael Keith
>>> Cc: Gavin King; Java Community Process JSR #299 Expert List;  
>>> WebBeans;
>>> Matt Drees; Jim Knutson
>>> Subject: Re: Terminology
>>>
>>>
>>>
>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>