a comparative analysis of object-relational mappings for java

INSTITUTE OF COMPUTING SCIENCEPOZNAN UNIVERSITY OF TECHNOLOGY

University of Applied Sciences at Braunschweig/Wolfenbuettel Institute of Industrial Computer Science

“A Comparative Analysis of Object-relational mappings for Java”

Master Thesis

Sudhakar Pothu

Braunschweig, June 2008

1

A Comparative Analysis of Object-relational mappings for Java

Master Thesis

Sudhakar Pothu30684785

[email protected]

June, 2008

Supervisors:Prof. Dr. rer. nat. Klaus Harbusch

Prof. Dr. Maciej Zakrzewicz

Submitted in partial fulfillment of the requirements for the degreeMaster of Science in Computer Science.

The thesis defense will take place on 11th of July in Poznan at Poznan University of Technology.

University of Applied Sciences Braunschweig/Wolfenbuettel, GermanyPoznan University of Technology, Poznan, Poland

2008

2

mailto:[email protected]

ABSTRACT

While object-oriented programming and high-performance databases are now mainstream,

programmers continue to struggle with persistent storage of objects. Juggling object persistence with

requirements for simplicity, flexibility, maintainability, transparency and scalability can rattle even the

most hardened architect. Especially, in today's Internet-driven multi tier Java applications, the approach

to managing persistent data has been key design decision. This paper examines and does comparative

study on Object-relational mapping technologies for Java. Criteria for comparative analysis has been

defined and study been done on JDBC, ORM frameworks: Hibernate, JPOX JDO and ODBMS db4o

using an example application. This paper will prove useful for persons who are looking to adapt a

persistent strategy for Java application's.

3

Declaration of Honor

I hereby declare in lieu of oath that the work here presented was completed independently by me

without the help of any resource materials other than those stated. The direct and indirect idea taken

from other sources have been labeled as such.

The work has not been previously submitted to any other review board nor has it been released in this

or in any similar form.

Braunschweig, Germany, July 2008.

_____________________________ .Sudhakar Pothu

4

Preface

This study is performed as part of the master's programme in Computer Science during 2007-2008. It

has been very useful and valuable experience and I have learned a lot during the study, not only about

the topic at hand also to manage the work in the specified time. However, this workload would not have

manageable if I had not received help and support from a number of people who I would like to

mention.

First of all, I would like to thank my Professors, Prof. Dr. Maciej Zakrzewicz for giving me his idea for

a comparative analysis on Object-relational mappings for Java and Professor Klaus Harbusch for his

help and supervision during the writing of thesis.

I would also like to extend my gratitude to the people on online communities, especially Hibernate,

JPOX and db4o. Without online communities my research would have been very difficult to be finished

on time.

I have had a wonderful time doing the research and writing this thesis, and I have learned a lot that will

be very valuable in my next step as a programmer.

5

Table of ContentsChapter 1. Introduction............................................................................................................................10

1.1.Objective and Research Question:.................................................................................................111.2.Method:..........................................................................................................................................12

1.2.1. Literature:..............................................................................................................................121.2.2. Model:...................................................................................................................................131.2.3. Case study:............................................................................................................................131.2.4. Comparative study:...............................................................................................................13

1.3.Outline...........................................................................................................................................14Chapter 2. About Object-Relational mapping..........................................................................................16

2.1.Introduction to object:...................................................................................................................162.1.1. Object-oriented programming (OOP):..................................................................................162.1.2. Objects in object oriented programming:.............................................................................172.1.3. Basics of Object-oriented programming:..............................................................................17

2.2.Introduction to Java:......................................................................................................................192.3.Introduction to Databases:.............................................................................................................19

2.3.1. Database management system (DBMS):..............................................................................192.3.2. Relational Database management system (RDBMS):..........................................................202.3.3. Object-oriented database management system (OODBMS):...............................................21

2.4.Introduction to persistence:...........................................................................................................212.4.1. Persistence in Object-oriented applications:.........................................................................222.4.2. Persistence in Java:...............................................................................................................22

2.5.The O/R impedance mismatch:.....................................................................................................232.6.Introduction to Object-relational mapping:...................................................................................242.7.Object-relational mapping (ORM) tools:......................................................................................242.8.Definitions, acronyms and abbreviations:.....................................................................................26

Chapter 3. Comparative analysis criteria.................................................................................................273.1.The ORM comparative analysis criteria:.......................................................................................273.2.Criteria description:.......................................................................................................................30

3.2.1. General criteria:....................................................................................................................303.2.2. ORM specific criteria:..........................................................................................................36

3.3.Chosen ORM candidates:..............................................................................................................423.3.1. JDBC:....................................................................................................................................433.3.2. Hibernate:..............................................................................................................................443.3.3. JPOX (Java persistent objects) JDO:....................................................................................463.3.4. Db4o (Database for objects) ODBMS:.................................................................................47

3.4.Chosen example for ORM candidates implementation:................................................................48Chapter 4. ORM Implementations...........................................................................................................52

4.1.JDBC Implementation:..................................................................................................................524.2.Hibernate Implementation:............................................................................................................584.3.JPOX JDO Implementation:..........................................................................................................644.4.Db4o Implementation:...................................................................................................................72

Chapter 5. Comparative analysis results:.................................................................................................785.1.Comparison of general criteria:.....................................................................................................78

6

5.2.Comparison of ORM specific criteria:..........................................................................................805.3.Comparison of performance:.........................................................................................................88

5.3.1. Use case specific comparison:..............................................................................................885.3.2. CRUD comparison:...............................................................................................................91

5.4.Recommendations and conclusion:...............................................................................................95Bibliography.............................................................................................................................................99Appendix A............................................................................................................................................102

7

Illustration IndexIllustration 1: Thesis outline.....................................................................................................................14Illustration 2: Object-relational mapping architecture.............................................................................24Illustration 3: JDBC Architecture.............................................................................................................44Illustration 4: Hibernate Architecture.......................................................................................................45Illustration 5: JPOX Architecture.............................................................................................................47Illustration 6: RDBMS - db4o's Object Database ...................................................................................48Illustration 7: High level architecture of ATM Banking application........................................................49Illustration 8: High level architecture of Persistence layer......................................................................50Illustration 9: JDBC implementation - Persistence layer class diagram..................................................54Illustration 10: Exceptions class diagram.................................................................................................57Illustration 11: Hibernate implementation - Persistence layer class diagram..........................................63Illustration 12: JPOX JDO implementation - Persistence layer class diagram........................................71Illustration 13: Db4o implementation - Persistence layer class diagram.................................................76Illustration 14: administrator use case – performance comparison chart.................................................89Illustration 15: User use case - performance comparison chart...............................................................90Illustration 16: Write - comparison chart.................................................................................................91Illustration 17: Read comparison chart....................................................................................................92Illustration 18: Update comparison chart.................................................................................................93Illustration 19: Delete - performance comparison chart...........................................................................94Illustration 20: User use case diagram...................................................................................................105Illustration 21: Administrator use case diagram.....................................................................................106Illustration 22: ATM banking application Domain class diagram..........................................................107Illustration 23: ATM banking application EER diagram........................................................................108

8

Index of TablesTable 1: Definitions, acronyms and abbreviations...................................................................................26Table 2: Comparison criteria....................................................................................................................30Table 3: Chosen ORM tools for comparative analysis.............................................................................43Table 4: Tools used for implementation...................................................................................................51Table 5: Comparison of general criteria...................................................................................................80Table 6: Comparison of ORM specific criteria........................................................................................87Table 7: administrator use case performance comparison........................................................................89Table 8: User use case - performance comparison...................................................................................90Table 9: Create objects performance comparison....................................................................................91Table 10: Read objects performance comparison.....................................................................................92Table 11: Update objects performance comparison.................................................................................93Table 12: Delete objects - performance comparison................................................................................94

9

Introduction

Chapter 1. Introduction

Today's Internet-driven view of information systems is helping to popularize Java as an application

development language. Developers are extensively using Java to create multi tier application

architectures that often integrate relational data stores with new data types, in order to package

information in easier-to- use, dynamic ways. Java's object-oriented nature is ideally suited to this new

world. Using objects, Java developers can encapsulate both data and data manipulation methods to give

applications a runtime dynamism and self-contained intelligence that is difficult to achieve using other

methods. Java application developers need to be able to store these Java objects-technically, to give

them persistence-in order to take advantage of these capabilities.

The approach to managing persistent data has been a key design decision in every Java software

project. For several years, persistence has been a hot topic of debate in the Java community. Many

developers don’t even agree on the scope of the problem. Is persistence a problem that is already solved

by relational technology and extensions such as stored procedures, or is it a more pervasive problem

that must be addressed by special Java component models, such as EJB entity beans? Should we hand-

code even the most primitive CRUD (create, read, update, delete) operations in SQL and JDBC, or

should this work be automated? How do we achieve portability if every database management system

has its own SQL dialect? Should we abandon SQL completely and adopt a different database

technology, such as object database systems? Debate continues, but a solution called object-relational

mapping (ORM) now has wide acceptance.

In this Master thesis paper, I examine the development issues surrounding Java object storage,

including a brief overview of the JDBC, Java API for executing SQL statements, Object-relational

10

Introduction

mapping, a solution that adds object persistence to Java and also Object oriented databases. I compare

object persistence in a example Java application with couple of Object-relational mapping tools, with

Object-oriented database and also the much greater level of effort required to implement the same

application using the lower level JDBC interface, which supports Java object storage in relational

databases. This thesis is helpful for those interested in using Object-relational mapping tools, such it

gives an idea of what to look for in an Object-relational mapping tool.

1.1. Objective and Research Question:

There are many Object-relational mapping tools that exist in market today that map relational databases

into Java-object models. This Master thesis paper provides an understanding of what Object-relational

mapping is? with comparison analysis and technical review of couple of popular ORM projects in the

market as of today namely, Hibernate and JPOX JDO. It is hoped that this will prove useful to anyone

who is working on Java platform, databases and trying to select a tool that does Object-relational

mapping.

The key contribution of this paper is to discuss the core technical problems that need to be

solved in Object-relational mapping scenario, and then classify the Object-relational mapping tools

according to how they attempt to solve these problems. It is therefore focused on the general design of

each tool, specific performance and reliability issues. Most of the analysis is based on direct experience

using each tool, testing performance and based on reading product documentation.

The research question addressed in this thesis is the following:

“Is ORM framework a replacement for JDBC, how to select an Object-relational mapping tool

which is suitable for the Java project in Hand, and can relational databases be replaced with

Object-oriented databases”

To answer this question, the following subquestions are used:

11

Introduction

● What is mismatch problem

● What are the challenges in using JDBC as persistence solution

● Are there characteristics that make Object-relational mapping tool unique that are relevant to a

particular Java-project, and if so, what are they?

● Which criteria can be defined for Object-relational mapping tool selection and evaluation?

● What are the advantages in using ODBMS

In order to answer these questions the subject of Object-relational mapping should be studied throughly

and also Object-relational mapping tool market will be studied using literature and information from

the Internet. With this knowledge a model for Object-relational mapping tool evaluation is created

that will give insights into the unique characteristics of Object-relational mapping tool relevant to

those who intend to use it. This model should give an answer to the question which ORM tool should

be used in a software project. To give experimental results not only the theoretical study is enough but

an example must be implemented with JDBC, on chosen ORM tools and with an ODBMS.

1.2. Method:

The method used to construct this thesis consists of four parts: literature study, construction of the

Model (comparative analysis criteria), case study (implementation of ORM candidates on example) and

the Comparative study itself.

1.2.1. Literature:

Comparison analysis of Object-relational mapping tools is a relatively new field of study in the

academic world. The number of articles written on the subject is not high. To start the literature study,

general Object-relational mapping articles and information is used to get a good global idea of Object-

relational mapping. This literature will also be the basis for the first chapter. In order to establish the

criteria for the comparative analysis, literature on comparing Object-relational mapping tools such as

Hibernate and JPOX JDO are consulted. Because scientific literature from the academic libraries may

12

Introduction

not offer enough to complete the research, other sources need to be explored as well, by using search

engines on the Internet, for example. Of course the validity of non-scientific resources is verified.

1.2.2. Model:

From the literature mentioned above, the Comparison analysis criteria are identified. These will be the

key terms of the evaluation model for Comparison analysis of Object-relational mapping tools. The

model consists of two parts. The first part describes the background of the criteria, what effect they

have on the Object-relational mapping tool and why they are important. In the second part the

evaluation process is described, explaining the method for identifying the key values for each criterion.

1.2.3. Case study:

The case study will be performed on ATM Banking application. This application category was chosen

because it concerns reasonably large applications, targeted at institution wide use at banking

institutions, which warrants a full evaluation. A list of requirements is constructed using websites on

Banking applications. This application's persistence layer will be developed using each ORM

candidate. A step by step process implementation will be described and the model created in the

previous step will be followed to identify the symptoms of these candidate tools.

1.2.4. Comparative study:

The comparative study is based above three steps. The criteria formed will be analyzed for each ORM

candidate, this analysis is based on literature, experience and experimentation during case study. Both

general criteria and ORM specific criteria will be elaborated for each ORM candidate in tabular form

for easy examining. A special comparison will be done on performance using the test execution times

of each unit test performed during case study.

13

Introduction

1.3. Outline

Figure 1 gives a graphical representation of the structure of this thesis.

Chapter 2 is an introduction to Object-relational mapping, including the Object-relational mapping

tools. In chapter 3 the criteria for evaluation is discussed, starting by a description of the criteria in

section 3.2, followed by a description of general criteria in section 3.2.1 and the ORM specific criteria

14

Illustration 1: Thesis outline

Introduction

in 3.2.2. A description of chosen ORM candidates is given in 3.3 followed by the description of

example taken in 3.4. In chapter 4 the ORM implementation on example are explained step by step.

Section 4.1 is dedicated for JDBC implementation, followed by Hibernate implementation in 4.2, JPOX

JDO implementation in 4.3 and Db4o implementation in 4.4. Finally, the Comparative study is done in

chapter 5, for general criteria is done in 5.1, followed by ORM specific criteria in 5.2 and comparison

of performance in 5.3. In section 5.4, recommendation and conclusion answers the research question in

1.1, and also gives recommendations for further research.

