ebXML Persistence

This page describes GeoNetwork's implementation of a Persistence Layer to the ebXML Object Model.

---

Introduction

The ebXML Object Model has the capability of being persisted to permanent storage (a database). In order to achieve a vendor-independent code base and to maintain the Object Oriented paradigm in the face of the Relational paradigm employed by databases, we use ​Hibernate as an Object/Relational Mapping tool. Hibernate was chosen over other solutions such as ​EJB 3.0 as that would require a J2EE container for runtime platform. We're not using the Hibernate framework within the confines of the ​JPA specification at this moment, although this is open to debate.

---

Implementation details

Here is a list of design decisions regarding the Hibernate mapping.

Inheritance

The OO notion of inheritance may be expressed in Hibernate using 4 different strategies, see "Java Persistence with Hibernate" by Christian Bauer and Gavin King. They are

• Table per concrete class with implicit polymorphism
• Table per concrete class with unions
• Table per class hierarchy
• Table per subclass

The first strategy creates a different table for each subclass, and those tables all contain (repeat) the properties from the common base class. The Hibernate mapping is unaware of the inheritance relation. The base class definition is thus denormalized. It is impossible to define polymorphic associations and problematic to define polymorphic queries.

The second strategy also employs different tables for each subclass (thus base class columns are denormalized), but now the Hibernate mapping is made aware of the inheritance relation. This allows for polymorphic associations and avoids repeating the base class mapping multiple times in the Hibernate mapping.

The third strategy uses a single table for the base class and all subclasses. The table's columns are a union of all columns of the base and subclasses. This will require that all subclass properties are nullable. In case of larger inheritance structures, this strategy would lead to everything being chucked together in one table.

The fourth strategy is to represent inheritance relationships as relational foreign key associations. Every class/subclass that declares persistent properties—including abstract classes and even interfaces—has its own table. The primary advantage of this strategy is that the SQL schema is normalized. A polymorphic association to a particular subclass may be represented as a foreign key referencing the table of that particular subclass. This seems a preferred strategy but its performance may be detrimental for large class hierarchies as queries require a join across many tables.

At this point the second strategy, "Table per concrete class with unions", has been chosen to map the OO inheritance relations in the ebXML Object Model to the relational database realm.

---

Custom Types

The following classes are represented as Custom Types in the Hibernate mapping:

• Duration

This class represens the xsd:duration type in Java. The source was taken from the Axis project. This class is mapped using a custom Hibernate type that will map an instance to a SQL STRING type using its toString() and Duration(String) methods. So in the database the duration will be stored in the !PnYnMnDTnHnMnS format.