[webbeans-dev] Re: Terminology
Scott Ferguson
ferg at caucho.com
Wed Dec 24 13:44:04 EST 2008
On Dec 23, 2008, at 3:55 PM, Gavin King wrote:
> 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.)
I do think the configuration and binding/locator capabilities are the
heart of the spec, but I'm mostly agnostic on the naming.
Some of the best names are arbitrary, like "swing", "bean", "java",
"seam", etc. because in a year or two, everyone will treat the name as
arbitrary anyway. I do think "bean" is overused, so it would be nice
to pick something else.
I like Emmanuel's "weaver" suggestion. It's a nice image about what
the spec's trying to do without bogging down by trying to get too
literal.
-- Scott
>
>
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
More information about the weld-dev
mailing list