15

Introduction

Chapter 2. About Object-Relational mapping

As the topic stated on cover page “A Comparative analysis of Object-relational mappings for Java”

this paper deals on the subject matter called Object-relational mapping and some tools that are present

in market at this present moment to deal with this subject. As you read along this chapter you will

understand each and every word that is used in the stated topic and the research topic that is formed by

combination of these words.

2.1. Introduction to object:

In computer science an Object is a discrete item that can be selected and maneuvered. In its simplest

embodiment, an object is an allocated region of storage.

2.1.1. Object-oriented programming (OOP):

Object-oriented programming (OOP) is a programming language model organized around "objects"

rather than "actions" and data rather than logic. Historically, a program has been viewed as a logical

procedure that takes input data, processes it, and produces output data. The programming challenge was

seen as how to write the logic, not how to define the data. Object-oriented programming takes the view

that what we really care about are the objects we want to manipulate rather than the logic required to

manipulate them.

16

About Object-Relational mapping

The first step in OOP is to identify all the objects you want to manipulate and how they relate to

each other, an exercise often known as data modeling. Once you've identified an object, you generalize

it as a class of objects and define the kind of data it contains and any logic sequences that can

manipulate it. Each distinct logic sequence is known as a method.

2.1.2. Objects in object oriented programming:

As stated above in object-oriented programming, an object is an instance (or instantiation) of a class.

The class object contains a combination of data and the instructions that operate on that data, making

the object capable of receiving messages, processing data, and sending messages to other

objects. Therefore an object facilitates for

● data members that represent the data associated with the object.

● methods that access the data members in predefined ways.

Examples of objects range from human beings (described by name, address, and so forth) to

buildings and floors (whose properties can be described and managed) down to the little widgets on

your computer desktop (such as buttons and scroll bars).

2.1.3. Basics of Object-oriented programming:

Object-oriented modeling techniques are concerned with (primarily) behavior. It is beyond the scope of

this paper to explain all about Object-Oriented programming, but I tried to explain some basic terms

which are used in Object-oriented modeling in this section. They are the following:

Class:

A class is a user-defined data type that defines a collection of objects that share the

same characteristics.

Object:

17


A particular object, an instance of a class.

Instance:

A member of a class, one can have an instance of a class or a particular object.

Method:

A method is the processing that an object performs. When a message is sent to an

object, the method is implemented. In other terms it is an object's abilities.

Message passing:

Message passing is the process by which an object sends data to another object or asks

the other object to invoke a method.

Inheritance:

Inheritance is the ability of one class of objects to inherit properties from a higher class.

‘Subclasses’ are more specialized versions of a class, which inherit attributes and behaviors

from their parent classes, and can introduce their own

Encapsulation:

Encapsulation refers to the bundling of data with the methods that operate on that data,

it conceals the functional details of a class from objects that send messages to it.

Abstraction:

Abstraction is the process of generalization by reducing the information content of a

class, which means simplifying complex reality by modeling classes appropriate to the

problem, and working at the most appropriate level of inheritance for a given aspect of the

problem.

Polymorphism:

Polymorphism refers to the ability to process objects differently depending on their data

type or class. More specifically, it is the ability to redefine methods for derived classes.

Polymorphism allows you to treat derived class members just like their parent class members.

More precisely, Polymorphism in object-oriented programming is the ability of objects

belonging to different data types to respond to method calls of methods of the same name, each

one according to an appropriate type-specific behavior.

18


2.2. Introduction to Java:

Java is a high-level Object-oriented programming language, influenced in various ways by C, C++, and

Smalltalk, with ideas borrowed from other languages as well. Its syntax was designed to be familiar to

those familiar with C-descended "curly brace" languages, but with arguably stronger OO principles

than those found in C++, static typing of objects, and a fairly rigid system of exceptions that require

every method in the call stack to either handle exceptions or declare their ability to throw them.

Garbage collection is assumed, sparing the developer from having to free memory used by obsolete

objects.

A typical Java program creates many objects, which as you know (by above), interact by

invoking methods through these object interactions, a program can carry out various tasks, such as

implementing a GUI, running an animation, sending and receiving information over a network or

storing the information. Once an object has completed the work for which it was created, its resources

are recycled for use by other objects.

2.3. Introduction to Databases:

A database is a collection of information that is organized so that it can easily be accessed, managed,

and updated. In one view, databases can be classified according to types of content: bibliographic, full-

text, numeric, and images. In computing, databases are sometimes classified according to their

organizational approach.

2.3.1. Database management system (DBMS):

Database management system (DBMS) is a collection of programs that enables you to store, modify,

and extract information from a database. There are many different types of DBMS's, ranging from

small systems that run on personal computers to huge systems that run on mainframes. A DBMS

19


includes:

● A modeling language to define the schema of each database hosted in the DBMS, according to

the DBMS data model.

● Data structures (fields, records, files and objects) optimized to deal with very large amounts of

data stored on a permanent data storage device (which implies relatively slow access compared

to volatile main memory).

● A database query language and report writer to allow users to interactively interrogate the

database, analyze its data and update it according to the users privileges on data.

● A transaction mechanism, that ideally would guarantee the ACID properties, in order to ensure

data integrity, despite concurrent user accesses (concurrency control), and faults (fault

tolerance).

2.3.2. Relational Database management system (RDBMS):

Relational database management system is a type of DBMS that stores data in the form of related

tables. Relational databases are powerful because they require few assumptions about how data is

related or how it will be extracted from the database. As a result, the same database can be viewed in

many different ways.

An important feature of relational systems is that a single database can be spread across several

tables. This differs from flat-file databases, in which each database is self-contained in a single table.

RDBMS consists of guidelines such as the avoidance of duplicating data using a technique called

normalization and how to identify the unique identifier for a database record. Almost all full-scale

business database management system's (DBMS), including Oracle, DB2, SQL Server, MySQL, etc., is

a relational DBMS (RDBMS).

A RDBMS is basically based on the relational model as introduced by E. F. Codd in 1969. The

relational model for database management is a database model based on predicate logic and set theory

20


with aims that included avoiding, without loss of completeness, the need to write computer programs to

express database queries and enforce database integrity constraints. The word "Relation" is a

mathematical term for "table", and thus "relational" roughly means "based on tables". It did not

originally refer to the links or "keys" between tables, contrary to popular interpretation of the name.

Most popular commercial and open source databases currently in use are based on the relational model.

However, many of the early implementations of the relational model did not conform to all of Codd's

rules, so the term gradually came to describe a broader class of database systems. At a minimum, these

systems:

• presented the data to the user as relations (a presentation in tabular form, i.e., as a collection of

tables with each table consisting of a set of rows and columns.

• provided relational operators to manipulate the data in tabular form.

2.3.3. Object-oriented database management system (OODBMS):

An object-oriented database management system (OODBMS), sometimes shortened to ODBMS for

object database management system), is a database management system (DBMS) that supports the

modeling and creation of data as objects. This includes some kind of support for classes of objects and

the inheritance of class properties and methods by subclasses and their objects. There is currently no

widely agreed-upon standard for what constitutes an OODBMS, and OODBMS products are

considered to be still in their infancy. But the fact is that OODBMS technology is the perfect match for

using in OO development environment is obvious from the very name. Though RDBMS has a wide

support in tools and methods of using in OO environment there will always be an overhead of the

translation from the object to relational world, commonly known as object-relational impedance

mismatch.

2.4. Introduction to persistence:

In computer science, persistence refers to the characteristic of data that outlives the execution of the

21


program that created it. Almost all applications require persistent data. Persistence is one of the

fundamental concepts in application development. If an information system didn’t preserve data when

it was powered off, the system would be of little practical use.

2.4.1. Persistence in Object-oriented applications:

In an object-oriented application, persistence allows an object to outlive the process that created it. The

state of the object may be stored to disk and an object with the same state re-created at some point in

the future. This application isn’t limited to single objects—entire graphs of interconnected objects may

be made persistent and later re-created in a new process.

2.4.2. Persistence in Java:

Most Java applications involve creating, storing, and searching data in some form; in other words: use a

database (mostly RDBMS). This is referred to as persisting data often called CRUD, for Create, Read,

Update, and Delete. Databases are integral parts of almost all Java computing systems. The approach to

managing persistent data is a key design decision in every Java project. Given that persistent data isn’t

a new or unusual requirement for Java applications, you’d expect to be able to make a simple choice

among similar, well-established persistence solutions.

For several years, persistence has been a hot topic of debate in the Java community. Many

developers don’t even agree on the scope of the problem. Is persistence a problem that is already solved

by relational technology and extensions such as stored procedures, or is it a more pervasive problem

that must be addressed by special Java component models, such as EJB entity beans? Should we hand-

code even the most primitive CRUD (create, read, update, delete) operations in SQL and

JDBC, or should this work be automated? How do we achieve portability if every database

management system has its own SQL dialect? Should we abandon SQL completely and adopt a

different database technology, such as object database systems? Debate continues, but a solution called

object/relational mapping (ORM) now has wide acceptance.

22


2.5. The O/R impedance mismatch:

The object-oriented paradigm is based on proven software engineering principles. The relational

paradigm, however, is based on proven mathematical principles. Because the underlying paradigms are

different the two technologies do not work together seamlessly. The impedance mismatch becomes

apparent when you look at the preferred approach to access: With the object paradigm you traverse

objects via their relationships whereas with the relational paradigm you join the data rows of tables.

This fundamental difference results in a non-ideal combination of object and relational technologies. To

succeed using objects and relational databases together you need to understand both paradigms, and

their differences, and then make intelligent tradeoffs based on that knowledge. [ADTSA06]

The following are the common mismatches between both paradigms:

● The problem of granularity

● The problem of subtypes (inheritance, polymorphism)

● The problem of identity

● Problems relating to associations

● The problem of data navigation

23


2.6. Introduction to Object-relational mapping:

Object-relational mapping is a programming

technique for converting data between

incompatible type systems in relational databases

and object-oriented programming languages. It

mediates the application’s interaction with a

relational database, leaving the developer free to

concentrate on the business problem at hand. As

shown in Illustration 2, an object relational

mapper sits between the object model used by an

application and the relational model used by a

conventional RDBMS system. It's a useful piece

of software, as it allows one to blend the best of

both worlds. The application can be written in

terms of objects, and the database can be managed

using conventional tools.

2.7. Object-relational mapping (ORM) tools:

An Object-relational mapping (ORM) tool is an implemented ORM framework that performs a way of

automatically mapping normal Java objects to an SQL database. In other words, it loads, searches, and

saves your data model objects. Rather than writing cumbersome SQL insert, update, and select

commands, the framework will take care of the boilerplate code through some kind of automation.

Object-relational mapping tools establish a bidirectional link with data in a relational database and

24

Illustration 2: Object-relational mapping architecture


objects in code, based on a configuration and by executing SQL queries (dynamic most of the time) on

the database.

An ORM tool solves the difficult problem of storing objects in a relational database. You tell the

framework how your domain model maps to the database schema, and it takes care of getting your

objects in and out of the database. This enables you to focus on solving your business problems rather

than writing lots of low-level database access code. The key features of an ORM framework are as

follows:

● Declarative mapping between the object model and database schema—Describes how the

object model’s classes, attributes and relationships are mapped to database table and columns

and used by the ORM framework to generate SQL statements

● An API for creating, reading, updating, and deleting objects—Called by the domain model’s

repositories to manipulate persistent data

● A query language—Used to efficiently find persistent objects that satisfy search criteria

● Support for transactions—Maintains data integrity and handles concurrent updates

● Lazy and eager loading—Optimizes performance by controlling when objects are loaded

● Caching—Improves performance by minimizing database accesses

● Detached objects—Enables persistent objects to be passed between the presentation tier and the

business tier

There are both free and commercial tools available in market today that perform object-

relational mapping. Below you see some of the well known ones,

• Cayenne, apache, open source for java

• Ebean, open source ORM Framework

• Enterprise Objects Framework, Mac OS X/Java, part of Apple WebObjects

• Hibernate, open source ORM Framework, widely used

• iBATIS, maintained by ASF, and with .NET port.

25


• Java Data Objects (JDO)

• JPOX, open source JDO 2 reference implementation

• Kodo, commercial implementation of both the JDO and JPA API.

• OpenJPA, apache, open source, supports JPA API.

• TopLink by Oracle

• WebObjects commercial from Apple, includes EOF as the object-relational mapping layer

In particular, Hibernate has become the de facto ORM. Hibernate is an ambitious project that

aims to be a complete solution to the problem of managing persistent data in Java. It mediates the

application’s interaction with a relational database, leaving the developer free to concentrate on the

business problem at hand.

2.8. Definitions, acronyms and abbreviations:

ORM Object Relational MappingSQL Structured Query LanguageDDL Data Definition LanguageDML Data Manipulation LanguageRDBMS Relational Database-Management-SystemODBMS Object-oriented database management systemDB DatabaseAPI Application Programming Interface GUI Graphical User InterfacePOJO Plain Old Java Object

CRUD Create/retrieve/update/delete XML Extensible Mark-up LanguageXSD XML Schema DefinitionMetadata Data that describes data ( or in other terms structured data which

describes the characteristics of a resource)EER Enhanced Entity-Relationship IDE Integrated Development EnvironmentGPL General public licenseGNU, LGPL Lesser General Public License

Table 1: Definitions, acronyms and abbreviations

26


Chapter 3. Comparative analysis criteria

In this chapter, a model criteria is proposed for comparative analysis of Object-relational mappings

using an approach adopted to the general and unique characteristics of Object-relational mapping tools.

The criteria that are used were derived from Object-relational mapping literature, among which

are three articles giving advice on criteria for selecting Object-relational mapping tool. These sources

are discussed in the next section. In order to understand their importance and value, the section 3.2

gives a description of each criterion. The comparative analysis is done on chosen candidates, in section

3.3 the chosen ORM candidates are described with the reason of why they were chosen. The evaluation

process, consisting of an example Java application is described in section 3.4 with the tools used for

implementation.

3.1. The ORM comparative analysis criteria:

The criteria for the Comparative analysis of ORM were established using Object-relational mapping

literature on the subject of Object Relational Tool Comparison. Because scientific literature is still

somewhat scarce on the subject, web searches were needed to find the required resources. The web

