[webbeans-dev] RE: Terminology

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. 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). 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@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. > > > -- 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 > >> > > > > > >