As my RSS reader was showing me incoming entries, I got confused and thought I saw:
Cedric Beust – EJB 3.0 is broken
Actually it was a merged viewing of two entries in a row:
Cedric Beust – EJB 3.0 at JavaOne
Cedric Beust – JavaOne’s scheduling is broken
:)
Debu Panda has written an article on Using a JMS Provider with MDBs via the J2EE Connector Architecture.
You often find that once a technology is fairly mature, changes in version don’t get as much attention, unless they are a rewrite like EJB 3 ;)
The latest versions of J2EE Connector Architecture, JMS, and MDBs make the technologies a lot nicer to use. It is great that we can write MDBs that use messages that are not JMS messages.
I also like the fact that with JMS 1.1 we don’t have the two parralel object trees of Queues and Topics. It is a lot nicer that you can use the MessageProducer/MessageConsumer which works with both point-to-point and pub/sub. Now I don’t have to tweak my client code if I change the publishing model.
A nice article…. *go to page 2 to get to the real meat*.
Scott Ferguson has written a simple blog entry that compares JDO, EJB/CMP, Hibernate and Amber.
He has simple Pro’s and Con’s for the various solutions and manages to keep it 100% technical. He stays away from the politics. Nicely done.
Regarding some of his comments:
I just saw Geir Magnusson Jr. and Jeremy Boynes entry discussing the problem that we have with persistence at this moment of time.
I have personally written about this before here, here, and here.
But back to the blog from Geir and Jeremy. The go through the problem at hand, and notice that we all want the same thing:
Give me a transparent persistence API
It looks like we can agree on that. So then the next question is how do we get to that path.
It seems like a no-brainer to me that we should use JDO 2.0 to get there, but I am of course biased. JDO shouldn’t only be in J2EE, it should be in J2SE in my opinion. You know, sometimes I want to access a data source WITHOUT being in an enterprise environment! I definitely want to do this without having to have an EJB container.
It is great to hear this from some of the Apache guys, and I look forward to us all coming together to work on the same problem. If we got in the same room we would find out that having blue eyes or brown eyes don’t matter. We both see.
Scott Crawford has written up his thoughts on the EJB 3.0 process.
Scott is an independent member of the EJB expert group, and his thoughts are very interesting.
I agree with a lot of the comments that he made in his various articles on the topic, however I do dissagree (of course) with the following:
Since I am not a world expert on object persistence but I do want to do the right thing I listen carefully to these arguments. But I also try to take a step back and look at the big picture. A persuasive point for me is to consider the fundamental design goals of JDO and of the O/R tools. One of JDO
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 ;)
Linda DeMichiel was asked if EJB 3.0 would have to be backwards compatible. She immediately said yes.
What would it mean if the backwards compatibility was made “optional”?
Would the world be so bad if this was an option? Users would have a choice. If the backwards compatibility means a lot to them, they can choice a vendor which has the optional “Supports 2.1″ checkbox.
The programming model is changing so much, that I think it would be fair to not burden EJB vendors with The Old Ways.
What are the reasons to mandate backwards compatibility?
Personally, I wish they made it optional, and we could break out on the new road with EJB 3.
The ballot results for the JDO 2.0 spec are in.
Although the spec passed, there was some significant “No Votes” from IBM, BEA, and Oracle.
They made comments to the effect of:
“There is no room for JDO anymore. EJB 3 is your new persistence model”
Personally, I just want a nice transparent persistence standard. I guess if EJB 3 does a better job than JDO does…. good for them. However, logically, it seems to make more sense that:
JDO: Defines a specification for transparent persistence.
EJB: Define enterprise cross-cutting concerns, using existing specifications where possible.
I think everyone would have been better served in this model. The JDO model allows for persistence without EJB. One of the use cases there is JDO on devices. Are we going to start to see EJB for mobile phones?
JDO has a lot of smart people, who have spent a lot of time on these problems. It is almost a little arrogant to say “we don’t need you”. Why not involve some of these people in the process?
Oh well, time will show us the story. As long as we actually get transparent persistence!
Marc Fleury said the following in an interview at InfoWorld:
When is EJB 3.0 due out and what
Whenever I get together with Ted, the group we are in somehow gets onto the topic of EJBs. We got around to it this time as we had heard the CTO of Orbitz discuss their Service Oriented Architecture, and how they use EJBs. Almost sensing that people would gasp, and think that he must be a bad bad CTO, he clarified that they used EJB for transaction processing.
Fancy that, a use for EJB. Ted and I always end up with “EJB is good at TP and should stick with that”. It isn’t good at persistence, and shouldn’t probably be a distributed object system. EJB is very good at doing the right thing with respect to transactions. The containers are mature, and know how to enlist correctly…. and it all “just works”.
So, as time goes on and I ask myself “when would I ever use EJB in a project”, I find myself justifying it if I was building a truly enterprise system (which is 1% of the total systems that are built?) and I wanted it to handle my TX throughput. In this scenario I could be happy enough using Stateless Session Beans, and Message Driven Beans. For persistence I would not touch Entities with a barch pole, but would opt for transparent persistence (JDO/Hibernate).
The lightweight containers don’t seem to be quite there wrt efficiently doing the right thing with distributed TX, but I am pretty sure that they will catch up. In fact Ron Bodkin (AOP guru) has worked on some nice Aspects that can handle things quite nicely… so this could be promising for the future.
Bottom line? EJBs have a place…. but should focus on the E, and yeah, they aren’t for the majority of projects. I hope that EJB 3.0 gets this, and starts dealing with the requests that developers on these huge systems need, and don’t just slap on some JSR 175 metadata, claim that EJB is easy, and sing a song. If AOP really kicks into gear, I think it would be fun to see EJB be a group of standards around various service aspects.
And don’t get me started on the fact that messaging systems don’t seem to be used nearly enough on projects!
My posts, status updates, link blog, and anything else I do on the web is here:
I am honoured to be working with my long time friend and collaborator Ben Galbraith on helping to set the direction of the industry.