Discussions

News: Gemstone to re-invent itself as JDO vendor for J2EE app. servers

  1. Following the aftermath of the re-acquisition of Gemstone from Brokat, Gemstone has decided to re-invent itself as a vendor of a Java Data Object (JDO) persistence pluggin for J2EE app. servers such as Weblogic and Webpshere. "Diamond", Gemstones JDO product is built on Gemstone's distributed shared object cache and O/R mapping tool (also known as the Gemstone PCA).

    This new move is probably the smartest thing Gemstone could have done. As of next year, Gemstone will be providing the industry with the only JDO implementation based on proven 18-year old distributed shared object cache technology.

    Gemstone will also continue to build and support its Gemstone/S Smalltalk application server, but its Java strategy is now focused on the Diamond product.


    From the website:

    GemStone's goal is to make the performance, reliability and adaptability of our persistent cache architecture (PCA) available to developers industry-wide. As one step towards that goal, we are making core PCA features available in a distributed object cache compliant with the emerging Sun JDO standard API. This product is now being developed under the project name "Diamond".

    In addition to all the features of JDO, the Diamond object cache will offer:

    A shared memory model that facilitates inter-VM communication
    Reduced conflict collections to support optimistic concurrency control
    Recoverability of data and transactions
    Transparent object persistence that eliminates O/R mapping for metadata
  2. I think this is excellent news and I hope more vendors that have innovative technology that currently locks you into their J2EE server will also do this and resell the technology on the leading J2EE platforms.

    J2EE is supposed to become the DOS/Win32 of server side programming and it's moves like this that help it along that path.
  3. And I also hope this succeeds. The CMP space definitely needs a good OO DB. I worked with the pre-EJB Gemstone/J (and other OO db's in the Smalltalk arena), and nothing beats a good OO DB.

    Gemstone/J was extremely fast and reliable. No complex mappings to worry about, and you can store ANYTHING that you can express in java, completely transparently.
  4. There are many other vendors planning to offer JDO that runs on third-party AppServers too. Visit www.access1.sun.com/jdo to find out who are the other players. Many are perhaps ahead of Gemstone
  5. GemStone/J Close?[ Go to top ]

    I don't think their is any questioning how "close" GemStone is to providing an implementation of the JDO spec at all. The product already has most if not all the requirements of the JDO specification in the PCA already just not the common API to those services.

    It will be very interesting to see other EJB servers running inside the PCA-GemStone/J shared object space. It will open a wide variety of doors for developers. Hopefully it will lead developers new paths and develop software in more advanced ways.

    I thought relational databases were supposed to go out of style with The Jackson Five?
  6. I have been wanting for *years* to use GemStone/J to have access to its OODB, but their whole package has been such a niche player that it's never been given *any* consideration by clients. I'm very glad that the OODB is being separated out.

    It's interesting that they pointedly don't call it an OODB, just as ObjectDesign (now Excelon, now C-Bridge) never liked to admit that their Excelon XML database was built on top of an OODB. I get the feeling that the term "OODB" has strongly negative marketing cache now, so they invent new terms like "persistent object cache".
  7. FYI, these are major JDO vendors listed in Sun's JDO web site:

    1. Sun Forte Internet Edition 2.0 (Include an implementation of JDO spec
    0.8)
    2. TechTrader KodoJDO (version 2.1.2 beta, claims to be the most complete
    version. Direct comparison matrix with OpenFusion)
    3. Rexip JDO (as complete as KodoJDO with some features not found in KodoJDO.
    OR-mapping. Beta available for download (www.rexip.com) together with Rexip
    AppServer)
    4. Versant JUDO (Preview release 0.5.0. Built on top of Versant ODBMS)
    5. Object Identity (One of the members of JDO expert group, provide services
    of consultation, education and training of JDO)
    6. PrismTech OpenFusion JDO (Beta release, implemeted JDO 0.8, final release
    on Sept)
    7. Object Technologies Orient JDO (preview release, Built on top of Orient
    ODBMS, final release on Sept)
    8. Poet FastObject JDO (built on top of Poet FastObject, available in Q4)
    9. ICS Computer Service JDO (not available for download)
    10. ObjectDesign JDO (not available for download, built on top of
    ObjectDesign ObjectStore and Javlin EJB Server)
    11. LIBeLIS LiDO (built on top of Versant enJin, now in beta stage, not
    available of download)
    12. Gemstone JDO (alpha release on Sept, and final release on Q1 2002.. run on
    OO DB?)

  8. JDO is gaining vendor support but mostly from OODBMS vendors. Why is there such a distinct lack of announcements from relational database vendors or integrators?

    Even the JDO reference implementation doesn't yet support relational databases, which simply amazes me. The last time I checked, relational databases were fairly popular ;-)

    Piper
  9. Some thoughts:
    (1) Relational vendors already have a "standard": SQL.
    They have every reason not to be interested in a shift in the paradigm, how to program against a database. Currently they are fighting windmills, trying to add inheritance capabilities to tables and SQL. Digging trenches at other fronts is not in their interest.
    (2) JDO is Java only.
    (3) The concept behind relational database technology is "thinking in sets". JDO focusses on "thinking in objects".
    (4) JDO query functionality is miles away from the capabilites that SQL can provide. Relational users would never accept a downgrade.
    (5) The JDO concept matches the paradigm that the old-time-object-databases use. Why should relational database vendors move into a market, where other companies have a head start? Even more so: Why not wait for a proof-of-concept? None of the publicly held object database companies are prosperous at this time. Looking at the Edgar figures, none of them has database license revenues exceeding 6,5 million $ per quarter. All of them have high losses.
    It is very well possible that things might change if we see three or more 100% fully functional JDO implementations in the near future and companies start making good profit in this area.
    Currently it rather looks as if some of the object database vendors could be running into severe cash problems still this year.
    Storing objects to object databases of course makes more sense than using relational databases. Of course we *do* need a standard.
    As I can see TheServerSide team is trying hard to create hype around JDO. Floyd Marinescu (the inventor of JDO I think?) and Billy Newport, both working for TheServerSide are padding eachothers shoulders vice-versa.
    Nice technology you have here:
    "PostgreSQL powered" :-)