About the Frameworks Series
Besides the Java language, a world of Java frameworks exists. These frameworks can afford substantial improvements in programmer productivity and enhance the quality, performance, reliability, and interoperability of different Java applications. Fortunately, many of these popular and widely used frameworks are open source projects, so anyone can benefit from them if he can invest some time learning when and how to use such frameworks. This article is the second installment in the frameworks series and aims to introduce persistence frameworks in general and the open source Java persistence framework, Castor JDO, in particular.
To read previously published article in this series, follow this link: Frameworks.
Most enterprise applications need access to a relational database. The Java standard for accessing relational databases is the JDBC APIs that utilize SQL as a data manipulation language. This approach of directly accessing a relational database from an object-oriented Java application was shown to be inefficient and introduces a problem called "object-relational impedance mismatch," or simply "impedance mismatch" for short.
Impedance mismatch refers to the differences between object-oriented technology and relational technology. Object technology relies on objects that have data and behavior. Relational technology supports the storing of data in tables and handling these data via a Data Manipulation Language (DML) such as SQL. Furthermore, objects have identity and are traversed using direct access, whereas RDBS tables have a primary key and are related via values in foreign and primary keys. Finally, RDBMS has no equivalent to Java's object inheritance for data and behavior.
An approach for solving the impedance mismatch problem is to introduce an abstract layer, called a persistence layer, between the relational database and the object model of the application, as in Figure 1. This layer fully encapsulates the database access from your business objects. Thus, instead of writing code to handle your database, you are required only to define meta-data that represents how your relational database will be mapped into objects and deal directly with these objects.
Figure 1: Persistence Frameworks adds an abstraction layer between the OO application model and the relational database
Sun's Java Data Objects (JDO)
The Java Community Process (JCP) developed the standard JDO as a high-level API specification and a reference implementation. JDO transparently handles the mapping of Java objects to relational databases.
Sun didn't distribute a free JDO implementation, but it released a reference implementation. This reference implementation is a way for Sun to prove that the specification is available. Instead of using a relational database, the reference implementation writes the persistent objects to the file system. Of course, there exist commercial implementations that are compatible with Sun's JDO specifications. Some of these products are listed in Table 1.
|Table 1: Commercial JDO Tools|
|Hemisphere Technologies||JDO Genie|
|Prism Technologies||OpenFusion JDO|
|Poet Software||Fast Objects|
Open Source Persistence Frameworks
In addition to the JDO commercial products, a number of free and robust persistence frameworks exist. These frameworks have the same target as Sun's JDO although they are not compatible with the JDO standards. Three of the most popular persistence frameworks in the open source community are Hibernate, Castor, and OJB.
The Castor JDO is an open source persistence framework developed under the auspices of exolab.org. As with Sun's JDO, Castor JDO aims to transparently persist Java objects. However, you should remember that Castor JDO is not an implementation of Sun's JDO.
Working with Castor JDO could be briefly described in the following four steps:
- Write a configuration file.
- Write mapping file(s).
- Implement persistent objects.
- Issue queries using Castor's Object Query Language (OQL).
Database Configuration File
To access a database, you first need to establish a connection to it. Castor maintains information required to access a database (e.g. name, engine) in a configuration file named "database.xml".
This configuration file specifies the means to obtain a connection to the database server, the mapping between Java classes and tables in that database server, and the service provider to use for talking to that server.
A typical example of a database configuration file is shown in Listing 1.
<database name="shippingDB" engine="postgresql"> <driver class-name="org.postgresql.Driver" url="jdbc:postgresql:shippingDB"> <param name="user" value="Administrator"/> <param name="password" value=""/> </driver> <mapping href="mapping.xml" /> </database>
Listing 1: database.xml configuration file
The database to connect to is specified by the name attribute and the database engine is specified by the engine attribute. The <driver> element specifies the JDBC driver for this database engine and the URL path to the shippingDB.The <param> elements have user and password information that the driver needs to log in to the database. Finally, the mapping file and its location are specified by using the <mapping> element and the href attribute.