Versant / Poet / Solarmetric in JDO-related Announcements

Discussions

News: Versant / Poet / Solarmetric in JDO-related Announcements

  1. The JDO market has seen two significant announcements. Yesterday, Versant and Poet Holdings announced plans to merge. Today, Versant and SolarMetric announced an agreement by which Versant will market, distribute and support Kodo JDO, including a version of Kodo which targets the Versant ODBMS as well as the existing relational database product.

    You can read the announcements here:

    Versant to Merge With German Software Firm (Poet Holdings)

    Versant Partners with SolarMetric to Deliver Standards-Based JDO Solutions

    To read about JDO get a copy of my book Java Data Objects.
  2. Can anybody provide some real-world implementation examples of the DAO pattern?

    I already looked at Sun's Java Petstore. They use DAO only for read-only database queries.
  3. This is not really on-topic, but I'll run with it for a while.

    Patterns represent the repeatable application of good design practice to commonly occurring problems. In the Java/J2EE world, many patterns exist to address inherent weaknesses - resulting from deficiencies or over-complexity - in the J2SE/J2EE platforms.

    Data Access Object is one such pattern. It's purpose is to split the business logic of a class from the persistence infrastructure needed for one or more persistent datastores.

    JDO addresses this by defining transparent object persistence which is datastore agnostic. With JDO, you can write POJOs and later persist them to any datastore for which a JDO implementation is available. You can even persist instances of the same class, loaded by the same class loader, into different datastores from the same VM. Cool!

    Thus JDO solves the deficiencies in J2SE/J2EE which gave rise to the DTO pattern in the first place.

    Essentially JDO *is* the DTO pattern. Write your domain objects as POJOs. Use a JDO implementation that targets your datastore. If you need to use an esoteric store which no vendor accommodates then you could write your own simple JDO implementation - targeting that datastore - which provides only the features you need. Chances are you'd never need to, though, as JDO implementations exist for all of the SQL databases, most of the Object databases, as well as file-system and XML-based storage.

    So, getting back on topic, what does the TSS community think of the announcements from Versant, Poet and SolarMetric?

    Kind regards, Robin.

    For details of the DAO pattern see: http://java.sun.com/blueprints/patterns/DAO.html
  4. With JDO, you can write POJOs and later persist them to any datastore for which a JDO implementation is available. You can even persist instances of the same class, loaded by the same class loader, into different datastores from the same VM. Cool! <

    Is this not possible without JDO? I never noticed a limitation when I used DAO (not DTO, btw) years back.
  5. I wrote "Essentially JDO *is* the DTO pattern". Of course I meant "DAO".

    And Christian, the difference with JDO and your past implementations of DAO is that you would have to have written the persistence infrastructure or be locked into a proprietary persistence technology.
  6. We were talking about persisting any class we want (thats what is called transparent persistence, which is different from automated persistence), not about the underlying persistence implementation.

    I'm really glad the discussion is finally over about implementing interfaces (non-transparent) and we can move on. But please don't claim any kind of "portability" for JDO: You created a dependency on an interface and then invent a precompiler to restore portability. This is not cool, this is mixing cause and effect.
  7. So, getting back on topic, what does the TSS community think of the announcements from Versant, Poet and SolarMetric?


    Well I think it is a very interesting situation.

    My thoughts on this are that there could start to be very little difference between a JDO implementation which persists into a relational database and has very good caching (including distributed caching), and a JDO implementation which persists into an oo database. Or consider the situations of a JDO implementation which uses an an oo database for caching purposes and speed and then persists into a relational database.

    In the end of the day the reason for many organisations to use JDO with an oo store as opposed to a relational store is speed. If one can persist into a relational db and get the speed through caching of an oo db then this is where I think the market will go, because relational is still what the enterprise market want.

    What do you think?

    Regards,
    Menno
  8. This is very interesting news. There seems to have been a steady increase in interest in JDO this year, and now we could be seeing the emergence of a large JDO player that can bring real marketing clout.

    Regards,
    Rod