BRIDGING JAVA OBJECTS AND RELATIONAL DATABASES

Proposal for a OJB based JDO® implementation

invitation to participate

Thomas Mahler, December 2001

introduction

Within the last year ObJectRelationalBridge (OJB) has become one of the most active open source projects in the field of object/relational mapping.
OJB provides most features one would expect from a commercial product. It also provides several advanced features that are found only in first class products.
OJB has been designed for maximum flexibility, extensibility and scalability.

As the main implementation work for the 1.0 Version of OJB is almost finished I want to prepare for the activities for the 2.0 Version.
The main feature projected for OJB 2.0 is a JDO® implementation (Java Data Objects, the Java standard extension for object persistence as proposed by SUN).

I'm inviting all interested developers to participate in this OJB based JDO® implementation.

In the following I will explicate my proposal and provide first suggestions how the project might be organized.

proposal

I expect that JDO® will have an enormous impact on Java based enterprise computing. I suppose that it will find much broader acceptance than the ODMG API. I believe that it will also find broader acceptance than the EJB Entity Beans concept.
Most vendors of OODMBS and of object/relational mapping tools will provide JDO® compliant products. If OJB wants to remain a viable open source alternative to first class commercial products it must provide a JDO® interface sooner or later.

I propose to build a OJB based JDO® interface now because:

• The JDO® specification is (almost) final.

• there is a general demand for JDO® compliant O/R tools.

• vendors are currently launching the first commercial implementations.

• OJB provides a persistence kernel that has been designed to ease the development of high-level object transactions managers as specified by ODMG and JDO.

• This design is proven as we already have a working ODMG implementation

• AFAIK no other open source project is doing it.

design

state of the art: the OJB ODMG implementation

As of now OJB provides a full featured ODMG 3.0 implementation that is build on top of a persistence kernel, the so called PersistenceBroker. The ODMG implementation resides in the package ojb.odmg. The PersistenceBroker kernel resides in the package ojb.broker. The dependency relationship between the ODMG implementation and the OJB kernel is depicted in the following package diagram (figure 1).

Figure 1: package diagram for the current OJB ODMG implementation.

This kernel based design brings about a very clear separation of concerns. The PersistenceBroker kernel is responsible for basic object/relational services like O/R mapping, performing queries against the backend RDBMS, materializing objects from the RDBMS backend and for inserting and updating objects to the RDBMS.
The ODMG implementation is concerned with providing object-level transactions coordination, performing OQL Queries ("Object Query Language") and supporting specific persistent collections.
During a ODMG transaction commit it uses the PersistenceBroker kernel to persist objects.
The OJB OQL Parser translates OQL statements into OJB Query Objects (an abstract syntax tree representation of object queries) which are executed by the OJB PersistenceBroker kernel to retrieve persistent objects from the RDBMS.
The persistent collections are implemented by utilizing the OJB object/relational mapping techniques.

This separation of concerns helps to keep the ODMG implementation very lean. It does not contain any JDBC calls. It does not even know about the underlying RDBMS. It consists of only 45 fine grained classes, delegating all the hard work to the PersistenceBroker kernel.

JDO® is similar to ODMG in many respects (in fact ODMG may even be considered as a precursor of JDO). I don't want to go into details here, you should have a look at both the ODMG and the JDO® specifications to see how similar they are in substantial parts.

Conclusion: Building a JDO® implementation on top of the PersistenceBroker kernel won't be more difficult than building our ODMG implementation!

how to build a JDO® implementation with OJB

Implementation strategy

First things first: let's put the JDO® implementation into a package called ojb.jdo.

The naive way of implementing JDO® would be to have a short look at the code in the package ojb.odmg (and its subpackages), and write the code for ojb.jdo with some kind of copy & paste reuse from the ojb.odmg stuff. This approach is shown in the next diagram (figure 2)

Figure 2: package diagram for a quick and dirty approach. The JDO® implementation reuses code fragments from the ODMG implementation. Green symbolizes new code.

