4:20 a.m.
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@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(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>