Subject:   JDO thoughts
Date:   2002-12-17 01:02:26
From:   anonymous2
I've spent a lot of time keeping tabs on object persistence technology options over the last few years. I've examined, at various times, almost all of the products/technologies mentioned in previous posts. I don't imagine I'm unique in that respect. Here are some thoughts:

- I had no trouble distinguishing Castor JDO and Sun JDO. Anyone seriously considering either technology would discover their non-equivalence in short order. It seems like a mildly unfortunate naming conflict, whatever the reason.

- Different software, even different parts of a single software project, will have diverse requirements and characteristics regarding object persistence. Scaling requirements, transactional behavior, data structure complexity, hardware environment, programming skills, all sorts of other things, will differ, sometimes dramatically, from each other. There is room for many approaches to co-exist.

Saying, for instance, that because Castor uses "slow" reflection, and is therefor less desireable, is making stupid assumptions about the speed requirements of all data persistence problems.

- After reading the JDO spec, and other available JDO material from Sun and others, my feeling is that, while JDO is interesting, and may even become the only sensible option in many situations, it has suffered greatly by clearly being designed in part by a commitee of existing middleware tool vendors, each of whom needs to ensure their existing product's viability.

Designing by committee is a challenging process in the best of situations, adding in the commercial interests of a dozen vendors, many of whom have VERY expensive enterprise relational mapping software packages and corresponding business models, seems like a bad idea. In fact, I'm surprised that JDO turned out as well as it did, and I don't doubt there was a lot of sincere effort put into it- it shows. But the relationship to pre-existing vendor products also shows.

JDOCentral, the "Developers community for Java Data Objects", mentioned in a previous post, also reflects this unfortunate focus on the middleware/tools vendors who participated in the spec-writing. It has a strong smell of "fake-community". It's not all that bad, but it doesn't even bother to hide it's commercial connections, and it's clear use as a marketing tool for those same vendors.

- JDO, like J2EE/EJB, suffers from requiring what often seems like a bit too much of architectural buy-in on the part of developers. Part of this comes from the requirements of playing in the Sun technology sandbox. APIs that make it through the various JCP/JSR wringers tend to not end up as a-la-cart as they might otherwise be.

Sun's desire to avoid angering tools-vendors means that they do a little too much of the "here's a spec, you'll have to pay for a vendor implementation to do anything serious with it". Sure, it's nice to have designs reflect the seperation between interface and implementation, but I'd rather have them come with a basic but serious, solid implementation as a starting point, which is certainly and notoriously not the case with the JDO reference implementation, at least not when I looked at it not too long ago.

- I'm glad that there are as many open-source and low-cost object persistence projects as there are. I don't see a need to create one spec to unify every persistence API out there. Even if one wanted to do such a thing, JDO certainly doesn't succeed.

- I want to suggest an addition to previous posters' mentioned list of persistence APIs. Db4o is an interesting light-weight alternative object persistence framework. I find it interesting because it doesn't map object data to a conventional relational database like most of the other approaches. It, too, has it's quirks, but I wish the JDO team had demonstrated similar willingness to explore designs not based on the assumptions of years of legacy persistence products. it's at I have no relationship with them aside from having tried out their product.

Back to work now, I guess...

-Dave F.

Full Threads Oldest First