This approach will be fast and will allow to maintain the ODMG and the JDO® branches independently.

But there are also disadvantages: Due to the similarities between JDO® and ODMG with respect to transaction handling both packages will contain duplicate code. This may result in double maintenance efforts. Duplicate code is also a typical indicator for bad design. This "code smell" may be resolved by an additional level of abstraction.

I suggest to factor out a ObjectTransactionManager (OTM) that contains all basic Object transaction services (lock management etc.). This OTM will be used by JDO and ODMG implementations. This OTM will add a new level of genericity to OJB. The dependencies are depicted in the next diagram (figure 3).

Figure 3: package diagram for the refactoring approach. The ODMG implementation and the JDO® implementation depend on the OJB ObjectTransactionManager that itself is based on PersistenceBroker code. Green symbolizes new code. Pink symbolizes refactorings.

If we choose this approach there are at least two possible strategies:

1. First factor out the OTM and refactor the ODMG implementation to use the OTM. Then write the JDO implementation based on the OTM.
   Problem: we have to know in advance what JDO and ODMG have in common.

2. First write a rapid prototype of the JDO implementation as suggested by figure 2.
   Advantage 1: we will have a working prototype soon.
   Advantage 2: Writing this prototype will show us in detail the OTM intersection between JDO and ODMG.
   Then write the OTM based on this knowledge.
   Finally refactor ODMG implementation and JDO implementation to use the OTM.
   
   
   

The second strategy looks most promising to me.

design principles

Here some of my ideas regarding design issues.

• Don't restrict OJB capabilities to comply with JDO limitations:

  • OJB does not require persistent classes to implement a special interface or to be derived from a special base class. JDO requires persistent classes to implement the interface javax.jdo.PersistenceCapable.
    Of course we must support the PersistenceCapable mechanics. But I don't think that we should encourage things like pre- or post-processing source code to let persistent classes implement this interface.

  • JDO extents don't work for interfaces. OJB extents do. Why should we drop our superset functionality?

• Apply design patterns whereever suitable. Using patterns will help to keep the code readable and will ease modifications and extensions.

• Apply extreme programming techniques whereever appropriate.

  • applying the JUnit "test a little, code a little" cycle will help to deliver high quality code. It will also make refactorings faster and more safe.

  • Refactor often. Will help to improve the quality of our code.

  • Allow user participation. Will help to meet user requirements, will also help to find all kind of bugs and shortcomings.

organization

Let's form a team!

I believe it is important to be aware which roles must be occupied to keep such a project going. Here are those I'm currently aware of (maybe there are more important tasks and roles, but I consider these to be very important):

• designer / developer

• documentator

• code integrator / release manager

The most important thing in a distributed team IMHO is to keep everything in sync. That's why I believe that code integration and release management are of central importance.

What I have learned in the first year of OJB is that it's not enough to define roles. The project members must commit themselves to fulfill certain roles.

Without fixed responsibilities we are lost!

decisions

We will have a lot of ideas. That's good! But how to resolve conflicting ideas / requests / designs ?
It is easy to vote for some intergalactic features if you don't have to do all the hard work.
IMHO all stakeholders should be allowed to utter their ideas, proposals, requests, etc.
But only people that have taken some reponsibility in the team should have voting rights.

tools

Let's use open source tools or free tools that are available to everyone. Here are my favourites:

UML modelling: ArgoUML (www.argouml.org)

Java IDE: Eclipse (www.eclipse.org)

HTML Documentation: StarOffice (www.sun.com/staroffice)

Sourcecode management: CVS (www.cvshome.org)

Build management: ANT (jakarta.apache.org)

Module testing: JUnit (www.junit.org)

next steps

If you want to participate in this adventure please join the OJB JDO developers mailinglist. I suggest to coordinate the work through this list.

I'm looking forward to working with you!

$FOOTER$