Andreas Schaefer documents a thought from a discussion with one of the product managers for Glassfish, and says that "One of the thing that strikes me with EJB3 is that Sun seems not to be able to let go of old stuff... I would have made the support of EJB2 optional."

Right now an EJB3 application server needs to support EJB2 and EJB3 and must make sure that they do not conflict. This is going to convolute the code and drags down the performance. If I would have been in charge I would have made the support of EJB2 optional and required that an JavaEE application is either EJB2 or 3 so that the application server can deploy it on different containers. I would it even have made it possible that an application server can only support EJB3 and so a deployment of an EJB2 application would fail.

This was discussed as part of the Java EE process, and there were members of the EJB3 JSR who specifically argued against outright dismissal of older specification compatibility. That said, it's an interesting question: would you be affected by such a possibility, that EJB2 not be part of Java EE 5 at all? What about the suggestion that an application use EJB2 or EJB3?

I can answer that bluntly: Hell yes. Absolutely EJB3 should include EJB2. Simply put, if it didn't, it would have killed EJB dead in the water. Like a turtle in a barrle with shotgun. POW! Why? Because you just destroyed the growth path. You just told all those folks who have a gazillion lines of EJB2 "Yea, umm...that didn't work. So, you know, thanx and all, but you have nowhere to go." Combining EJB2 and EJB3 lets the legacy (yes, Java EJB is old enough to be considered "legacy") systems work initimately with the new standard. It lets agencies deploy old code alongside with new code, without having to jump through hurdles like EAI systems or web services, nor having to port their old applications. Making EJB3 standalone wouldn't have made anything simpler. The spec would still be just as complicated. But from an implementation point of view, EJB3 is not dramataically different from EJB2. Rather, it's just got some simplified mechanisms to support the developer through injection and annotations. But in truth, even if you tossed out EJB2, you'd really only be tossing out CMP1 and 2 Entity beans. You'd still need XML descriptors, JNDI, transaction model, etc. Session Beans are still here, Message Beans, Connectors, etc. etc. EJB3 changed much of the "user facing" aspects, and added the EntityManager. Other than that, EJB3 IS EJB2. The core is very similar. So, why not mandate support? And, frankly, I don't buy that EJB2 support is costing much, if anything, in terms of performance. I don't think the EJB2 specific mechanisms get in the way at all.

There are countless EJB 2 applications that will be hanging around for years to come. Some of these applications will be slowly migrated to EJB 3, while some of them interoperating with a new set of EJB 3 applications. Also support of EJB 2 allows customers to do a phased migration to EJB 3. If EJB 3.x dumps EJB 2 and Java EE 5 dump J2EE 1.4/1.3 without caring about backward compatibilities many customers will loose faith on JCP and probably dump Java EE :) Anyway even if Sun decides not to include support for EJB 2 as part of EJB 3.1, I believe most application server vendors will keep supporting EJB 2 for a while to keep their customers happy! regards Debu Panda http://debupanda.com Author: EJB 3 In Action

There are countless EJB 2 applications that will be hanging around for years to come.

You don't need to upgrade to the new versions of application servers, as well as you don't need to upgrade to the latest JVM, for running your legacy apps. For the old stuff, you use the old versions. If you upgrade slowly from one version to the other, you deploy the upgraded services in the new application server, and leave the old ones in the old application server. So, I don't think that legacy systems are a reason for keep supporting deprecated stuff forever. Anyway, even if the spec does not mandate the compatibility, some app servers could still support the old spec. There could even be two branches for Glassfish (for example): one that supports only EJB 3, and another that supports both.

I agree with Rodrigo here. The EJB specification shouldn't make it mandatory, rather it can give it as an optional requirement or as a guideline that app servers should provide versions that are backward compatible also. This gives app server vendors the option to release versions of their product which supports only EJB3, so that new applications which are being written do not have to suffer in performance because of backward compatibility support provided by the server which they aren't using at all. I am not saying backward compatibility is not needed. The app server vendors I think have that much brains that they will identify the need to provide a backward compatible version of the server as well. I don't think they can ignore such a large number of users and be so greedy at selling there new product with EJB3. And if any vendor chooses to go against the user community he would obviously pay in terms of lost user confidence. However, I disagree with Andreas' point about forcing the application either to choose EJB2 or EJB3 since a new functionality being added to the application cannot be implemented using EJB3 if developer wants so. And totally removing support for EJB2 is out of question.

...vendors the option to release versions of their product which supports only EJB3

Absolutely. Why force the attachment of the dead weight of EJB2 ? It wil only have a negative effect. Of course they should have probably re-branded EJB3 as something completely different anyway...

Absolutely. Why force the attachment of the dead weight of EJB2 ? It wil only have a negative effect. Of course they should have probably re-branded EJB3 as something completely different anyway...

The dead weight of EJB2 is on EJB3 regardless. The whole EJB3 farce is built on the foundation of EJB2. How can supporting EJB2 (except EJB1/EJB2 entity bean) be a difficult job for the vendors. For new entrants such glassfish, it is possible to build a simple and merely functional EJB2 entity bean on top of Toplink. Or just make EJB1/EJB2 entity bean optional.

Long time support and backward compatibility is very important for the enterprice type customers that typically make use of EJB technology. EJB should be included for at least five or more years.

This is a no-brainer. EJB 2 should definitely be supported. I think the stand-alone JPA spec addresses most of the "EJB3 without EJB2" needs. I admit, though, that I would like to see future Java EE specifications modularized so that different parts are optional.

Hey this comment is so Microsoft like, I once thought that I had typed theserverside.net in my Firefox's address bar. Yes EJB 2 should be mandatory, there are so many applications with EJB 2 & I won't like to touch any one of them just to port them to a newer version because application server doesn't support that anymore. Moreover, that would have been such a wastage of time & money. Hashir Ahmed

This is the time we should learn something from Microsoft! Yeah, I mean it. Look at .NET. They have done exceptionally well in last 5 years and made significant advance compared to COM days!! More and more Java users/companies are moving to .NET. We need not carry all extra baggage just for "backward compatibility"!! It is not that EJB has been there for 20 years! It replaced CORBA/COM apps and now .NET is doing the same. If for all invalid reasons EJB is "too heavy" and not performing well, customers will anyway move to "Spring" or lightweight platforms. So supporting customers forever and thus destroying the future progress is not acceptable either. At some point we must decide to move forward and let users know about it!

This is going to convolute the code and drags down the performance.

Pure hogwash. Been there, done that. Randy

I think that  EJB2 be included

hollywood crossword puzzles

i believe so..for me they compliment each other

buffalo freelance web designer