searches were done to find the most prominent articles on Object Relational Tool Comparison, Object

Relational Tool success factors and Object Relational Tool evaluation. Three articles giving advice on

criteria for selecting Object-relational mapping tool were found. In order to identify the criteria that

give a good general idea of the Object-relational mappings that needs to be evaluated, all criteria were

listed and the terms covering the same areas were grouped together. The criteria that were mentioned in

27

Comparative analysis criteria

some way in at least three sources were included in this model. The three sources are

listed below.

I. “Choosing an object-relational mapping tool” by Fabrice Margueriehttp://madgeek.com/Articles/ORMapping/EN/mapping.htm (Retrieved on May 05, 2008)

II. Object Relational Tool Comparisonhttp://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison (Retrieved on May 05, 2008)

III. “How-To-Select an Object-Relational Mapping Tool for .NET” by By Jason Mauss

http://www.howtoselectguides.com/dotnet/ormapping/#dal (Retrieved on May 05, 2008)

The criteria is divided into two sections General and ORM specific. General section is criteria

applicable to any software and ORM specific criteria is applicable to ORM tools. The following table

list the general criteria and ORM specific criteria in two adjacent columns. Later in section 3.2 each

criteria is explained in detail.

28

http://www.howtoselectguides.com/dotnet/ormapping/#dal

http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

http://madgeek.com/Articles/ORMapping/EN/mapping.htm


General Criteria ORM specific Criteria

● Performance● Resource consumption● Complexity (or simplicity...)● Ease of use, time to be up and running● Flexibility● Documentation● Maturity or Longevity● Frequency of the updates, bug fixes,

evolutions● Support (forums, community)● Vendor's reputation and stability● Source code provided (or not)● Support for multiple platforms● Price

Basic features

• Inheritance• Relations• Transactions• Aggregations• Grouping

Extended features• Supported databases• query language

Flexibility• Customization of queries• Support for SQL joins• Concurrency management• Data type support for RDBMS• Single class to multiple tables• single table to multiple objects

Assistance, ease of use• GUI to set up the mapping• Generation of the classes• Generation of the database schema

Optimizations, performance, design:• Global performance• Lazy loading• Caching• Optimized queries• Handle circular references• Handle cascade updates• Bulk updates or deletions

Evolution, compatibility• Maintainability• Possibility to move to a new mapping tool• Serialization• Distributed objects

Additional features• Freedom in the design of the classes• Less constraints as possible on the database

schema• State information on data• External mapping file• Support for disconnected mode• Interceptors and delegation mechanisms• Support for stored procedures

29


• constraints handling• Filtering objects in memory• Deferred operations cache

Table 2: Comparison criteria

3.2. Criteria description:

The criteria are each described in the following subsections, giving background information and

explaining why the criterion is important for comparative analysis.

3.2.1. General criteria:

The general criteria are each described in the following subsections, giving background information

and explaining why the criterion is important. The following criteria are not ORM specific it is

common to the selection of any piece of software.

● Performance: One of the most difficult things in enterprise application development is

guaranteeing performance and scalability of an application. Performance is usually considered

to be the reaction time of a request/response based application. If you click a button, you expect

a response in half a second. Or, depending on the use case, you expect that a particular event (or

batch operation) can be executed in a reasonable time frame. Naturally, reasonable depends on

the case and usage patterns of some application functionality. (JPHBK08)

A performance bottleneck can be anything you consider a programming mistake or bad design

—for example, the wrong fetching strategy, a wrong query, or bad handling of the session

and persistence context. Testing a system for reasonable performance is usually part of the

acceptance tests. In practice, performance testing is often done by a dedicated group of end

user testers in a lab environment, or with a closed user group in real-world conditions. Pure

automated performance tests are rare.

You can also find performance bottlenecks with an automated scalability test; this is the

30


ultimate goal. Stress and load tests must consider the following rules:

Test performance with real-world data sets: Test data should be as close as possible to the data

the system will work on in production, with the same amount, distribution, and selectivity. Test

must not be performed with a data set that can fit completely into the cache of a hard disk on the

database server.

Test performance with real use cases: If your application has to process complex transactions

(for example, calculating stock market values based on sophisticated statistical models), you

should test the performance of the system by executing these use cases. Analyze your use cases,

and pick the scenarios that are prevalent—many applications have only a handful of use cases

that are most critical. Avoid writing micro benchmarks that randomly store and load a few

thousand objects; the numbers from these kinds of tests are meaningless.

● Resource consumption (memory): How a piece of software impacts on your IT infrastructure

depends on a lot of factors – some are foreseeable, some are not. You may know what the load

on your network is now, and how many people will be using the software to start off with, but it

can be very difficult to predict how things will happen in the future. How will your network

expand? Will you employ more people? What other software will the company use? What

processes will be running on different machines? How will your users’ habits change?

Applications using an object/relational persistence layer are expected to outperform applications

built using direct JDBC because of the potential for caching. Caching in turn cause memory

consumption, therefore this is an important criteria for comparative analysis for Object-

relational mapping.

For applications accessing data that does not change frequently or only needs read-only access,

caching can play an important role. Different methods of caching can be employed among O/R

Mappers like a disk-based cache or in-memory. Additionally, some O/R Mappers can cache the

31


object-relational mapping information in order to remove the need for accessing the mapping

file repeatedly. As one of the most important requirements for implementing an O/R Mapping

component is that there be no loss of performance, caching can make a big difference in

whether your performance requirements are met or not.

● Complexity (or simplicity...): complexity is a measure of the resources expended by a system

while interacting with a piece of software to perform a given task. If the interacting system is a

computer, then complexity is defined by the execution time and storage required to perform the

computation. If the interacting system is a programmer, then complexity is defined by the

difficulty of performing tasks such as coding, debugging, testing, or modifying the software.

The term software complexity is often applied to the interaction between a program and a

programmer working on some programming task. [KSTGASCM86]

● Ease of use, time to be up and running: Most organizations rank ease of use as a high priority

on their list of criteria. One of the most compelling reasons one software package is selected

over competing products is the ease-of-use issue. This is true because many people with varying

skill levels throughout the organization must use the planning tool. Employing an easy-to-use

software tool does not require that the user possess a great deal of specialized knowledge nor

training to produce the end product. That is to say, ease of use is a characteristic attributable to

the process of using a software tool. The tool is graded on the simplicity of its use. Therefore,

ease of use is a process issue. Ease of use is not an end product issue. The end product produced

by the software tool cannot be attributed the characteristic, ease of use. A product issue focuses

on the end result, the plan, not how the plan was processed. [GEOUS08]

● Flexibility: Flexibility has been recognized as a desirable quality of software since the earliest

days of software engineering. Object-oriented programming (OOP) is hailed, among other

reasons, for promoting flexibility. Experienced programmers, however, observe that object-

oriented mechanisms such as inheritance and dynamic binding make programs more flexible

32


only towards the particular shifts they specifically were tailored to accommodate. For example,

it has been established that gratuitous use of inheritance may lead to the problem of ‘fragile

base class’ and yield highly inflexible programs. [EMMSF05]

● Documentation: Using a mapping tool is not always a snap. Check the quality of the

documentation and the provided samples.

There are two main types of documentation [KBOSE05]

I. User documentation

II. Developer documentation

User documentation contains all documents that describe how to use the system. For certain

applications there can be different levels in the user documentation, corresponding with

different user levels and rights. For example, many applications that have an administrator role,

have a separate piece of documentation for administrators. Additionally, there can be various

user-contributed tutorials and How-To, be it on the project’s website or elsewhere.

The other main type of documentation, which plays a much larger role in Open Source

software than in proprietary applications, is developer documentation. A voluntary

decentralized distribution of labor could not work without it. The developer documentation

concerns separate documents on how to add or change the code, as well as documentation

within the source code, by way of comments. The comments usually explain what a section of

code does, how to use and change it and why it works like it does. Though this type of

documentation may exist for proprietary software, it is usually not public to have access to it.

Documentation is often lagging behind the status of the application, since especially

user documentation is often written only after functionality is created.

33


● Maturity or Longevity: Many tools are relatively new, and are still not mature. Some are still

at the beta level, or even alpha.

The longevity of a product is a measure of how long it has been around. It says something

about a project’s stability and chance of survival. A project that is just starting it usually still full

of bugs. The older a project, the less likely the developers will suddenly stop. But age is not

always a guarantee of the chance of survival. First of all, very old software may be stuck on old

technologies and methods, from which the only escape is to completely start over. Some

software has already successfully gone through such a cycle, which is a good sign in terms of

maturity. One thing that needs to be taken into account when products are not very young is

whether or not there is still an active community around it.

● Frequency of the updates, bug fixes, evolutions: The age and activity level of project are

often related. Young projects often have a higher activity level than older ones, because once a

project has stabilized and is satisfactory to most users, the discussions are less frequent and

releases are smaller, containing mostly bug and security fixes. This doesn’t mean that the

activity should ever be slim to none. As mentioned before, no project is ever static. There’s

always something that still needs to be done.

● Support (forums, community): ‘One of the most important aspects of open source tools is the

community’ [KBOSE05]

The user community of an open source ORM project consists of the people that use the

software and participate in some way. One way of participating is by filing bug reports, which

is a report on a problem in the software. This could be something very small, like a typing error

in the text, or something large, like a feature that does not work properly. Another way is giving

feedback on functionality the user would like to be added. Some users turn into developers over

time, and participate in things such as fixing bugs or adding functionality themselves. They

cross the line to the developer community, which is often a line made very thin by encouraging

participation and making the developer community accessible to anyone who is interested. In

34


some cases the user and developer community interact fully in the same discussion areas. The

community of an Open Source project is very important because it is the community that does

most of the testing and provides quality feedback. Instead of using financial resources to put the

software through extensive testing and Quality Assurance(QA), like a proprietary vendor will

do, the Open Source ORM projects have the community as a resource. The more people are

interested in a project, the more likely it is that it will be active and keep going. A large and

active community says something about the acceptance of the tool. If the software was not good

enough to use,there would not be so many people who cared about its development.

There are two types of support for a software product. [KBOSE05]

I. Usage support – the answering of questions on the use of the software

II. Failure support or maintenance – the solving of problems in the software

Often the two get mixed at some level because users do not always know the right way to use

the product. Their support request will start as a problem report and later becomes part of usage

support. The way support is handled is a measure of how seriously the developers work on the

software. One way to check this is to see if there is a separate bug tracker for the software, and

how actively it is being used by both the developers and the users. When the developers use it

but hardly any users seem to participate, the users may not be pointed in the right direction to

report problems. Aside from community support, larger or more popular projects may have paid

support options. The software is free to use, but the user has the option to get professional

support for a fee, either on a service agreement basis where a subscription fee is payed for a

certain period of time, or a per incident fee for each time the user calls on support. The project

leaders themselves may offer something like this, which is the case for the very popular Open

Source database server MySQL (MySQL, 2005). There are companies that offer specialised

support for certain Open Source software. This is called third party support. For example, at the

Mozilla Support web page, it can be seen that DecisionOne offers paid support for Mozilla’s

popular web browser FireFox, the e-mail client Thunderbird and the Mozilla Suite (Mozilla,

2005). The fact that paid support exists for a Open Source product, especially third party

support, is a sign of maturity and a sign the product is taken seriously.

35


● Vendor's reputation and stability: This is a big problem today. There are a lot of tools, but

natural selection is constantly at work. Which products will still be there tomorrow? Some have

already fallen. Time will probably continue to eliminate some actors in this very competitive

market.

● Source code provided (or not): (important in case the vendor disappears)

● Support for multiple platforms: (Java and .NET? Windows and Linux?RDBMS and

ODBMS?)

● Price: This may not be an important criteria for open source ORM tools, as they are free. But if

you can spend some money there are many tools which can ease and speed up development

steps which is unimaginable by open source free tools.

3.2.2. ORM specific criteria:

The criteria specific to ORM are each described in the following subsections, giving background

information and explaining why the criterion is important for ORM. This criteria is mentioned

especially to compare ORM tools like Hibernate and JPOX JDO.

Basic features:● Transparent Persistence : The automatic mapping of Java objects with database tables and

vice versa is called Transparent Persistence.

● Inheritance: Inheritance is one of the core concepts in OO programming, but supporting

inheritance in your relational database requires you to make some tough decisions.

Implementing an ORM requires support for some or all of those decisions. ORM should handle

inheritance, create hierarchies between entities, and use polymorphism (we are using objects!).

The tools can support a variety of combinations for tables and classes to allow these

36


mechanisms.

● Relations: There are two types of relations in database design: one-to-many and many-to-many.

In a one-to-many relation, multiple rows in one table usually have a reference to a single row in

another table (or quite possibly the same table, depending on the design). When using an ORM

tool relations between multiple entities are typically resolved directly by means of associations,

which are defined within your metadata that will map the entities classes to the underlying

persistence unit. Inside your classes, those associations are usually represented as fields (or

properties) which reference either a single related entity or a whole collection of related entities.

A good ORM should Handle any type of relations (1-1, 1-n, n-n).

● Transactions: Transactions allow you to set the boundaries of a unit of work: an atomic group

of operations. They also help you isolate one unit of work from another unit of work in a

multiuser application. While I might qualify transactions as comparatively unimportant, anyone

who’s written a multi-user web application knows how significant they can be in maintaining

data integrity. An ORM which didn’t support transactions would be sorely crippled indeed.

● Aggregates: By their very nature, our databases contain a lot of data, oftentimes, we're

interested in summarizing our data to determine trends or produce top-level reports. SQL

provides aggregate functions such as SUM, AVG, MIN, MAX, COUNT to assist with the

summarization of large volumes of data. A typical ORM query language should support

aggregate functions which are most commonly used for reporting and other things.

