J2EE Smackdown, XDoclet, EJB, EJB vs. JDO

[Rick Hightower]

I ran accross a really interesting read, entitled
J2EE Container Shootout Summary.
(sunday, Sunday, SUNDAY come to the J2EE Shootout.... We will sell you the whole seat, but all you need is the edge.)
Interesting read... mentions XDoclet and the power of EJB CMP vs. JDO
http://www.rollerweblogger.org/page/roller?catname=Java (Tuesday September 24, 2002 )


Interesting quotes:

What applications justify the use of EJB?
BEA: Robert says that even for small apps, you should design with future migration to EJB in mind. Use EJB if your developers have the skillset for EJB.
...
JBOSS: Mark says: don't access the database directly from Servlets and JSP, use EJB intead. EJB caches data for web applications very well and can be ten times faster than ordinary database access.
...

Another interesting quote.... about JDO

Do you support JDO and what are your plans for JDO?
JBOSS: we have been supporting JDO for quite a while via Castor and other means. But, JDO has not taken the persistence crown. EJB/CMP is much more powerful than JDO. JBoss is working to decouple the CMP engine from JBoss so that it can be used independently of EJB. (Cool beans... RMH)
BEA: ... JDO is not compelling vs. CMP 2.0.

Also pushes XDoclet.... (another quote)

BEA: Robert says it is very difficult to predict the future, but that he sees that XDoclet-like method and field attribute driven development will be important and that web services will be very important.

This is a good read, and a really well written blog. I check it from time to time.

[Rick Hightower]

I am not saying that EJBs are not useful. I am just saying that there are glaring holes in the EJB 2.0 specification regarding CMP. Why do you think there is so much buzz around JDO? Everyone is looking for a better Entity Bean.

EJB 2.0 CMP is not perfect. I agree with that.
In fact if you search, I am sure you can find me complaining about it. But it is useful. I have used it in a production env. and it worked great.
Here are some interesting quotes about JDO vs. EJB CMP...
JDO vs. EJB CMP

Thoughts on JDO....
My opinion, EJB 2.0 CMP CMR is more mature than JDO. Most JDO implementation "don't fully implement the JDO spec. yet".... that said I think JDO will leap ahead of EJB in the near future...

I also think a future version of EJB 2.2 will merge EJB CMP CMR and JDO just like EJB 2.1 merged EJB and web services. There is really no point in having two frameworks that essentially accomplish the same thing. Therefore a later version of EJB will embrace JDO and build on top of it instead of replace it... Just my humble opinion. (note this is just a guess... i have not heard of any such activity)
At this point in time, if you want a portable persistence tier the best way to go is EJB CMP/CMR...

If you want to buy or sell components, you will most likely want a layer of persistence in your components to work cross-platform on application servers (for example, IBM WebSphere, BEA WebLogic, JBoss/Tomcat, etc.) and persistence storage systems (for example, Oracle, DB2, etc.). You do not have to write low-level Java Database Connectivity (JDBC) calls in your EJBs to add these features, a great reducer of time and complexity. Once you get the hang of CMP/CMR, it is faster to write entity beans using this technology, than using low-level JDBC inside of bean-managed persistence (BMP) beans.
What does this mean to you? Well, for starters, you do not have to write low-level JDBC calls and, you do not have to write code to manage relationships. It is all built into the EJB framework. Your interface to relationships is through the pervasive java.util.Collection and java.util.Set which most EJB developers are already familiar with. Very cool!
This additional feature includes support for JavaBeans component patterns for persistent fields, inside of the entity bean. Thus, instead of making your class variables public -- which has always felt strange to me -- you create get and set methods following the JavaBean technology standard naming pattern we all know and love.
I can't stress this point enough. Since EJB 2.0 containers will support the most common SQL databases (and other data stores as well), you can write components that work with many types of databases. This makes it easier to sell components that require persistent storage. For example, you can sell components that will work in an IT department that uses Oracle or a shop that uses DB2. Thus, instead of writing low-level JDBC calls using SQL native to a particular database, you will use EJB-QL to create finder and select methods, and describe relationships in deployment descriptors.
Simply put, CMP/CMR is the missing link in cross-platform component creation. CMP/CMR will spur the growth of the enterprise level component marketplace. In addition, CMP/CMR is easier to use then low-level JDBC calls. CMP/CMR corrects many of the foibles, and missing functionality of earlier versions of CMP. There are many persistence frameworks, none are available on as many application server platforms as EJB CMP/CMR!
Also, there is a significant increase in productivity by using select methods and EJB QL. Code that use to take 10, 20, 30 lines of code can be written in just a few by mastering EJB QL.

Then when you factor in caching....wow....

Mark says: don't access the database directly from Servlets and JSP, use EJB intead. EJB caches data for web applications very well and can be ten times faster than ordinary database access.

We had similar experience when we used Resin EE. The speed of hitting the entity cache vs. the database every time was substantial.

[Chris Mathews]

Of course the big 3 are going to back EJB (that is where they make the money), I wouldn't expect anything less. Marc Fleury doesn't care what technology you use as long as you use it with JBoss
I would really like to be excited about JDO... but when is anyone going to fully support it? I know that I just got done bashing Entity Beans and mentioning JDO as a future alternative, and it might be, but when? JDO and Java Server Faces are two technologies that Java needs to be available today. At least the JSF camp has had some positive news with the annoucement that Struts will support JSF. Haven't heard much out of Craig Russell and the JDO supporters in quite a while. For today and the forseeable future EJB is the way to go for automatic persistance unless you can afford Cocobase or TopLink.
Personally I doubt JDO will be merged with EJB as soon as you predict. Too many people are on the fence and none of the big players that have been traditionally part of the EJB JSRs support JDO. It would make sense and definitely be a smart move, but at the speed that the JCP works I doubt it will happen anytime soon.

[Rick Hightower]

I have no bias per se towards EJB. I use it because it works.
<plug>
I am going to be in Colorado this weekend. I am teaching a tutorial on how to apply XP to J2EE and another tutorial on EJB CMP/CMR and EJB QL (using XDoclet).
Rocky Mountain Software Symposium� 2002.
</plug>
I find both WebLogic and Resin's implementation of EJB CMP/CMR useful.
I have not had as much success with JBoss, but then again I did not give it as much effort.
I am a big fan of Resin but I am not on the Caucho pay roll.

I think JDO has a lot of potential.