Showing messages 1 through 3 of 3.

  • JDO thoughts
    2002-12-17 14:38:37 [View]

    Hi Dave F.

    Thanks for your input. I'm glad that the distinction between Castor JDO and JDO (JSR12) was clear to you and presumably to others that are "seriously considering either technology". I wish that everyone making decisions on persistence infrastructure adoption would exert the same due dilligence!

    I'd be genuinely interested in the areas you believe JDO suffers because of its "design by committee" origins. Of the vendors who currently market JDO-compliant products I can think of only two who had "pre-existing vendor products" at the time the spec was under consideration. Both of these are ODBMS manufacturers.

    On the Object-Relational side all of the companies currently marketing JDO-compliant implementations who were involved in the spec's evolution were created in order to provide JDO implementations, and had no substantial pre-JDO offering in that area. I'm not trying to be facetious here, nor am I guarranteeing that my analysis is correct, but I don't think there was substantial "pre-existing vendor product" bias. Unless you count SQL as one such influence.... Anyway I'd be interested in your (and others) comments.

    Of course Sun Microsystems has Forte Transparent Persistence, support for which was dropped as JDO approached specification maturity. I think Forte Transparent Persistence formed a useful technology base from which JDO was grown, rather than Sun exerting any undue influence to steer JDO in its own direction. Once again I might have missed something, I suppose.

    As for JDOcentral, it is quite unashamedly sponsored by the JDO vendor community (see the "Steering Committee" page, from "About JDOcentral". Thanks to this financial and directional input, evaluators and users of JDO have a useful forum in which discussions are regularly read and responded-to by experts in the field; some vendor-based and some (like myself) vendor-independent.

    Ok, I have a book to promote, so perhaps I'm not as neutral as I claim! At least I disclosed it up-front to this OnJava thread. And whilst it remains the only book dedicated to the topic it can certainly be said to be the best (and, I suppose, the worst!) one....

    Now that the spec has been published, Sun's marketing department is faced with quite a dilemma: how should JDO be positioned? Given the recent fuss and expense of EJB 2.0 and CMR, they are understandably careful of JDO's positioning regarding Entity Beans. Currently Sun says "Here is the API" but does not directly advocate its use in any specific architectural tier.

    From a JDO-based perspective, the choice to use JDO is reasonably clear in a Client-Server architecture or a Web-based one with no other reason to involve an Enterprise container. I say "reasonably clear" because you have correctly stated that one size does not necessarily fit all as far as persistence infrastructure middleware goes. I will claim JDO is an appropriate choice in "many if not most" of the above scenarios to leave some room for debate.

    Once you have an Enterprise container in the architecture, Entity Beans become an alternative. I've tried to highlight some of the pros and cons objectively in a sub-topic to this thread, but my posting has given rise to no subsequent debate, where I had expected substantial debate.

    Perhaps that's for another day....

    Kind regards, Robin.
    Robin M. Roos
    • JDO thoughts
      2002-12-18 01:29:47  anonymous2 [View]


      Well, of course I don't really know much about what really went on behind the scenes during the specification process for JDO. From checkin the JCP page for JDO, it seems like you were on the Expert Group panel, so I'd be curious to hear what that was like, from you.

      Again, from the the JDO JCP page on, the JDO expert group includes the following list of large software companies, (many with pre-existing data persistence tools) forming the majority of the JDO Expert Group membership.

      Ericsson Inc.
      Informix Software
      Rational Software
      SAP AG
      Sun Microsystems, Inc
      Silverstream Software
      IONA Technologies PLC
      Objectivity, Inc.
      Secant Technologies, Inc.
      Software AG
      Versant Corporation

      David Jordan, author of the above article, was Ericcson's representative.

      A quick overview of the JDOCentral Vendors include:

      FastObjects, Inc - "wholly owned subsidiary of Poet Software GmbH, Hamburg, founded in 1993"
      products include fully ODMG/OQL support in C++ and Java, as well as JDO - seem like mature products

      ObjectFrontier, Inc. - "ObjectFrontier was founded in 1997 with offices in Atlanta, USA and an R & D Lab in Chennai, India."
      They say " ObjectFrontier specializes in persistence management for enterprise applications, providing persistence engines, O/R mapping and caching solutions."
      Their earlier product: FrontierSuite J2EE version 3.0, new product: in FrontierSuite JDO

      SolarMetric Inc. - "is a global company with corporate headquarters in Washington, D.C., USA. [..] founded Solarmetric in 2001. The core technology team has been together since 1997"

      Versant, Inc. - "Since the company’s founding in 1988, Versant Corporation (NASDAQ: VSNT) has led the industry in providing highly scalable and reliable object management solutions for complex, enterprise-level systems."
      Previous product: Versant Developer Suite (VDS) 6.0, "is a 6th generation object database."

      Hemisphere Technologies and Libelis were founded in 1999 and 2000, respectively. I couldn't figure out when Object Industries was founded.

      Clearly, it is desireable to have a specification written by people who are experienced in the appropriate domain, and those people will often be involved in other, related businesses. The above list of Expert Group companies, however, seems like overkill with respect to simply ensuring that experienced viewpoints are part of the process, and seems dangerous with respect to the potential for biased architectural decisions.

      Again, it would be great to hear from you, Robin, your impressions of the JDO spec development process, in particular, why is it that the JDO reference implementation isn't as useful an implementation of the JDO spec as, for example, Apache Tomcat, the Servlet spec R.I. is a useful form of the Servlet spec. One hopes that it's just a matter of time, but...

      -David F.

      • JDO thoughts
        2002-12-20 03:16:15 [View]

        Hello again David,

        Yes, I am a member of the JDO Expert Group. However my membership was only ratified about 6 months before JDO was submitted to JCP for final approval, at which stage the first Proposed Final Draft was already published. I had input on usability, from a non-Vendor's perspective, but the key architectural decisions had been bedded down by that stage. Someone who could give a better impression of any "undue influence" on these decisions would be David Jordan, author of the "Castor JDO - Simply False Advertising" article, as he was there from the beginning.

        Versant and FastObjects were the vendors I had in mind as having pre-existing products in the space. I'm not sure what FrontierSuite for J2EE comprised. The rest are companies which may, I suppose, have had experience implementing aspects of the ODMG spec in some past life!

        To be approved a JSR must provide the specification, the Toolset Compatibility Kit (TCK) tests, and a Reference Implementation (RI). The RI needs to be functionally correct so that it can be used by Vendors to identify the correct behaviour of an implementation.

        It happens that Tomcat is a reference implementation that is so good it is also widely used as a servlet container in real web applications. Unfortunately Sun Microsystems was going through the pain of the current downturn in IT revenues at the time that the JDO RI was being implemented. As a result the amount of resource dedicated to that project was significantly reduced. Finally, the presence of so many commercial implementations in Beta at the time the RI was under development meant that there was no scope for the RI to become the de-facto standard, even if additional resource had been made available.

        Hence we have an RI that is used by JDO Vendors to verify the functionality of their products, but which is generally not employed by JDO Users.

        Happy Christmas!

        Robin M. Roos