● Grouping (SQL's GROUP BY): GROUP BY was added to SQL because aggregate functions

(like SUM) return the aggregate of all column values every time they are called, and without the

GROUP BY function it was impossible to find the sum for each individual group of column

values. Hence it is an essential criteria for ORM.

Extended features:● Supported databases: A big advantage of mapping tools is that they provide an abstraction of

37


the underlying database engine. Most of them allow switching easily between RDBMS's

(Relational Database Management Systems). Your application does not even know what the

database is; its only connection to it is via the ORM framework and the JDBC driver. This

means that your development environment can be a cheaper version of the production

environment (as in, using an open source database for development would save you all that

Oracle development licenses cash), and that you can confidently upgrade database versions

without expecting to have to modify the application at all.

● Query language (OQL - Object Query Language): We very frequently have to execute dynamic

queries. It's the case at least with searches based on filters. It is important to be able to use a

powerful query language. ORM should be equipped with a powerful query language that

understands notions like inheritance, polymorphism and association.

Flexibility:● Customization of queries: We often need to go beyond what is possible with the provided

query language. In these cases, we need to be able to provide custom SQL queries. HQL, which

is a strong point of Hibernate, allows for this. We could also wish a dynamic mapping to be

possible from developer provided SQL queries.

● Support for SQL joins: Support any type of SQL joins (inner join, outer join)

● Concurrency management (support for optimistic and pessimistic approaches)

● Data type support for RDBMS: Support for the data types specific to the database

management system (identity columns, sequences, GUIDs, auto increments).

● Single class to multiple tables: Be able to map a single object to data coming from multiple

tables (joins, views). Most of the tools handle a direct mapping of a class to one table. We often

need more.

38


● Be able to dispatch the data from a single table to multiple objects.

Assistance, ease of use:● GUI to set up the mapping. Such a graphical tool presents the relational data model and lets

you specify the objects to be created or at least the links between the objects and the tables.

● Generation of the classes: This can speed up the development, even if in a lot of cases we

prefer to map the database to hand-coded classes or to classes generated from UML for

example. Check which scenarios are supported by the tools.

● Generation of the database schema. Some tools work only with a database they generated.

This can be a big constraint, especially if you have to work with a legacy database of course!

Otherwise, it all depends on whether you are an expert in database modeling, or if you prefer

not to have to deal with the database schema. If you have a DBA who takes care of your

databases, or if you prefer to design them by yourself, be sure to select a mapping tool that

doesn't require its own data model.

Optimizations, performance, design:● Global performance (good implementation of the object-relational mapping concept)

● Lazy loading (the loading of some data is deferred until it's needed)

• for the data through relations

• for some columns. When we want to display just a list of names, we don't need all the

columns of a table to be loaded. We may need the blob fields only at certain point, under

certain conditions, and so it's better to load them only at that time.

● Caching: A major justification for our claim that applications using an ORM persistence layer

are expected to outperform applications built using direct JDBC is because of the potential for

caching. Although we’ll argue passionately that most applications should be designed so that it’s

39


possible to achieve acceptable performance without the use of a cache, there is no doubt that for

some kinds of applications, especially read-mostly applications or applications that keep

significant metadata in the database, caching can have an enormous impact on performance.

Furthermore, scaling a highly concurrent application to thousands of online transactions usually

requires some caching to reduce the load on the database server(s).

• Cache dynamically generated queries, so that they don't get rebuilt at each call.

• Cache some data to avoid too many calls to the data source.

● Optimized queries: update only the modified columns; detect situations where the number of

executed queries can be reduced.

● Handle circular references: Handle circular references without duplication of objects

("account == account.Client.Account")

● Handle cascade updates: Deleting a master record should delete the linked details if wished

so.

● Bulk updates or deletions: When we want to update or delete thousands of records at a time,

it's not possible to load all the objects in memory, while this can be easily and quickly done with

a SQL query (DELETE FROM Customer WHERE Balance < 0). Support from the tool is

welcome to handle such massive operations without having to deal with SQL. Hibernate is not

very good on this point for example.

Evolution, compatibility:● Maintainability: what happens if the database schema changes? If I need to add a new

collection?

● Possibility to move to a new mapping tool: what would it imply? At what cost?

40


● Serialization: Serialization can be used to persist data outside of the database. Serialization can

be done into a binary format, or more important, in XML. Object-relational mapping tools often

base the development of your applications on the fact that the entities you handle are linked to a

data source with which they communicate directly to reflect updates you perform on them.

Especially when considering service-oriented architectures, the handling of persistence is

delegated to a dedicated layer; the code for persistence is not in the entities themselves.

● Distributed objects: ORM Remoting capabilities; web services; requires support for

serialization

Additional features:● Freedom in the design of the classes: No base class for the entities; no mandatory interface; no

specific class for collections. Think POJO (Plain Old Java Object).

● Less constraints as possible on the database schema: eg. support for composite data keys

● State information on data: It can be useful to know by looking at an object if the entity has

been added, modified, deleted.

● External mapping file: External mapping file or not? Attributes (annotations) in code or not?

• Advantages of external files: mapping entirely externalized; no intrusion in the classes;

can be generated

• Disadvantages of external files: one or multiple additional files to deal with; a syntax to

learn if no GUI is provided; understanding the links between the code and the database

requires some effort; can become out of sync with the code

• Advantages of attributes/annotations: everything at hand at code-level; the mapping is

obvious since directly present on classes and class members; can be used to generate

external mapping files using reflection if needed; if the mapping tool isn't used anymore,

they are ignored

• Disadvantages of attributes/annotations: the code is "polluted"; the code depends on a

41


specific mapping framework

● Support for disconnected mode: fill objects from a database, close the connection, the session,

create/update/delete some objects, and apply this modifications back to the database later.

● Interceptors and delegation mechanisms: Strategy to be able to react when the handling of

the persistence happens (eg. to be able to log what happens)

● Support for stored procedures: The advantages of stored procedures compared to dynamic

SQL queries make for a hot debate, but it is better to have the choice.

● constraints handling: Ability to specify constraints between objects and on properties (OCL -

Object Constraint Language). This can avoid having to wait for the data to reach the database

before being validated.

● Filtering objects in memory: Ability to filter objects in memory without having new queries

executed on the database.

● Deferred operations cache: Be able to defer the updates on the database, and apply them at a

given time using a specific method call, instead of having them systematically applied

immediately.

As you can see, the criteria are numerous! While choosing an ORM tool one should start by defining

which are critical for him (MUST HAVE) and which are less important (NICE TO HAVE).

3.3. Chosen ORM candidates:

Now that the comparison analysis criteria for Object-relational mapping has been identified and

defined, it needs to be tested on real software tools. The following table lists the chosen candidates for

comparison analysis. An introduction is given on these tools in the following sub sections.

42


Tool Version used Category Description JDBC 4.0

implemented in Java SE 6 (Java 6.0 will include a number of Java Database Connectivity enhancements collectively known as JDBC 4.0)

Free - The Java Development Kit (JDK) is free to download and use for commercial programming

JDBC is an API that provides universal database access for the Java programming language.http://java.sun.com/

Hibernate 3.2requires JDK 1.4 or newer

Open source–GNU LGPL Free to download andfree to use for both development and production deployments.

Hibernate is an open source object/relational mapping tool for Java http://www.hibernate.org/

JPOX(Java persistent objects)

1.2.2JDO1, JDO2, JDO2.1 and JPA1 compliant

Free - Apache Public License

JPOX is a free and fully compliant implementation of the JDOhttp://www.jpox.org/

Db40(Database for objects) ODBMS

7.2for Java

Open source – GPL Free when licensed under GPL.

Db4o is a high-performance, embeddedable open source object database. http://www.db4o.com/

Table 3: Chosen ORM tools for comparative analysis

3.3.1. JDBC:

JDBC is an API that provides universal database access for the Java programming language. JDBC is

the trademarked name and is not an acronym. But JDBC is often thought of as standing for "Java

Database Connectivity." The current version of JDBC API is JDBC 4.0 API implemented in Java SE 6.

It includes two packages:

• JDBC 4.0 Core API - The java.sql package, which is distributed as part of Java SE 6. The core

API is good enough for normal database applications.

• JDBC 4.0 Standard Extension API - The javax.sql package, which is distributed as part of Java

SE 6. The standard extension API, javax.sql, can also be downloaded from

http://java.sun.com/products/jdbc. It is required for applications that uses connection pooling,

43

http://java.sun.com/products/jdbc

http://www.db4o.com/

http://www.jpox.org/

http://www.hibernate.org/

http://java.sun.com/


distributed transactions, Java Naming and Directory Interface (JNDI), and RowSet API.

The specification of JDBC 4.0 API is documented in JSR (Java Specification Request) 221 maintained

by JCP (Java Community Process).

In order to use JDBC to connect Java applications to a specific database server, you need to have a

JDBC driver that supports JDBC API for that database server. For example, Microsoft JDBC Driver

allows you to access Microsoft SQL Server through the JDBC API.

As shown in the following figure the JDBC Architecture consists of two layers: the JDBC API, which

provides the application-to-JDBC Manager connection, and the JDBC Driver API, which supports the

JDBC Manager-to-Driver Connection. [JJO08]

3.3.2. Hibernate:

Hibernate is an open source Object-relational mapping tool for Java. Hibernate lets you develop

persistent classes following common Java idiom - including association, inheritance, polymorphism,

composition and the Java collections framework.

Hibernate not only takes care of the mapping from Java classes to database tables (and from

44

Illustration 3: JDBC Architecture


Java data types to SQL data types), but also provides data query and retrieval facilities and can

significantly reduce development time otherwise spent with manual data handling in SQL and JDBC.

Hibernates goal is to relieve the developer from 95 percent of common data persistence related

programming tasks. Hibernate is Free Software. The LGPL license is sufficiently flexible to allow the

use of Hibernate in both open source and commercial projects. Hibernate is available for download at

http://www.hibernate.org/.

The following diagram describes the high level architecture of hibernate: [HD08]

The above diagram shows that Hibernate is using the database and configuration data to provide

persistence services (and persistent objects) to the application

To use Hibernate, it is required to create Java classes that represents the table in the database

and then map the instance variable in the class with the columns in the database. Then Hibernate can be

used to perform operations on the database like select, insert, update and delete the records in the table.

45

Illustration 4: Hibernate Architecture

http://www.hibernate.org/


Hibernate automatically creates the query to perform these operations.

3.3.3. JPOX (Java persistent objects) JDO:

The Java™ Data Objects (JDO) specification introduced by the Java Community Process (JCP) is a

framework which persists plain Java objects to a datastore such as an RDBMS. JDO facilitates rapid

development with an open standard and can be used in nearly any Java environment. Java Persistent

Objects (JPOX) is a free and fully compliant implementation of the JDO1, JDO2, JDO2.1 and JPA1

specifications, providing transparent persistence of Java objects. It supports persistence to all of the

major RDBMS on the market today, persistence to the DB4O object data store, supporting all of the

main Object-Relational Mapping (ORM) patterns demanded by today's applications, allows querying

using either JDOQL, SQL, or JPQL, and comes with its own byte-code enhancer. JPOX is available

under the Open Source Apache 2 license.

The first thing to do when designing the datastore layer using JPOX is to define your classes to

be persisted (aka your "model"). You define this with either XML Metadata or annotations (or a mix of

both). As well as defining which classes and which fields of these classes are persisted you also have to

specify how the "identity" of each object is defined.

JPOX provides a high performance persistence mechanism by utilizing bytecode enhancement

to provide rapid detection of changes to persisted objects, allowing optimization not available using

reflection based tools. The following figure shows high level JPOX architecture. [JPOXD08]

46


JPOX is architected to provide an extensible persistence framework for heterogeneous datastores.

Outofthebox JPOX provides support for all major RDBMS on the market, together with DB4O. All

JPOX jars are OSGi bundles allowing deployment in J2SE environments, J2EE environments and

OSGi environments. JPOX provides a host of extension points allowing users to utilize the JPOX

persistence mechanism with their own corporate components, defining customized persistence of own

Java types, and generally not be limited in development.

3.3.4. Db4o (Database for objects) ODBMS:

db4o (database for objects) is a high-performance, embeddedable open source object database for Java

and .NET developers. db4o is designed to be embedded in clients or other software components

completely invisible to the end user. Thus, db4o needs no separate installation mechanism, but comes

47

Illustration 5: JPOX Architecture


as just one easily deployable library with a very low footprint of some 400KB. db4o supports Java's

JDK 1.1.x through 5.0 and runs on J2EE and J2SE.

Rather than using string-based APIs (such as SQL, OQL, JDOQL, EJBQL, and SODA), db40

uses Native Queries which allow developers to simply use the programming language itself (e.g., Java)

to access the database and thus avoid a constant, productivity-reducing context switch between

programming language and data access API.

The full version of db4o is available under two licenses (dual license): the open source, GPL,

which enables easy download, evaluation, and use in GPL compliant projects; and a commercial

runtime license with indemnification from db4objects for product development companies that wish to

embed db4o into their commercial, non-GPL products. The following picture gives a glimpse of db40

approach to storing objects. Unlike relational databases, db4o eliminates the object-relational mismatch

entirely. [DB4O08]

db4o have No Impedance Mismatch. The application's class hierarchy and object relationships

themselves define the database schema.

3.4. Chosen example for ORM candidates implementation:

In this section I will briefly describe the example chosen for ORM implementations. I chose a Banking

application to implement and analyse ORM candidates. This Banking application has two roles, an

Administrator and a User. I chose it as ATM banking application, especially because the Administrator

part of it can be modelled as web application and User part of it can be modelled as distributed Java

48

Illustration 6: RDBMS - db4o's Object Database


application. I implemented the persistence layer for the application using all the four technologies

described in the above sections. In the following chapter (chapter 4) you will see details of each

implementation.

The application’s high-level architecture is shown in figure 3.5. This diagram shows the

application’s main components and its actors. It has the standard three-layer architecture consisting of

the web-based/GUI presentation, business, and database access layers. The application stores its data in

a relational database for first three implementations and in Object-oriented database for fourth

implementation.

49

Illustration 7: High level architecture of ATM Banking application


The application’s persistence layer is responsible for accessing the database. The design of the

presentation layer and business layer are not part of this thesis, so I am going to focus on the design of

the persistence layer. In the following figure 3.6 you see the persistence layer as two subsystems that

form a layered structure. The upper layer, called the Persistent objects layer, encapsulates the concepts

of object-orientation while the lower layer, called the Database Handler, offers a high level interface on

top of Database (RDBMS / ODBMS).

The ATM Banking application is completely elaborated (requirements, use cases and EER diagram) in

Appendix A.

Tools used for implementation:

As the aim of this thesis is to compare and analyse ORM's, the persistence layer is implemented in all

four technologies, ORM and ODBMS. The following tools are used in implementation.

50

Illustration 8: High level architecture of Persistence layer


Tool Version used Category DescriptionNetbeans 6.0.1 Free – open source A free, open-source IDE for software

developers. http://www.netbeans.org/

Apache Derby

10.3.2.1 Free - Apache License, Version 2.0

Apache Derby, an Apache DB subproject, is an open source relational database implemented entirely in Java.http://db.apache.org/derby/

JUnit 4.1 Free – open source JUnit is a simple Java testing framework to write tests for Java applications. http://www.junit.org/

JMeter 2.3.1 Free - Apache License, Version 2.0

Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance.http://jakarta.apache.org/jmeter/

Java JDK 6 Free - GPL The Java SE Development Kit (JDK) includes the Java Runtime Environment (JRE) and command-line development tools that are useful for developing applications.http://java.sun.com/

Table 4: Tools used for implementation

In the following chapter (chapter 4 ) you will see details of each ORM Implementation, later in

chapter 5 the results of comparative analysis are elaborated.

51


http://jakarta.apache.org/jmeter/


http://db.apache.org/derby/

http://java.sun.com/


Chapter 4. ORM Implementations

In this chapter you will see details of each ORM candidate implementation of example application. As

you read along the sections you will sometimes find that I am not explaining the points stated in

previous implementation, this is done intentionally to avoid most of the redundant steps and words.

This chapter can serve as high level tutorial for the ORM candidates.

4.1. JDBC Implementation:

In this section I am going to show you the step by step process I followed to develop persistence layer

for the example application using JDBC and Derby database. I designed database schema for the Use

case requirements and written Java code to persist objects using JDBC API.

Step 1 : Database installation and schema definition:

As I am using Netbeans6.0.1, the Sun Java System Application Server is registered in NetBeans IDE

and the Java DB (which is based on the Apache Derby database) is already registered in IDE. Once a

connection is made, i can begin working with the database in the IDE, it allows to create tables,

populate them with data, run SQL queries, and more [LGDN08]. I defined database schema using IDE,

this schema follows the EER I developed for the Use case specified in Appendix A. Please see EER

diagram.

Step 2 : Domain classes:

As per retirements stated in Appendix A I designed domain classes as below (these are under

52

ORM Implementations

orm.jdbcimpl.perobj package in source code).Administrator

Customer

Transactions

PendingDeposits &

Atm

these objects are "Plain Old Java Objects" (POJO's) with no persistence code.

Step 3 : Persistence code:

After step 2, it is time to write persistence code for the domain objects. The following class diagram

shows the persistence layer I developed using JDBC.

53

ORM Implementations

The AdminTransactionHandler is responsible for administrator related Use case persistence activities.

This class uses AdminAuthenticator for authentication of a adminstrator and DatabaseManager class

for database connection and basic database operations. The TransactionsHandler class is responsible

54

Illustration 9: JDBC implementation - Persistence layer class diagram

ORM Implementations

for user related Use case persistence activities. This class uses UserAuthenticator for authentication of

a user and DatabaseManager class for database connection and basic database operations.

As everybody know how verbose JDBC code will be, I am not going to explain much about code, but

to give you glimpse of boiler plate code, below I gave a section from AdminTransactionHandler

addCustomer method.

public class AdminTransactionHandler {private DatabaseManager dbMgr;

......

/* method which stores new customer object*/

public boolean addCustomer(Customer $customer) throws InSufficientBalanceException {

if ($customer.getAccountBalance() >= 100) {

boolean status = false;

//generating account number.

String strGenAccNo = "select max(accountNo)+1 from SAVINGSACCOUNT";

$customer.setAccountNo(dbMgr.executeQueryString(strGenAccNo));

......

As part of code you must set each attribute from domain class to each attribute of database table String strAccQuery = "insert into SavingsAccount values('"

+ $customer.getAccountNo() + "','" + $customer.getName()

+ "'," + $customer.getAccountBalance() + ",default,'"

+ $customer.getAddress() + "','O','" + strDOB + "')";

int noOfRows = dbMgr.updateQuery(strAccQuery);

......

The following code is from DatabaseManager class referred above as dbMgr object.public int updateQuery(String query) {

Statement stmt = null;

int noOfRowsUpdated = 0;

try {

stmt = conn.createStatement();

try {

noOfRowsUpdated = stmt.executeUpdate(query);

55

ORM Implementations

} catch (SQLException sqle) {

sqle.printStackTrace();

}

} catch (SQLException sqle) {

sqle.printStackTrace();

}

return noOfRowsUpdated;

}

......

return status;

}

......

}

}

This code is just part of one method which persists a Customer object to database. Please see source

code for complete view of persistence layer code.

To handle the various application (Use case) specific errors I defined following exceptions. These

exception classes will be used for all the four implementations, so I won't mention them again in next

sections.

56

ORM Implementations

57

Illustration 10: Exceptions class diagram

ORM Implementations

Step 4: Testing and execution times:

In this step I implemented test cases for all components developed during above steps using Junit. I

noted execution time of each unit test of user and administrator modules. These execution times can be

used later in next chapter for comparative performance analysis.

4.2. Hibernate Implementation:

In this section I provide step by step instructions and process I followed to develop persistence layer for

the example application using Hibernate 3.2. I used both native SQL and HQL queries for this

implementation. HQL (Hibernate Query Language) is designed as a "minimal" object-oriented

extension to SQL. HQL provides an elegant bridge between the object and relational worlds.

[CHTRI08] [JPHBK08]

Step 1: Project library:

As I am working with Netbeans IDE, created a new Java project in the IDE and added the following

Hibernate libraries to the project library.

Antlr-2.7.6.jarasm.jarasm-attrs.jarsc3p0.jarcglib-2.1.3.jarcommons-collections-2.1.1.jarcommons-logging-1.0.4.jardom4j-1.6.1.jarhibernate3.jarjta.jarlog4j-1.2.11.jarderbyclient.jar

The libraries are from the Hibernate distribution, most of them required for a typical Hibernate project.

The derbyclient.jar is from Apache Derby distribution.

For Database installation and schema definition I followed the same step as in step 1 of JDBC

implementation so I wouldn't mention in detail again.

58

ORM Implementations


As Hibernate uses persistent classes that are mapped to database tables, it is obvious to follow this step

and define the domain classes based on business domain. I used the domain classes defined in 4.1 with

few modification. To make things a bit more interesting, i have replaced Customer class with

SavingsAccount class and AtmCard class. AtmCard is a subclass of SavingsAccount and adds two extra

fields on top of the ones it inherits. Please see Domain class diagram in Appendix A. I have defined an

id attribute in each of these classes which allows the application to access the database identity-the

primary key value of the persistent object.

Step 3: Mapping domain classes to database schema:

Hibernate needs some information about exactly how the domain classes be persistent, in other words

hibernate needs to know how instances of each class are supposed to be stored and loaded. This

metadata can be written into an XML mapping document, which defines, among other things, how

properties of the domain classes map to columns of database tables. Following is a section of mapping

file of SavingsAccount class.

<hibernate-mapping>

<class name="orm.hibernate.perobj.SavingsAccount" table="SAVINGSACCOUNT">



<id

name="savingsAccount_id”

column="SAVINGSACCOUNT_ID">

<generator class="increment" />

</id>



<property

name="accountNo"

type="java.lang.String"

column="ACCOUNTNO"

not-null="true" />

.....

59

ORM Implementations

.....

<set name="transactions" cascade="all,delete-orphan" lazy="false" inverse="true">

<key column="SAVINGSACCOUNT_ID" not-null="true" />

<one-to-many class="orm.hibernate.perobj.Transactions" />

</set>

.....

</class>

</hibernate-mapping>

I created a file named SavingsAccount.hbm.xml with the content shown above, and placed it next to

SavingsAccount.java file in the source package. Same is done for all other domain classes.

Step 4: CRUD operations:

After above three steps, Hibernate has enough information to generate all the SQL statements needed to

insert, update, delete, and retrieve instances of domain classes. I wrote a generic class which performs

all CRUD operations. This class is responsible for all database related operations. The below section of

code briefly explains how this class is organized. Please see the source code for complete file.

public class HibernateTransactionHandler {

//initialized fields

Session session = null;

.....

/* method which stores new objects*/

public Object create(Object object) {

.....

// store object

session.save(object);

.....

}

/* method which retrieves all objects of a class*/

The following method uses a HQL query.

60

ORM Implementations

public List all(String className) {

.....

// retrieveAllobjects

String QUERY = "from " + className + " objects";

Query query = session.createQuery(QUERY);

objects = query.list();

.....

}

/* method which retrieves an object by specified SQL/HQL query statement*/

public Object retreiveObject(final String query) {

.....

retrievedObject = session.createQuery(query).uniqueResult();

.....

}

/* method which updates an object*/

public boolean update(Object object) {

.....

session.update(object); // updating object

.....

}

/* method which deletes an object*/

public boolean delete(Object object) {

.....

session.delete(object);

.....

}

}

Step 5: Hibernate configuration file:

For Hibernate provided connection pooling and transaction management it is required to provide a

configuration file to setup environment. This configuration file must bear default name

hibernate.cfg.xml and be placed directly in the source directory of project, outside of any package. This

61

ORM Implementations

way, it will end up in the root of classpath after compilation, and Hibernate will find it automatically.

Following is the section of configuration file for this implementation.<hibernate-configuration> <session-factory>  <property name="hibernate.connection.driver_class">org.apache.derby.jdbc.ClientDriver</property> <property name="hibernate.connection.url">jdbc:derby://localhost:1527/ormhibernate</property> <property name="hibernate.connection.username">ormhibernate</property> <property name="hibernate.connection.password">ormhibernate</property>

 <property name="dialect">org.hibernate.dialect.DerbyDialect</property>

.....  <mapping resource="orm/hibernate/perobj/Administrator.hbm.xml"/> ..... </session-factory></hibernate-configuration>

Step 6: Persistence Layer:

After above steps and testing basic CRUD operations I wrote database handlers for each type of

domain class object to handle CRUD operations. These handlers mainly supply the specific class and

attribute related data to the generic CRUD class developed in step 3.

After successfully writing CRUD operations for each type of object in domain model, I

developed Use case specific operations for the persistence layer. In the following class diagram you see

the classes developed in this step and their usage of generic CRUD component

HibernateTransactionHandler stated in step 4.

62

ORM Implementations

63

Illustration 11: Hibernate implementation - Persistence layer class diagram

ORM Implementations




used later in next chapter for comparative analysis.

As I implemented persistence layer with Hibernate I am impressed by it. It appears mature and robust.

It's easy to use and the documentation is very good. I actually hand written Java code and defined

database schema my self but Hibernate have tools which by simply writing a simple xml document, can

generate java code and sql code. Or it can work with a legacy database and legacy objects, the xml

document links the two together. The simplicity of the design, and how well it stays decoupled from

application logic, are some of the reasons why I like it so much.

4.3. JPOX JDO Implementation:

In this section I am going briefly explain the steps involved in developing the persistence layer using

JPOX JDO. The JDO process is quite straightforward [JPT08]. As I explained about my working in

Netbeans IDE in previous sections, it is assumed that I follow the same procedure for basic project

settings. In this section you see only JPOX JDO related development steps.

Step 1: Domain classes:

These are same as in previous section. The only JDO constraint on any Java class that needs

persisting is that it has a default constructor (this can be private, and will actually be added by the

JPOX Enhancer if not added by developer).

Step 2: Persistence definition for domain classes:

After getting ready with domain classes, now I need to define how the classes should be persisted, in

64

ORM Implementations

terms of which fields are persisted etc. This is done by writing a Meta-Data persistence definition for

each class in a JDO MetaData file. There are several ways to do this, including using XDoclet, however

the most common way is to write the Meta-Data file manually. Below you see the part of the metadata

file.<jdo>

<package name="orm.JPOXjdo.perobj">

<class name="SavingsAccount" identity-type="application"table="SAVINGSACCOUNT" detachable="true">

<inheritance strategy="new-table"/>

<field name="savingsAccount_id" primary-key="true" value-strategy="max">

<column name="SAVINGSACCOUNT_ID" jdbc- type="BIGINT"/>

</field>

<field name="accountNo">

<column name="ACCOUNTNO" length="10" jdbc-type="VARCHAR"/>

</field>

.....

</class>

.....

</package>

</jdo>

With JDO there are various options as far as where these MetaData files are placed in the file structure,

and whether they refer to a single class, or multiple classes in a package. In this implementation, i have

all classes specified in the same file package.jdo, and placed directly in the source directory of project.

Step 3: Instrument/Enhance domain classes:

JDO relies on the domain classes to persist being PersistenceCapable. That is, they need to implement

this Java interface. JPOX JDO provides its own byte-code enhancer for instrumenting/enhancing the

persistent classes for use by any JDO implementation. We need to obtain the Enhancer JAR (as well as

the SUN JDO JAR) to use this. The following jar's are added to the project library.

jdo2-api-2.1.jarjpox-core-1.2.2.jarjpox-enhancer-1.2.2.jarlog4j-1.2.15.jar

65

ORM Implementations

bcel-5.2.jarderby.jarderbyclient.jarjpox-rdbms-1.2.2.jar

The first thing to do is compile domain classes. For enhancing, Netbeans provides a convenient way of

integrating this procedure into the build process without the need for any additional tool or plugin. This

is possible because NetBeans stores project information in .properties files and relies on Ant for the

build process. Class enhancement thus becomes a simple matter of adding a new task to the existing

build.xml generated by NetBeans [JPN08]. Override the -post-compile task/target with the following

Ant instructions.

<target name="-post-compile"> <echo message="Enhancing the MODULE files"/>

<copy todir="${build.classes.dir}">

<fileset dir="${src.dir}"

includes="**/*.jdo,**/*.properties,**/*.dtd,**/*.xml"/>

</copy>

<path id="module.enhancer.classpath">

<fileset dir="lib" casesensitive="yes">

<include name="*.jar"/>

</fileset>

<pathelement path="${javac.classpath}"/>

<pathelement location="${build.classes.dir}"/>

</path>

<taskdef name="jpoxenhancer"

classpathref="module.enhancer.classpath"

classname="org.jpox.enhancer.tools.EnhancerTask" />

<jpoxenhancer classpathref="module.enhancer.classpath" enhancerName="BCEL"

dir="${src.dir}"

failonerror="true"

fork="true"

verbose="true">

<jvmarg line="-Dlog4j.configuration=${log4j.properties}"/>

</jpoxenhancer>

</target>

66

ORM Implementations

This target is the most convenient for enhancing classes because it occurs just after all classes have

been compiled and is called in any case, whether the project is being built, tested or deployed. This

ensures that classes are always enhanced. By “Clean and Build” the project give the following output.

JPOX Enhancer : Using ClassEnhancer "BCEL" for API "JDO"

JPOX Enhancer : Input Files

>> C:\Thesis\19-04-2008\OrmJPOXjdoImplimentation\src\package.jdo

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.SavingsAccount

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.AtmCard

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.Administrator

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.Atm

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.Transactions

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.PendingDeposits

JPOX Enhancer completed with success for 6 classes. Timings : input=828 ms, enhance=391 ms, total=1219 ms. Consult the log for full details

Now the classes are enhanced and ready for persistence.

Step 4: JPOX configuration file:

Java Persistent Objects JDO (JPOX) allows a level of runtime configuration. This configuration is

typically specified in a jpox.properties file, follwing is the section of the file I specified

javax.jdo.option.ConnectionDriverName=org.apache.derby.jdbc.ClientDriver

javax.jdo.option.ConnectionURL=jdbc:derby://localhost:1527/ormJPOXjdo

javax.jdo.option.ConnectionUserName=ormjpoxjdo

javax.jdo.option.ConnectionPassword=ormjpoxjdo

Above it specified that, I have a Derby datastore, with the database called "ormJPOXjdo".

67

ORM Implementations


After above four steps, JPOX JDO has enough information to generate all the SQL statements needed

to insert, update, delete, and retrieve instances of domain classes. I wrote a generic class which

performs all CRUD operations. This class is responsible for all database related operations. The below

section of code briefly explains how this class is organized. Please see the source code for complete

file.

public class JPoxJDO {


private PersistenceManager pm;

.....

The initial step is to obtain access to a PersistenceManager, which is done as followsPersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory("jpox.properties");

PersistenceManager pm = pmf.getPersistenceManager();

So PersistenceManagerFactory using the file jpox.properties is being created. This will contain all

properties necessary for our persistence usage.

Now that the application has a PersistenceManager it can persist objects. This is performed as follows



.....

// store object

pm.makePersistent(object);

.....

}

/* method which retrieves all objects of a class*/public List all(Class className) {

Extent extent = null;

.....

68

ORM Implementations

.....

extent = pm.getExtent(className, true);

for (Iterator i = extent.iterator(); i.hasNext();) {

Object object = (Object) (i.next());

objects.add(object);

}

.....

return objects;

}

/* method which retrieves an object by id*/public Object retreiveObject(Class className, long id) {

.....

object = pm.getObjectById(className, Long.valueOf(id));

pm.detachCopy(object);

.....

return object;

}



.....

pm.makePersistent(object);

.....

}



.....

pm.deletePersistent(object);

.....

}

Clearly you can perform a large range of operations on objects. It is as simple as shown above.

69

ORM Implementations

Step 6: Persistence Layer:

After above steps and testing basic CRUD operations I wrote database handlers for each type of

domain class object to handle CRUD operations. These handlers mainly supply the specific class and

attribute related data to the generic CRUD class developed in step 5.

After successfully writing CRUD operations for each type of object in domain model, I

developed Use case specific operations for the persistence layer. In the following class diagram you see

the classes developed in this step and their usage of generic CRUD component JPoxJDO stated in step

4.

70

ORM Implementations

71

Illustration 12: JPOX JDO implementation - Persistence layer class diagram

ORM Implementations





As I implemented persistence layer with JPOX JDO I was impressed by it in beginning, but as I

continued with implementation I felt resources be limited. JPOX has active user forum and good online

documentation, but my point is sometimes when you developing something you wish to get answers as

soon as you type a key word in google, this is not so good for JPOX. Mostly, the only site which you

get redirected to is to JPOX official site. Otherwise, everything is perfect with JPOX JDO.

4.4. Db4o Implementation:

In this section I am going to show you the step by step process I followed to develop persistence layer

for the example application using db40 ODBMS. It is very simple to create a database and store objects

using db4o Object database. I used two query methods: Query-By-Example (QBE) and the more

flexible S.O.D.A query API of db4o. [DBT08] [JPDB04]

Step 1 : Db4o installation:

Added db4o-7.2-java5.jar to CLASSPATH of the project and db4o is installed, very simple.


Designed domain/model classes, these are actually same for all four implementations.

As per retirements stated in Appendix A I designed six domain classes as below (these are

under orm.db4o.perobj package in source code). Please see Domain class diagram in Appendix A.

72

ORM Implementations

Administrator.java

SavingsAccount.java

AtmCard.java

Transactions.java

PendingDeposits.java &

Atm.java

The six classes in the example represent administrator and User of a Banking Atm system.

Administrator and SavingsAccount are the two classes which represent administrator and user of the

system. To make things a bit more interesting, i also have a AtmCard class. AtmCard is a subclass of

SavingsAccount and adds two extra fields on top of the ones it inherits. SavingsAccount has an attribute

that is a list of Transactions objects and also has an attribute that is a list of PendingDeposits.

PendingDeposits and Transactions have an attribute of Atm and AtmCard objects. Administrator,

SavingsAccount, AtmCard, Transactions, PendingDeposits and Atm objects are "Plain Old Java

Objects" with no persistence code. No unique key attributes are required as an object database

automatically stores objects with unique object identifiers (OIDs).


After step 2, it is time for their persistence. I wrote a generic class which performs all CRUD

operations. This class is responsible for all database related operations. Following section of code

briefly explains how this class is organized. Please see the source code for complete file.

public class Db40Persistence {


private ObjectContainer db = null;

.....

// accessDb4o (open or create database file)

setDb(Db4o.openFile(config, DB4OFILENAME));

73

ORM Implementations



.....

// store object

getDb().store(object);

.....

}

/* method which retrieves all objects of a class*/

The following two methods uses a SODA query. The SODA query API is db4o's low level querying

API, allowing direct access to nodes of query graphs.

public ObjectSet all(Class className) {

....

// retrieveAllobjects

Query query = getDb().query();

query.constrain(className);

result = query.execute();

....

}

/* method which retrieves an object of a class by descending to its constrain field and constraining this with the respective candidate String.*/

public Object retreiveObject(Class className, String descend, Long constrain) {

....

Query query = getDb().query();

query.constrain(className);

query.descend(descend).constrain(constrain);

ObjectSet result = query.execute();

object = result.next();

....

74

ORM Implementations

}



....

getDb().store(object);

....

}

