John Reynolds's Blog

Make JDO the "P" in CMP

Bruce Tate's article "For JDO, the Time Is Now" brings up many good points, but it misses a key concern of mine: Solutions that already incorporate Entity Beans would be painfully expensive to rearchitect as JDO solutions.

The J2EE specification for Entity Bean CMP should dictate the interface for using JDO as a persistence mechanism. This would allow developers to reliably introduce JDO below the Entity Bean level without impacting the overlying layers of their applications.

I am involved with a project that uses Toplink as the CMP mechanism for Entity Beans and have experienced the pain of incorporating a non-standard persistence mechanism. Bruce is not completely candid when he states that TopLink can be used as a snap-in replacement for EJB CMP; it's more like a hack-in or pound-in replacement.

The interface between the EJB container and an underlying persistence mechanism is not a part of the J2EE standard, so Oracle (formerly WebGain) has to craft unique versions every time the container (in our case WebLogic) changes. At times we have been unable to apply WLS Service Packs because they would break Toplink. This is a real maintenance and upgrade hassle.

A standard mechanism for using JDO as the "P" in CMP would avoid versioning problems between EJB containers and JDO implementations, and it would also enable the ability to truly snap-in competing JDO implementations (competition is a good thing).

On another note, Bruce lobbies for the recognition of SQL in the JDO standard, and I heartily agree. EJBQL and JDOQL just aren't up to snuff, and from my perspective they just aren't worth bothering with. SQL is not as "Java friendly" as the new query languages, but it is much more comprehensive and widely understood. It seems like a distraction to pursue EJBQL, JDOQL and JDBC rather then focusing on tools to help developers write good SQL.

All in all, I am delighted at the possibility of a JDO resurgence, but I hope that it expands to embrace fixing EJB CMP rather then just replacing it.

Update 1: The problems that we have experienced due to the tight coupling between Weblogic Server and Toplink CMP have crossed the pain threshold to the point where we have commited to fixing the problem.

After careful analysis, we have determined that EJB CMP 2.0 can not meet our needs (primarilly due to the limitations of EJBQL) and the best option for us is to eliminate Entity Beans and use Toplink for Java directly from our session beans. This looks like a rather straightforward conversion for us. I'll keep you posted. Update 2 (July 2004): The EJB 3.0 spec's radical overhaul of CMP has so confused us that we've slammed on the brakes. We're going to maintain our current code for the next few months and wait for the dust to settle.

Comments

• In Brazil, we'd call this "palitativo"
  A "paliativo" is something that is supposed to give a result but actually doesn't delivers it, but it also do not makes things worse. It's a fake solution that actually does not solves anything. It just provides a ilustion, because you note something has changed.

  I thing the biggest drawback of CMP EJB is that the OO/Relational mapping is outside the spec and so you have the painfull problem of configuring one of the proprietary OO/Relatinal engines each ejb container provides, or integrating a third-party one.

  JDO also does not defines how to map Java classes to relational tables, and so JDO implementations are as interoperable as CMP implementations are. That is, bot at all. You have to rewrite descriptors (or configuration files) and rewrite the methdos that use some proprietary way to make something that isn't provided by the spec (like order by on ejb 2.0)

  You'll change a lot to get on the same problem: your application has to be changed to work with a different ejb container and OO/Relational mapping tool.

  Your proposed solution will become a real one, and not just a "paliativo", when the JCP "completes" the specs for either EJB or JDO, guaranteeing 100% interoperability, without code and configuration changes, from any vendor implementation.

  Posted by: flozano on March 12, 2004 at 09:59 AM

• In Brazil, we'd call this "palitativo"
  Thanks for the great word of the day!
  "Palitativo" certainly seems to apply.

  Posted by: johnreynolds on March 12, 2004 at 11:17 AM

• More like putting lipstick on a Pig...

  Which, in my opinion, what really the "P' in CMP stands for. Bruce in a way actually answers your question when he alluded to the BMP based solutions, where developers ended up having the worst of both worlds.

  So, if you ask me, I'd say let CMP die a slow, and peaceful death.

  Posted by: mikeazzi on March 12, 2004 at 11:27 AM

• Thanks for reading.
  I didn't expect so much interesting discussion so soon. You make a good point. Adopting JDO would not be a backwards-compatible solution. And if you're not experiencing much pain with EJB, then why change at all?

  But if you're already experiencing enough pain to force you to look for an alternative, I can't think of any reason that you'd want to stay with a CMP type interface. It's ugly, and invasive, and complicated, and often slow.

  Like you, I don't think that TopLink is ultimately the answer. It's got its own share of warts, and the Oracle acquisition has not improved things.

  I believe that for EJB, (and not just CMP), *the interface is the problem*. Transparent persistence allows much better productivity. More likely, instead of adopting a backward-compatible solution, you'd be looking for a way to use JDO with your existing EJB session facade, which you can already do today.

  I've got a book coming out called Better, Faster, Lighter that will explore some alternatives to massive J2EE architectures, that in some ways are ready to collapse under their own weight.

  Posted by: batate on March 12, 2004 at 12:03 PM

