Big Data/Analytics Zone is brought to you in partnership with:

Hands on software technologist and executive. Extensive experience with distributed database technology implementations and associated industry landscape. Software product management expert with a history of defining and executing strategic product roadmaps while evangelizing and supporting the technical aspects of marketing and sales. Built and managed engineering development teams who've delivered innovative, mission critical quality products to market. Skilled at public speaking and communications to enterprise software professionals. Managed multi-million dollar budgets for engineering, product management and marketing operations in an internationally operated public company. Robert has posted 1 posts at DZone. You can read more from them at their website. View Full User Profile

Java Persistence Standards Applicability to NoSQL Database Technology

07.11.2013
| 4891 views |
  • submit to reddit

Many of the Java developers with a few years under their belt will likely remember the POJO persistence wars of the early 2000's.  At that time, there were a bunch of crazy guys (like me :-) touting a POJO persistence mechanism called JDO (Java Data Objects)  -  big credit to Craig Russell who drove this JSR.   The thing that really made JDO cool was the fact that it dealt with persistent object lifecycle management orthogonal to what was the underlying data storage technology, so it supported RDBMS, FileSystem, XML, Object, virtually any kind of data storage  technology.  Only now in the age of NoSQL can one really start to appreciate the brilliance of this effort, and hence the reason for this article. 

There were several vendors who were selling JDO implementations and participating in the standards efforts - e.g. JDOGenie, Solarmetric, Versant (there were others).  The JDO folks were initially headed into battle against the EntityBean and its EJB standards group who were the established Java=>RDBMS persistence body.  

At that same time, there was another big industry shift happening, a shift from closed source proprietary solutions to open source solutions.  There was a lone guy named Gavin King, who clearly saw the superiority of POJO based persistence over heavy weight EJB's, but (as I recall) thought nobody cared about any database type but the RDBMS.  So, he started his own POJO open source project called Hibernate and basically dismissed the JDO crown. The Hibernate team started slinging mud like "byte code enhancement is the devil" and going to battle for the top of the POJO persistence stack.  

In the end, Hibernate won that battle and in fact, won it so completely that it became the catalyst that brought the EJB/JDO/Hibernate groups together. It was the success of Hibernate that got the EJB guys to acquiesce and embrace POJO persistence for Java and materialized the JPA specification, the interface that can be found today in every Java download for dealing with persistence.  

I think what won the POJO battle was really the fact that Hibernate was free open source, as in the end, it implemented many of the "horrible things" it found in the JDO vendor products. Today, as we see a great shift in the one database for all workloads paradigm, it seems clear to me that the POJO abstraction that became JPA, which is really about Persistent Object Lifecycle Management, can easily have a role in the emerging NoSQL market.  

This is not to trivialize NoSQL, because it is much more than an API issue, it is an architectural shift in the way data is managed and delivered in a Big Data, global economy, digital world.  Along with that architectural shift NoSQL represents a new attitude towards schema ownership. The acceptance of data constraints closer to the computing edge and embracing of an agile development process less encumbered by the dreaded DBA change request queue, embracing (as Google puts it) soft schema implementations. 

There are some lessons to be learned about dealing with the language API abstractions and persistence life cycle independently of the persistence architecture, just as independently as JDO did for persistence storage technology.  The work of JDO / Hibernate / JPA teams are important for the path that lies ahead with the maturation of NoSQL technology.

To that end, as I am now at Oracle helping to drive technology and standards for their NoSQL database, I started looking around at what kind of POJO persistence was emerging for the Oracle NoSQL Database (ONDB) and NoSQL databases in general.  I was encouraged to find there are several options (e.g. EclipseLink, Hibernate OGM, Kundera, Spring Data, etc) out there and more emerging to help Java developers get the familiarity and ease of development with which they are accustomed integrated with a new generation of scaleable database architecture found in the NoSQL space.

For example, the EclipseLink JPA team has an implementation for several NoSQL stores.  It is early technology, so I found a few quirks that make it a bit difficult to get started with ONDB, so I've created a blog on the subject and a bit of a tutorial.  The Oracle EclipseLink team is working on a whole set of improvements specific to dealing with NoSQL as a persistent store technology accessible via the JPA API.

What do you think?  Is Java and JPA with NoSQL extensions suitable for only the Enterprise class developer or do you think its something which can be embraced by the smaller startups and mid-sized developer teams?  Perhaps tied to Java those are unfair questions. Place the same thoughts into the world of Python, Ruby, Scala.   Heck anyone notice even javascript has a server side now and objects are getting passed around between the ...dare I say client and server.  Would these languages benefit from the emergence of a more unified approach to dealing with the Persistent Object Life Cycle and does a standard like JPA have a future in those languages even if just as a working roadmap?

Published at DZone with permission of its author, Robert Greene.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)