/* method which deletes an object*/


....

getDb().delete(object);

....

}

As you see in the above code it is very easy to write CRUD operations for Db4o.

Step 4: Domain objects Handlers for CRUD operations:

After step 3, I wrote database handlers for each type of domain class object to handle CRUD

operations. These handlers mainly supply the specific class and attribute related data to the generic

CRUD class developed in step 3.

Step 5: Administrator and User specific use case operations (Persistence layer):

After successfully writing CRUD operations for each type of object in domain model, in this

step I developed Use case specific operations for the persistence layer. In the following class diagram

you see the classes developed in step 4 and this step and their usage of generic CRUD component

Db40Persistence stated in step 3.

75

ORM Implementations

76

Illustration 13: Db4o implementation - Persistence layer class diagram

ORM Implementations





In this section I showed how a small footprint, embeddable object database offers a very simple,

compact route to object persistence. db4o is now an open source object database that offers a range of

attractive features and supports both Java and .NET. The simplicity of installation and use as well as the

lack of an impedance mismatch between object and data models make db4o very useful in a range of

business and educational applications.

77

ORM Implementations

Chapter 5. Comparative analysis results:

This chapter shows the complete comparative analysis of ORM's for Java based on the criteria formed

in chapter.3. The study is done based on literature available on the topic ORM and the implementations

