It looks like Google AppEngine for Java's JDO support is beginning to spread to others. In particular, Grails now supports JDO on GAEJ, and it looks like GORM is being enhanced to support JDO.
Some of you may not have been aware that JDO has been under active, continous development at Apache ever since before the JDO 2.0 release. In fact, it's the only JSR that I know of that was and continues to be developed in open source, with the expert group's doors flung wide open, and its discussions on a public mailing list. The most current version of JDO is 2.2, with 2.3 imminent.
I, for one, am really happy to see Grails support JDO, seeing that I entered an enhancement request for it a very long time ago. Back then, it got shot down, but clearly, things have changed.
Why did the folks at GAEJ go with JDO over Hibernate? Well, I can't speak for them, but recall that Hibernate (and JPA), by design, target relational databases only, whereas JDO's API is designed to be fundamentally independent of the underlying datastore. Since the most common implementations of JDO in the past have been object-relational mappers, one major enhancement delivered in JDO 2.0 back in 2006 was to standardize object-relational mapping metadata. This had very little effect on the API, and where it did, it was only a matter of convenience for those who needed hybrid applications that used both JDO and SQL together.
JDO, by design, is intended to support any kind of datastore. This is an important point, because only JDO allows us to consider new and exciting ways of storing our data. With little or no change to our code, we can run our applications against relational databases, Google's BigTable on GAEJ, or even new, as yet undeveloped datastores.
I don't think that the day is far off that JDO supports not only cloud-based datastores (BigTable might be considered one), but also multiple datastores, whose boundaries are managed by your JDO implementation. Imagine a comprehensive persistent object model of your entire domain, regardless of where and how its bits and pieces are stored and retrieved, whether they be via relational databases, clouds, web services, RESTful services, other stores, and/or multiple, heterogeneous instances thereof. Better yet, imagine writing a Grails or even a Naked Objects application over such comprehensive object models!
We've all heard of the unified view of the customer; well, JDO is definitely the path to get there.
3 comments:
JPA can be used with GAE, at least it's on the feature list:
http://code.google.com/appengine/docs/java/datastore/usingjpa.html
@Chris,
Yes, JPA is indeed supported, at least the parts that are not relationally specific. I would recommend using the JDO API, since most of the JPA API is a functional subset of the JDO API. I'll try to work on a detailed document of some the differences between the two APIs for everyone's benefit.
To me, GAEJ+JDO is round hole/round peg, GAEJ+JPA is a round hole/rounded-but-still-square peg.
While JPA is supported, it has API methods like "createNativeQuery" which accepts ... SQL. Hence of no use whatsoever to BigTable. The JDO API allows an implementation to support other query languages, so Google could add an implementation of GQL through that API with very little effort; impossible with JPA.
Many JPA annotations are tailored to RDBMS, whereas JDO provides genericity, and hence more applicable to BigTable.
JPA doesn't have a standard way of providing extensions to the spec, whereas JDO does - since the range of datastores is diverse you always would expect to allow configurability of specifics, yet JPA doesn't permit this in many places.
So as Matthew says, JDO is the right tool for the job in this case.
I suppose Hadoop (HBase) would be considered cloud technology too, and DataNucleus now supports that. Similarly distributed grid-based data storage would be a good match to JDO, and likely to appear before long. In the past JDO implementations have been disparate, catering for typically a single datastore type. The situation has changed and the value of the spec has now been realised; time to move it on further.
Post a Comment