• JDO - no thanks
  While it may seem sexy, I'll take the simpler solution, the one that doesn't require bytecode enhancement - Hibernate. Hell, even OJB. At least then my source and my compiled programs will always be 'in synch' if you will. I personally beleive that Hibernate coupled with AOP produces a much more elegant and modular solution that is earier to maintain.

  M

  Posted by: johnnycannuk on March 12, 2004 at 12:06 PM

• More like putting lipstick on a Pig...
  That's a image that will stick for awhile :-)
  Aren't you really advocating "Death to Entity Beans"?

  Posted by: johnreynolds on March 12, 2004 at 12:06 PM

• I don't like it, but it's what I have today...
  At the moment, I am staying with a CMP type interface because that's the only "standard" solution... and economically it's the one we've already paid for (as part of our J2EE app server).

  Life would be simpler if the persistence mechanism of the J2EE app server was decoupled from Entity Bean CMP... and JDO could be the interface to the persistence mechanism. I believe this is what JBOSS4 is working towards.
  

  Posted by: johnreynolds on March 12, 2004 at 12:27 PM

• More like putting lipstick on a Pig...
  Well,Yeah!! If you take persistence out of entity beans, then what else is left that's worth a damn? All you've got left is a really convoluted, awkward, invasive way of programming. Isn't persistense management the "raison d'etre" of entity beans in the first place?

  Posted by: mikeazzi on March 12, 2004 at 12:48 PM

• The verdict is Death!
  Death to Entity Beans it is!

  But for the sake of someone stuck with an existing application full of Entity Beans, give me some help in killing off those suckers one at a time (My management is rather conservative).

  My yucky Entity Beans have a vendor-supplied-and-supported persistence mechanism with a clustered/distributed caching mechanism.

  If I introduce JDO (or Hibernate), I will also have to introduce a second persistence mechanism with a clustered/distributed caching mechanism.

  Wouldn't life be simpler if CMP and JDO shared the distibuted caching aspect (at least until I come to my senses and completely nuke the Entity Beans)?

  Just a thought

  Posted by: johnreynolds on March 12, 2004 at 02:24 PM

• I don't like it, but it's what I have today...
  Aaaargh! #1 on my Java Pet Peeve List is, "I'm using it because it's the 'standard.'"

  Why is it that Java developers, as a group, are so obsessed with "standards"? Sun's obsessed with them too, so they rush things through, standardize before implementing, and we wind up with garbage ladened specs like EJB and JDO that could be so much better.

  Is any other developer committee this obsessed with "standards"? Let's standarize common sense instead.

  Posted by: jimothy on March 12, 2004 at 02:55 PM

• Common sense
  Ouch! Point well made.

  Okay... so the common sense in me says let's take all the thousands of man years that have been spent perfecting the aspects of Entity Beans that we do want (transactions, persistence, distibuted caching, etc) and figure out how to repackage/refactor rather then starting over from scratch.

  Fair enough?

  Posted by: johnreynolds on March 12, 2004 at 03:17 PM

• In Brazil, we'd call this "palitativo"
  Oh, I think you mean "paliativo", not "palitativo". The word you name doesn't exist in portuguese (at least, not in the brazilian portuguese...) :-) Just for correctness.

  Posted by: denisfalqueto on March 14, 2004 at 06:25 AM

• In Brazil, we'd call this "palitativo"
  In English, the word is "palliative", and I agree that we beed a complete rethink of current OR mapping standards for J2EE.

  Posted by: david_kennedy on March 15, 2004 at 05:30 AM

• Common sense
  Fair enough! Sounds like that's exactly what we need. But Sun need not be the driving force. A little third party competion, for example from Hibernate and OJB is healthy. If a "standard" is needed, let's draw from the lessons learned from these, and other, projects, rather than the up-'till-now typical "Standardize first, implement later" approach pushed by Sun.

  I realize that Sun involves third parties in the JCP, and that many JSRs are in fact driven by third parties and not Sun, but it still amazes me that anything with Sun's Seal of Approval is deamed a "standard" while anything from the Microsoft camp is "proprietory." This reflects a fantastic branding campaign from Sun. I'm also amazed that we need so many "standards" as opposed to, oh, I don't know...an API.

  P.S. Please pardon my Dean-esque exclamation in my previous message. An overreaction to a long-standing pet peeve of mine.

  Posted by: jimothy on March 15, 2004 at 07:30 AM

This work is licensed under a Creative Commons License.