of each ORM candidate tools, as explained in chapter.4. The comparison is done in tabular form for

easy legibility. In section 5.1 is shown comparison of general criteria, followed by comparison of ORM

specific criteria in section 5.2, comparison of performance in section 5.3. Finally in section 5.4

recommendations are given for choosing ORM tool and a conclusion is drawn with recommendations

for further research.

5.1. Comparison of general criteria:

In this section is shown comparison of general criteria for ORM based on the criteria developed in

section 3.2.1.

78

Comparative analysis results:

Tool ->criteria JDBC Hibernate JPOX JDO

usingODBMS (db4o)

Complexity (or) simplicity

Simple, all Java programmers know how to program in JDBC.

Less code, It relieves programmer from manual handling of persistent data. Has steep learning curve.

JDO is all about simplicity and JPOX is on the cutting edge of the available JDO implementations.

Fewer lines of code, less complexity to manage.

Ease of use, time to be up and running

Yes easy to use, JDBC 4 has a strong focus on ease-of-use and programmer productivity.

One of the reasons for Hibernates popularity is its ease of use. up and running in ten minutes or less .

anyone can run their first JPOX example in just a couple of minutes using sample JPOX app.

helps you to get things done in less time with less trouble. Has ease of deployment.

Flexibility Not very flexible in designing Object oriented concepts.

Hibernate provides tremendous flexibility for mapping O/R.

flexibility for different people to develop the data-tier utilizing their own skills to the full without having to learn totally new concepts.

db4o has the flexibility to fit in architectures, which aim to achieve better productivity in object-oriented software development."

Documentation

Has very good documentation.

One of the reasons for Hibernates popularity is its documentation.

provides extensive documentation.

Has good documentation with Extensive examples.

Maturity or Longevity

First released in 1997, current version is 4.0 released in 2006. distributed as part of Java Se 6, documented in JSR 221 and maintained by JCP.

The first version was released in 2001, became very popular, has won a Jolt Award in 2005, present version is 3.2.6.ga released on February 8, 2008. Has very active community.

is a fully compliant implementation of the JDO1/JDO2 specifications. JPOX project was started in March 2003 with first release 1.0 in July 2004, 1.1 in May 2006, and latest 1.2 in March 2008. JPOX has very active community.

created in 2000 and first shipped in 2001. launched in 2004 as commercial. Today, db4objects has become one of the hottest technology innovators in Silicon Valley.

Frequency of the updates, bug fixes, evolutions

Regular updates are available.

Has rapid release schedule, regular file releases (even a few days from one version to the next).



Support (forums, community)

Has Sun forum and many more.

Has very active user forum and also has commercial support, training, and

Yes, has online support community also offers professional paid

world's largest user community for ODBMS technology, with 35000 registered

79

http://developer.db4o.com/forums/default.aspx

http://www.jpox.org/servlet/forum

http://www.jpox.org/servlet/forum

http://forum.hibernate.org/

http://forum.java.sun.com/forum.jspa?forumID=48

http://www.stepaheadsoftware.com/products/javelin/examples/examples.htm

http://www.stepaheadsoftware.com/products/javelin/examples/examples.htm


consulting. support (training and consulting).

peers.

Vendor's reputation and stability

Very much stable, distributed as part of JDK.

Hibernate has excellent reputation and stability.

Has good reputation and stable.

Has good reputation and stability.

Source code provided or not

Yes Yes, source code available.

Yes, source code available.

Yes

Support for multiple platforms

Yes, Java has MultiPlatform Support.

Yes, cross-platform (JVM)

Multi platform Windows/Linux/Mac OS/BSD/Solaris and supports RDBMS, DB4O, LDAP.

is a multiplatform solution, also it supports Java and .NET

Price Free - The Java Development Kit (JDK) is free to download and use for commercial programming

Free - Open source–GNU LGPL Free to download andfree to use for both development and production deployments.

Free - Apache Public License

Free - Open source – GPL Free when licensed under GPL.

Performance A whole section is dedicated to compare performance, please see section 5.3 Comparison of performance.

Table 5: Comparison of general criteria

5.2. Comparison of ORM specific criteria:

In this section is shown comparison of ORM specific criteria for ORM based on the criteria developed

in section 3.2.2.

80

http://www.jpox.org/docs/download.html

http://www.hibernate.org/6.html


Tool ->criteria JDBC Hibernate JPOX JDO

usingODBMS (db4o)

Basic featuresTransparent Persistence

developer need to write lines of code explicitly to map database tables tuples to application objects during interaction with RDBMS.

provides transparent persistence. (developer does not need to write code explicitly to map database tables tuples to application objects during interaction with RDBMS)

provides transparent persistence.

fully compliant implementation of the JDO 1.0 and 2.0 specifications

the manipulation and traversal of persistent objects is performed directly by Java (OOP) in the same manner as in- memory, non-persistent objects.

Inheritance does not handle inheritance.

