There has obviously been a lot of buzz that cropped up after the EJB 3 announcement at TheServerSide Java Symposium. On the one hand, it is very impressive that the JCP is making a bold move…. and really trying to make EJB simpler to develop. Although it is great to see this happen, I can’t help but find myself confused when it comes to the persistence side of the equation.
JDO vs. EJB: Technical differences
There are a few technical differences between what looks to be in EJB 3 (which is still in VERY early stages by the way… and who knows when IBM will wake up ;). Gavin blogged about some of the issues he has with JDO, and I appreciate him coming out in public. I think it is really important to have these discussions in the open, and we are very lucky here with Gavin.
However, if you look at the points raised (e.g. JDO-QL isn’t as he likes, and persistence-by-reachability), I think they are fairly minor. Both JDO 2 and EJB 3 are not finished, however if you look at the features sets as they stand today, you will see many more similarities than differences. They are SO close that it isn’t even funny. In fact, they are so close that I don’t understand why Gavin and Oracle (who announced they are leaving the JDO expert group by the way) wouldn’t want to discuss them more. I know the expert group has really enjoyed having both of those parties involved, and together the java-persistence world is a great force.
So, the technical discussions between JDO and EJB have started. I hope they continue. However, I am actually more concerned about looking at the forests instead of the trees.
Do one thing. Keep it loosely coupled. Do it well
I really do not understand why persistence has ever been coupled to EJB. Persistence is a cross-cutting concern, that needs to be solved in AND out of the enterprise.
Let’s take a look at two alternate universes:
1. JDO and EJB working together
Imagine if the persistence experts from both the EJB side, and the JDO side all got together. JDO would become a fantastic persistence standard (in fact I think JDO 2.0 already is…). From the EJB world, we would make sure that JDO is written in such a way that it fits in perfectly with the needs from that side of the house. JDO has always tried to do this (working with J2EE CA, EJB transaction model, etc)…. and I think it is very important.
So, now we have a top class persistence spec, which would be ready to roll pretty darn quickly. EJB 3.0 can now get rid of ALL of the entity baggage (what is the % of the spec?). They can focus on making the programming model lean and mean. Session beans will be so clean to write, Message Driven beans a pleasure, and we have a chance to handle more. EJB should be all about transaction processing, and handling true enterprise needs. Now the expert group can spend time on a half decent security model, a nice thread worker pool for the times in which you need them, an interceptor stack, and things the enterprise truly needs.
Wow, as I type this I feel happier. Wouldn’t this all be great? Wouldn’t this be something we could be proud of? Now if you say “I use EJB” people say “I am so sorry”. In this alternate universe that would disappear. Let’s get back to the current real world though :(
2. JDO and EJB fighting, or ignoring each other
As it looks right now, we have two separate camps. There will be infighting between them. Developers will find it hard to choose which technology to use on their project. If an application isn’t an enterprise application they can simply plug into JDO. Then imagine if they want to migrate it to an enterprise app… would they want to change it to EJB 3?
Why wouldn’t you want universe #1?
I am finding it really hard to understand what sane person wouldn’t vote for universe #1. Please correct me if I am wrong here, but are there any technical reasons for this?
The only reason I can come up with is political: Vendors want the lock-in that they get with the current tight coupling of their persistence engines to their EJB container
Take a look at the EJB specs, and how:
(EJB 2.0 spec, page 509)
“We plan to provide the following in future releases of the EJB specification:
- specification for the pluggability of Persistence Managers
Why has this been on the list for all of time with respect to EJB? Isn’t it time to get around to this yet? I worry that the only reason is that vendors are scared. They want their container to be tightly coupled to their persistence engine. This actually seems so bizarre to me. I think it would be in the vendors interest to open this up. At one time the CMP engine was a main differentiator. Now we have moved up the stack, and there are plenty of others areas. The application server is becoming a commodity, so lets open up the bad boy and move on.
If we were writing code that tightly coupled items such as business objects with persistence, we would make fun of ourselves.
Let’s go for a brave new world
I really hope we end up at universe #1 one day. At this point the EJB spec will just be a standardization of some enterprise services. When it makes sense, sub-specs can be created allowing us to divide and conquer. We can work on the sub-parts in parallel, and experts in those areas can work on doing the best job they can.
I have been honored to work with the JDO expert group members. There are too many of them who are far too knowledgeable of the world of transparent persistence, and ORM, to not be part of the biggest effort.
As Marc Fleury himself would say… let’s take the red pill ;)
