[webbeans-dev] RE: Terminology
Michael Keith
MICHAEL.KEITH at oracle.com
Tue Dec 23 17:20:32 EST 2008
Okay, Scott. I am pretty clear on where you stand. Thanks.
Do other members of the group have a position on this issue?
> -----Original Message-----
> From: Scott Ferguson [mailto:ferg at caucho.com]
> Sent: Tuesday, December 23, 2008 5:05 PM
> To: Michael Keith
> Cc: Gavin King; Java Community Process JSR #299 Expert List; WebBeans;
> Matt Drees; Jim Knutson
> Subject: Re: Terminology
>
>
>
> 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