(developer has to write code to map an object model's data representation to a relational data model and its corresponding database schema)

Yes, can handle inheritance in number of ways.

table per class hierarchy

table per subclass

table per concrete class

Yes, have choices to handle inheritance.

New-table

subclass-table

superclass-table

Inheritance is a core feature, no mismatch exists.

(do not have to do anything special with inherited classes)

Relations Does not support table relations.

resolved directly by means of associations 1-1, 1-NN-1, M-N.Supports both unidirectional and bidirectional associations.

Supports relations. 1-1, 1-N, N-1 and M-N. Supports both unidirectional and bidirectional relations.

There are no tables. Can handle 1-N, M-N relations with List.

The application's class hierarchy and object relationships themselves define the database schema.

Transactions Can use disable auto-commit mode and setTransactionIsolation for Connection.

Uses Session and Transaction classes.

every SQL statement, be it queries or DML, has to execute inside a database Transaction.

Uses JDO Transaction and PersistenceManager classes.

the PersistenceManager is used for all JPOX transactions

provides a transaction mechanism.

Uses ObjectContainer class.

you always work inside a transaction, i.e., with

81


ObjectContainer.

Aggregates Supports all SQL aggregates.

Supports avg(), sum(), min(), max() ,count().

Supports avg(), sum(), min(), max() ,count().

Not supported.

For statistical tabular data RDBMS is best.

Grouping Supports SQL Group By

HQL supports Group By Clause.

JDOQL supports group by Clause.

Not supported.

Extended featuresSupported databases

There are currently 221 JDBC drivers available from different vendors. [JDAA08]

Many, please see


Excellent support for the vast majority of RDBMS available on the market today.

-Not applicable-Is a database itself.

Query language

Supports only native Structured query language (SQL)

Supports native SQL statements and provides a powerful query language Hibernate Query Language, HQL (independent from type of database) that is expressed in a familiar SQL like syntax and includes full support for polymorphic queries.

Supports three query languages

SQLJDOQLJPOXQL

http://www.jpox.org/docs/1_1/query.html

supplies three querying systems,

Query-By-Example (QBE)

Native Queries (NQ), and

the SODA API.

FlexibilityCustomization of queries

Developer has to find out the efficient way to access database, i.e to select effective query from a number of queries to perform same task.

HQL provides custom SQL queries.

selects an effective way to perform a database manipulation task for an application.

JDOQL provides custom SQL queries.

SODA is useful for dynamic generation of queries

Support for SQL joins

Yes.Developer must write code.

Supports both inner and outer joins

Supports both inner and outer joins

-Not applicable-

Concurrency management

Has transaction Isolation Levels,

Has optimistic concurrency control

supports 3 optimistic locking strategies.

Supports only optimistic locking.

82



http://www.jpox.org/docs/1_2/rdbms/index.html

http://www.jpox.org/docs/1_2/rdbms/index.html




which control concurrency:

TRANSACTION_NONETRANSACTION_READ_COMMITTEDTRANSACTION_READ_UNCOMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE

Automatic versioning and Time Stamping has to be added by the developer.

with automatic versioning and Time Stamping.

Supports pessimistic locking.

Version-number, date-time, none.

Supports pessimistic locking.

org.jpox.useUpdateLock

Data type support for RDBMS

Supports all data types for supported databases.

Supports all data types for supported databases

except some issues with some databases like, Problems with the use of index for the 'bigint' type in PostgreSQL, please see


Supports all data types for supported databases

except some issues with some databases like, MS SQL 2000 does not keep accuracy on datetime datatypes. Please see

http://www.jpox.org/docs/1_1/rdbms.html

Have problems with java.sql.Timestamp.

Supports almost all of java.sql datatypes.

Single class to multiple tables

Developer must write code to achieve this.

Using the <join> element, it is possible to map properties of one class to several tables.[HD08]

JDO allows persistence of fields of a class into secondary tables. [JPOXD08]

db4o stores objects as objects, not in tables.

Single table to multiple objects

Developer must write code to achieve this.

Yes, can be done. Yes, can be done.(embedded objects)

db4o stores objects as objects, not in tables.

Assistance, ease of useGUI to setup the mapping

There is no mapping

Yes, Hibernate Tools - implemented as an

Yes, Eclipse Dali project provides a

There is no Mapping, but has Db4oEclipse,

83







integrated suite of Eclipse plugins.

powerful development environment for Java Persistence.

an Eclipse plugin to explore and query the db4o database content.

Generation of the classes

No Has reverse engineering tool, hbm2hbmxml, hbm2java.

Has reverse engineering tool.

-Not Applicable-

Generation of the database schema

No Has schema generation tool hbm2ddl

(doesn't require its own data model)

Has support for schema generation, and existing schema.org.jpox.autoCreateSchema

(doesn't require its own data model)

-Not Applicable-has automatic schema recognition.

Optimizations, performance, design:Lazy loading No Yes, has lazy

loading.Yes, is a JDO implementation.

db4o provides a mechanism to give the user fine grained control over how much he wants to pull out of the database when asking for an object. This mechanism is called activation depth.

Caching Caching is maintained by hand coding. Can use CachedRowSet. [GCS01]

Hibernate uses two different caches for objects: first-level cache and second-level cache. Query result sets may also be cached by The Query cache.

Two levels of caching are available with JPOX. Has pluggable framework for external caching.

Db4o uses object reference cache for easy access to persistent objects during one transaction.

Optimized queries

Yes, set the query fetch size. when you doan update it's straightforward (although tedious) to write the code so

Yes, has two different and complementary tuning strategies, global and per use case.

Yes, allows control over fetching process. JDO2 provides a fetch size on the Fetch Plan to allow this control.

Yes, has enhancement tools for Native query optimization.

84

http://developer.db4o.com/Resources/view.aspx/Reference/Implementation_Strategies/Enhancement_Tools

http://developer.db4o.com/Resources/view.aspx/Reference/Implementation_Strategies/Enhancement_Tools

http://www.jpox.org/docs/1_2/jdo/fetchgroup.html


http://java.sun.com/j2se/1.4.2/docs/guide/jdbc/getstart/resultset.html

http://developer.db4o.com/Resources/view.aspx/Reference/Basic_Concepts/Object_Identity/Weak_References


that only modified columns are updated.

Handle circular references

Developer must handle manually.

A session-level cache resolves circular references.

Yes, is a JDO implementation and by default uses level 1 cache.

Yes, provides internal object id's to avoid circular reference.

Handle cascade updates

Developer must handle manually.

Yes, by using cascades associations may be configured for cascading save, delete, and/or reattachment.

Yes, by using cascade.

Yes, by setting cascadeOnUpdate() and cascadeOnDelete()

Bulk updates or deletions

No, not without using SQL.

HQL now supports bulk UPDATE and bulk DELETE queries. But do not cause cascade-deletes.

JDOQL has bulk delete but not bulk update.

db4o doesn't have any bulk insert/update/delete mechanisms.

Evolution, compatibility:Maintainability

hard to maintain. JDBC is tightly tied with the underlaying database. In database if a column type changes, or application ported to a different database, this code must be rewritten.

Easy to maintain. Hibernate is not tightly tied with any underlaying database

Easy to maintain. Yes, easy to maintain. Applications using objects with collection members (one-to-many relationships) will benefit.

Possibility to move to a new mapping tool

You have to change all the code.

Yes possible, depends on the situation. If the metadata models aren't too different it can be trivial.Should be pretty straightforward to convert, but then you will have to get

Yes possible, depends on the metadata model.

Moving to a new tool (in this case OO language) is not so easy. ODBMS creates a tight coupling between your code and your data storage.

85


familiar with the metadata model of other tool.

Serialization Yes supports serialization.

Yes has support. Yes has support. Yes has support.

Distributed objects

Using JDBC for transaction management in an environment involving multiple databases or distributed databases is not trivial.

Distributed transactions are well supported.

distributed (XA) transactions are supported. can be utilized within a J2EE environment using Java Connector Architecture, JCA.

From the API side, there's no real difference between transactions executing concurrently within the same VM and transactions executed against a remote server. (db4o is currently mostly optimized for embedded, local use rather than Client-Server. C/S isn't as fast as ORM's)

Additional featuresFreedom in the design of the classes

Yes Yes, provides transparent persistence for POJOs, except the no-argument constructor is a requirement. Tools like Hibernate use reflection on this constructor to instantiate objects.

Yes, the only JDO constraint on any Java class that needs persisting is that it has a default constructor.

Yes

Less constrains as possible on the database schema

Yes Yes, hibernate does not enforce on DB schema.

JPOX is very unobtrusive as far as the datastore schema is concerned.

Does not require schema files since it runs natively. Since it saves the graph, no linking entries need to be made.

State information on data

This check has to be added by the developer.

supports the following object states: Transient,

Can use getObjectState.

Yes, has support.

86


Persistent, Detached External mapping file

No Yes, uses external mapping file. You can also use annotations in addition to or as a replacement of XML mapping metadata.

Yes uses ORM MetaData file. JPOX supports both JPA1 and JDO2 annotations.

No mapping file required.

Support for disconnected mode

A DataSet can be manipulated and operated upon both in a connected and disconnected mode.

Yes, This pattern is known as session-per-conversation.

Yes, has ability to attach/detach objects to/from the persistence graph.

Yes

Interceptors and delegation mechanisms

Can be handled in a number of ways, ex. log4jdbc is a Java JDBC driver that can log SQL and/or JDBC calls

Hibernate uses log4j , java.util.logging , or potentially any another logging framework.

can be configured to log tracking the persistence process. ex. Using Log4J, JDK1.4+

Can use log4j.

Support for stored procedures

supports calling stored procedures with the CallableStatement class

Hibernate 3 introduced support for queries via stored procedures and functions.

Yes allows. overridden JDO by org.jpox.query.allowAllSQLStaments

Uses methods.Complex select procedures might require a separate function.

constraints handling

Developer must code the handling.

Hibernate Validator comes with some built-in constraints, which covers most basic data checks.

JPOX provides an extension to JDO that can give significant benefit to constraint handling. org.jpox.rdbms.constraintCreateMode ex.<unique name=.>

Supports constraints. A constraint is checked at commit-time and a constraint violation will cause an exception.

Filtering objects in memory

Can be programmed through FilteredRowSet.

can use createFilter Can use setFilter. Yes

Table 6: Comparison of ORM specific criteria

87


5.3. Comparison of performance:

In this section the performance of candidate tools is compared. This comparison is done by running

tests and recording the execution times. The tests were conducted on the original computer the

applications were developed on: a TOSHIBA T5500 Intel Core 2, 1.66 G Hz with 2 GB RAM, running

32 bit Windows XP Professional.

5.3.1. Use case specific comparison:

In this section I compared the execution times of the Use case modules. A table is shown with

execution times for each use case with each ORM candidate tool. Just below each table, its graph is

shown, the low the bar on the graph the fastest the tool.

88


'Administrator' Use case comparison:

t [time in ms] JDBC Hibernate JPOX JDOusingODBMS (db4o)

1. admin login 312 1328 1390 4062. add customer 313 1407 1468 783. find customer 15 47 375 784. update customer 31 46 297 945. delete customer 47 62 672 3286. create new card 93 79 313 1097. update PIN 15 31 1500 948. check all pending deposits

16 94 1484 63

9. check pending deposit for a customer

360 32 344 78

10. approve deposit 32 47 719 500

Table 7: administrator use case performance comparison

89

Illustration 14: administrator use case – performance comparison chart

1 2 3 4 5 6 7 8 9 100.000

200.000

400.000

600.000

800.000

1000.000

1200.000

1400.000

1600.000

JDBC

Hibernate

JPOX JDODb4o

Use case number

Exe

cutio

n tim

e


'User' use case comparison:


1. User login 359 1375 250 4682. check balance 16 15 16 163. withdraw cash 16 47 125 314. deposit money 15 1625 1703 315. mini statement 16 25 15 166. change PIN 15 32 31 31

Table 8: User use case - performance comparison

90

Illustration 15: User use case - performance comparison chart

1 2 3 4 5 60

200

400

600

800

1000

1200

1400

1600

1800

JDBC

Hibernate

JPOX JDODb4o

Use case number

Exe

cutio

n tim

e


5.3.2. CRUD comparison:

In this section I compared the execution times of CRUD operations. A table is shown with execution time for each set of objects. Just below each table, its graph is shown, the low the bar on the graph the fastest the tool.

write, query, update and delete simple flat objects individually.

Create:

Writes objects to DB.


500 objects 3579 1359 3344 5001000 objects 7110 2625 6703 9375000 objects 74625 11922 39625 131210000 objects 134953 32234 107547 1750

Table 9: Create objects performance comparison

91

Illustration 16: Write - comparison chart

500 objects 1000 objects 5000 objects 10000 objects0

20000

40000

60000

80000

100000

120000

140000

160000

J DBC

Hibernate

J POX J DODb4oEx

ecut

ion

time


Read:

Retrieves objects by querying.


500 objects 5469 7312 3906 3441000 objects 10125 11437 7156 7035000 objects 272562 73438 43563 145310000 objects Very large 194531 118610 2578

Table 10: Read objects performance comparison

92

Illustration 17: Read comparison chart


50000

100000

150000

200000

250000

300000

350000

400000

Read - comparison

JDBC

Hibernate

JPOX JDODb4o

Exe

cutio

n tim

e


Update:

reads and then updates an object.



Table 11: Update objects performance comparison

93

Illustration 18: Update comparison chart


50000

100000

150000

200000

250000

300000

350000

JDBC

Hibernate

JPOX JDODb4o

Exec

utio

n tim

e


Delete:

reads and then deletes an object.



Table 12: Delete objects - performance comparison

94

Illustration 19: Delete - performance comparison chart


50000

100000

150000

200000

250000

300000

350000

JDBC

Hibernate

JPOX JDODb4o

Exe

cutio

n tim

e


5.4. Recommendations and conclusion:

As you see above in sections 5.1, 5.2 and 5.3, there are numerous criteria, the importance of individual

criteria will depend on the respective application. Clearly, there is no best product for all situations.

However I drew some general conclusions from the results that answers the research questions formed

in chapter 1. These questions formed in chapter 1 served as guideline for the research done in the thesis.

The answers to these questions will now be given briefly recapitulating the main issues addressed in the

thesis.

The first question for which an answer was needed is:

Is ORM framework a replacement for JDBC?

The answer to this question: No. ORM frameworks use JDBC. It's ORM framework on top of JDBC,

not ORM framework instead of JDBC.

JDBC is theoretically faster (or the same) than any ORM tool since ORM tool is always reduced to

low-level JDBC calls. Even with hibernate, some advanced queries will require either direct JDBC or

good stored procedures; object mapping tools really don't eliminate complex database issues.

Use of ORM framework is an overhead for the applications which are :

• simple and use one database that never change

• need to put data to database tables, no further SQL queries

• there are no objects which are mapped to two different tables

ORM framework increases extra layers and complexity. So for these types of applications JDBC is the

best choice.

The use of O-R mapping technology like Hibernate or JDO O-R mappers has a strong negative impact

on performance. If you can't compensate by throwing hardware at your application, you may have to

avoid O-R mappers, if performance is important to you. Protagonists of O-R mapping technology may

tell you that caching will bring you back performance. Although this may be true, do not forget: Data

95


that comes from a cache can always be stale in a multi-user application. If you want your data to be up-

to-date, you have to reread from the database and an old cache that you can not use will even degrade

performance.

Now if we see disadvantages of JDBC, with JDBC, developer has to write code to map an object

model's data representation to a relational data model and its corresponding database schema.

Developer has to find out the efficient way to access database, i.e to select effective query from a

number of queries to perform same task. Application using JDBC to handle persistent data (database

tables) have database specific code in large amount. With JDBC, it is developer’s responsibility to

handle JDBC result set and convert it to Java objects through code to use this persistent data in

application. SQL looks like a foreigner in Java code, very ugly, difficult to write and refactor.

I think the main question a project team needs to settle on is whether or not to use an Object-Relational

Mapping (ORM) framework. If you decide to go with an ORM (which is what I'd usually recommend

for larger projects), you are indeed buying into some added complexity and learning curve, but in

exchange you'll get a great deal of power and flexibility. O-R mappers and object databases make life

so much easier and productive. Now, this arises the second question in this paper

How to select an Object-relational mapping tool which is suitable for the Java project in Hand?

This is not an easy question to answer in few words, a project team must check the criteria formed in

chapter 3, the analysis present in this chapter (Ch.5) and decide which criteria are critical for them. The

tools which I chose for this thesis, Hibernate and JPOX JDO passes almost all of the criteria. There

may be some issues in each tool, but there are workarounds for almost all of them. For these two tools

the community is so strong that the known issues are solved instantly and new versions with updated

features are released in regular periods. If you take a look at the source code of example implemented,

the task of storing objects is very similar among both the products.

Hibernate is often termed synonymous to ORM in Java world, but I would say there are many other

tools in market which are really good, I did not use any but as I was researching for ORM's I came

across Cayenne, TopLink and iBatis, which I would say probably be a good choice too. If you want to

96


go for JDO implementation, then I would say JPOX is the best open source JDO available at the

moment.

Finally, if there is problem using RDBMS with OO language, why not replace the whole system. This

leads to our last question in this paper

Can relational databases be replaced with Object-oriented databases?

The answer to this question: No. Object databases have not swept the marketplace. There are usually

good reasons for that. I don't think objects are always the most natural way to represent data. The

relational model has a lot going for it that the object model does not:

● A mathematical basis (set theory),

● A ubiquitous, standard language (SQL)

● A huge installed base

● Familiar to a large user and client community

● Large institutions have critical data tied up in them (e.g., banks)

● No compelling reason to switch

As would be expected, object databases like db4o provide best performance for deep inheritance

hierarchies and tree structures. Not especially. My point was more that, for some data operations, the

relational model is more suitable than an object one. Simple as that. The whole "ORM is inherently

better " thing is a fallacy. Right tool for the job, always.

Object databases have compelling reasons for existence, but not so strong a case that they could

displace the RDBMS from the "enterprise data" throne. the RDBMS has been, and will, in the absence

of a nearly catastrophic change to the contrary, continue to be, the choice of businesses all over the

world for storing data in a format that's easily-accessed from a variety of different systems.

97


Recommendations for further Research:

This research project has attempted to answer some questions regarding Object relational mapping and

its comparison. This relatively new area does still leave much to explore. There are a number of ideas

to extend on this research project, as well as new questions that could be answered.

The criteria defined in chapter 3 can be more researched and fine tuned by awarding points for each

criteria, I mean more statistical approach can be implemented for evaluation by introducing scoring.

In order to perform comparison analysis, a case study was conducted on an example banking

application. Of course one case study does not lead to a definitive answer. The comparison criteria

proposed here could certainly be tested more thoroughly on different applications, and improved using

the results of these tests. Also, few other ORM tools and databases (RDBMS & ODBMS) can be used

for further research.

98

Bibliography

Bibliography

[ADTSA06] Scott W Ambler - “Agile database techniques”, Wiley Publishing, Inc. 2006

[CHTRI08] “Complete Hibernate 3.0 Tutorial”, Retrieved on April 7, 2008.http://www.roseindia.net/hibernate/index.shtml

[CRPIA05] Chris Richardson - “POJOs in action”, Manning Publications Co. Greenwich, 2006.

[DB4O08] Db40 Documentation, Retrieved on May 5, 2008. http://www.db4o.com/

[DBT08] Db4o-7.2 Tutorial bundled with db4o-7.2 for Java, May 5, 2008.

[DMJLBH06] Dave Minter and Jeff Linwood - “Beginning Hibernate from novice to Professional”, Apress. Berkley, August, 2006.

[EMMSF05] Amnon H. Eden , Tom Mens - “Measuring Software Flexibility”, 2006, Retrieved on March 11 2008.

http://www.eden-study.org/articles/2006/measuring-sw-flexibility_ieesw.pdf

[GCS01] Jonathan Lurie , - “Develop a generic caching service to improve performance, Build a timed cache with a background thread”, 20 July, 2001, Retrieved on June 05, 2008.http://www.javaworld.com/javaworld/jw-07-2001/jw-0720-cache.html

[GEOUS08] Michael Gomoll - “The Ease-Of-Use Issue in Software Selection”, Retrieved on May 06, 2008. http://www.drj.com/drworld/content/w2_059.htm

[HD08] Hibernate documentation, 2008. Retrieved on April 02, 2008. http://www.hibernate.org/hib_docs/reference/en/html/

[JDAA08] JDBC Data access API – Drivers, 2008. Retrieved on June 02, 2008. http://developers.sun.com/product/jdbc/drivers

[JJO08] Java+JDBC+Oracle, Retrieved on May 06, 2008. http://www.cse.unsw.edu.au/~jas/talks/jdbc/notes.html , 2008

[JPDB04] Jim Paterson - “Simple Object Persistence with the db4o Object Database”, 2004. Retrieved on May 21, 2008.http://www.onjava.com/pub/a/onjava/2004/12/01/db4o.html#resources

99

http://www.onjava.com/pub/a/onjava/2004/12/01/db4o.html#resources

http://www.cse.unsw.edu.au/~jas/talks/jdbc/notes.html

http://www.cse.unsw.edu.au/~jas/talks/jdbc/notes.html

http://developers.sun.com/product/jdbc/drivers

http://www.hibernate.org/hib_docs/reference/en/html/architecture.html

http://www.drj.com/drworld/content/w2_059.htm

http://www.javaworld.com/javaworld/jw-07-2001/jw-0720-cache.html

http://www.eden-study.org/articles/2006/measuring-sw-flexibility_ieesw.pdf


http://www.roseindia.net/hibernate/index.shtml

Bibliography

[JPHBK08] Christian Bauer, Gavin King - “Java Persistence with Hibernate”, Manning Publications Co. USA, 2008

[JPN08] Eddy Young - “JPOX and Netbeans”, Retrieved on April 21, 2008.http://www.jpox.org/docs/1_1/tutorials/netbeans.html

[JPOXD08] JPOX documentation, 2008. Retrieved on April 21, 2008.http://www.jpox.org/

[JPT08] “JPOX – Tutorial”, 2008. Retrieved on April 21, 2008.http://www.jpox.org/docs/1_1/tutorials/tutorial.html

[KBOSE05] Karin van den Berg - “Finding Open options An Open Source software evaluation model with a case study on Course Management Systems”, Tilburg, August 2005. Retrieved on March 11, 2008.http://www.karinvandenberg.nl/Thesis.pdf

[KGPDM03] Kyle Gabhart - “Persistent Data Management”, April 02, 2003.Retrieved on January 11, 2008. http://www.ibm.com/developerworks/java/library/j-pj2ee3.html

[KSTGASCM86] Joseph k. Kearney, Robert L. Sedlmeyer, William B.Thompson, Michael A Gray, and Michael A. Adler - “Software Complexity Measurement”, 1986. Retrieved on June 11, 2008.

[LGDN08] Brian Leonard, Troy Giunipero - “Working with the Java DB (Derby) Database in NetBeans IDE”, 2008. Retrieved on December 03, 2008.http://www.netbeans.org/kb/55/derby-demo.html#starting

[MGATM01] http://www.math.gordon.edu/courses/cs211/ATMExample/, 2001.Retrieved on January 14, 2008.

[ORMA08] “Object Relational Mapping Articles”, 2007.

Retrieved on December 17, 2007.

[ORTC08] “Object relational tool comparison”, 2008. Retrieved on March 24, 2008.http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

[QMGSJ05] Qusay H Mahmoud - “Getting started with JDO”, 2005.Retrieved on April 07, 2008.http://java.sun.com/developer/technicalArticles/J2SE/jdo/

[SCUJWD06] Susan Cline - “Using JPOX JDO with Derby”, 2006.Retrieved on April 08, 2008.http://db.apache.org/derby/integrate/JPOX_Derby.html

100

http://db.apache.org/derby/integrate/JPOX_Derby.html

http://java.sun.com/developer/technicalArticles/J2SE/jdo/

http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

http://www.service-architecture.com/object-relational-mapping/articles/index.html

http://www.math.gordon.edu/courses/cs211/ATMExample/

http://www.netbeans.org/kb/55/derby-demo.html#starting

http://delivery.acm.org/10.1145/10000/7540/p1044-kearney.pdf?key1=7540&key2=0767800121&coll=GUIDE&dl=GUIDE&CFID=26741623&CFTOKEN=42695145

http://www.ibm.com/developerworks/java/library/j-pj2ee3.html

http://www.karinvandenberg.nl/Thesis.pdf

http://www.jpox.org/docs/1_1/tutorials/tutorial.html


http://www.jpox.org/docs/1_1/tutorials/netbeans.html

Bibliography

[SSVUH05] Saritha.S.V - “Understanding Hibernate ORM for Java/J2EE”, 2005.Retrieved on March 21, 2008.http://www.codetoad.com/java_Hibernate.asp

[WSHWMT01] William D. Shoaff - “How to write a master's thesis in computer science”, August 21, 2001. Retrieved on December 03, 2007.http://cs.fit.edu/~wds/guides/howto/

[XCHSI04] Xavier Coulon, Christian Brousseau – “Hibernate simplifies inheritance mapping”, Decebmer 14, 2004. Retrieved on March 03, 2007.http://www.ibm.com/developerworks/library/j-hibernate/?ca=dnt-550

101

http://www.ibm.com/developerworks/library/j-hibernate/?ca=dnt-550

http://cs.fit.edu/~wds/guides/howto/

http://www.codetoad.com/java_Hibernate.asp

Appendix A

Appendix A

Example: ATM Banking application

I. Functional requirements:

This list of functional requirements was used in the example application. This list is constructed using the main features from a website that gives detailed Requirements for Example ATM System: [MGATM0 1 ]

The requirements from the above site included for User module of application and Administrator module are created based on these.

i. User should have a savings account with the bank.ii. User should have ATM facility with valid card with unique card number and a valid PIN

number.iii. User should be acquainted with the basic transactions available in the ATM facility.iv. Bank should provide a customer database with the details like account holder’s name, account

number, card number, PIN number, balance, etc.v. Bank Administrator should have the control over the updating of the account details like:

○ Customer details

○ Updating the account balance

vi. Bank Administrator should have a facility to open/close a savings account with ATM facility for a customer.USER module:

i. The login window of the ATM should have fields for the entry of the valid ATM card number.

ii. If the card number is validated as valid card number, the application should prompt for the valid

PIN number or else it should display a message like:” Invalid card number. Please enter a valid

card number”, “Your account has been blocked”, etc. and should return back to the enter card

number screen.

iii. If PIN number is valid, user should be taken to the screen with the following options

○ Fast cash

○ Withdraw cash

○ Balance inquiry

○ Mini statement

○ PIN change

○ Deposit cash

102

Appendix A

○ Money transfer

○ Utility bill payment

iv. Fast cash: On selection of this option, user is prompted to select from the list of predefined

withdraw amounts like 1000, 2000, 5000, etc. Only the options with amount below the account

balance should be active.

v. Withdraw cash: On selection of this option, user is prompted to enter the amount to be

withdrawn and click the “yes” button. If the amount is within his balance then the transaction

takes place. If the amount is not within the balance, then a message “insufficient balance” is

displayed. There should be a “clear” button in case the user mistypes the amount.

vi. Balance inquiry: On selection of this option, user is prompted whether he/she wants a printed

slip or just the display on screen.

vii. Mini statement: On selection of this option, user’s ten latest transactions will be printed.

viii.PIN change: On selection of this option, a screen with new PIN and reenter new PIN fields will

be displayed. The user fills the fields and clicks on the “change” button. If the new PIN field

entry and the reenter new PIN field entry matches then the PIN will be replaced with the new

PIN number.

ix. Deposit cash: On selection of this option, user is requested to enter the amount he has deposited

in the ATM. Upon confirmation from the user, the transaction will kept in pending for bank

administrator approval.

ADMIN module:

i. Login window of the ADMIN module should have fields for username and password.

ii. Upon authentication of the username and password, then a screen with the following options

appear:

○ ADD customer

○ UPDATE customer info

○ FIND customer

○ PENDING deposits

iii. ADD customer: This option will present a screen to the administrator with the fields to fill the

customer details. After all the fields have been filled, administrator will click the “create”

button, then automatically account number, card number and the PIN number are generated.

103

Appendix A

iv. UPDATE customer info: This option will present a screen to the administrator where he can

fill either the account number or the card number and upon click the “get info” button user info

will be displayed and a provision for updating the info will be provided.

v. FIND customer: This option will present a screen to the administrator where he can fill either

the account number or the card number and upon click the “view” button user info will be

displayed.

vi. PENDING deposits: This option will present a screen to the administrator where all the

pending deposits will be displayed. Upon selection of a particular deposit another screen with

the “DEPOSIT” button will appear. If the DEPOSIT button is clicked, then the amount will be

deposited into the account.

II. Use Cases for Example ATM Banking application:

The following use cases are drawn by the requirements mentioned above. These use cases are

applied for the example persistence layer development.

104

Appendix A

User use case: The following is the use case for User module.

105

Illustration 20: User use case diagram

Appendix A

Administrator use case: The following is the use case for Administrator module.

106

Illustration 21: Administrator use case diagram

Appendix A

III. Domain class diagram: The following is the Class diagram for domain classes of ATM banking application.

107

Illustration 22: ATM banking application Domain class diagram

Appendix A

IV. EER diagram: The following is Enhanced Entity-Relationship diagram for ATM banking application.

108

Illustration 23: ATM banking application EER diagram

a comparative analysis of object-relational mappings for java

Documents