hese days almost every application requires some sort of data persistence, whether local, remote, or both. Developers traditionally have built applications with a specific data store and source in mind, using data store-specific APIs. This approach becomes troublesome and resource-intensive when trying to support and certify an application on numerous persistent data stores. Still, developers have had no choice but to learn, code, and test data source-specific APIs, despite the significant added overhead in the product lifecycle.

The JDO specification defines a set of Java APIs that exposes a consistent model to programmers interacting with disparate data sources.

For persistence storages like file systems, RDMSs, and object-oriented databases, Java Data Objects (JDO) provides a better and more efficient approach to application development. JDO provides developers with another layer of abstraction that encapsulates data store-specific details, letting application programmers concentrate on business logic rather than persistence storage intricacies. JDO provides a Java object interface to the data source, so developers perform data operations the same way they treat any other Java object. The result is faster application development (read quicker time to market) and fewer worries about persistent data storage.

JDO Overview
The two main goals of the JDO specification are to provide:

For software vendors: Detailed contracts and clear declarations of roles and responsibilities for application servers and JDO implementation providers so that various data stores can be plugged seamlessly into their applications.

?
	Figure 1 | A typical JDO-based application scenario

JDO addresses not only enterprise data, but also persistent data in general (even in embedded systems). In a two-tier environment, JDO hides the details of data storage, types, relationships, and retrieval. In the more complex managed multi-tier environment JDO also handles concurrency issues, transactions, scalability, security, and connection management.

JDO Query Example (cont’d)
PropertySearch was developed, debugged, deployed, and tested using Sun’s Forte for Java 4.0 Enterprise Edition Early Access IDE environment. The Forte for Java 3.0 Enterprise Edition was used during the initial development steps. Hence, to compile, deploy, and run this application, you must use three tag libraries (dbtags.jar, ietags.jar, tptags.jar) shipped with Forte for Java. I used the PointBase database (the evaluation version is bundled with Forte for Java) to test PropertySearch (the database creation scripts are provided with the source code).

?
	Figure 4 | Price-based query results from PropertySearch

Listing 1 illustrates how PropertySearch’s queries work. The featured code snippet is from SearchPropertiesBean.java. It creates the database connection, constructs the query criteria, executes the queries, and sends the results back to the JSP page. To keep the listings short, only the relevant and interesting portion is listed.

As you can see, JDOQL enables you to dynamically build and execute complex queries using Java-like syntaxes. The readme file included with the source code has more detail on how to compile, build, deploy, and execute PropertySearch in a development environment. Figure 4 shows a typical PropertySearch query result where the user has specified the maximum price of the desired property.

With the JDO specification’s easy integration with EJBs in a managed environment and effective use with servlets, JSP, and other J2EE server technologies, more and more J2EE container providers are going to adopt JDO to make their offerings feature-rich and standardized. The days of complete data “transparency” may come sooner than we think.