October 25, 2016
Hot Topics:

Web-Application Persistence: JDO & More

  • March 26, 2004
  • By Michael Nash
  • Send Email »
  • More Articles »

One API to Rule Them All?

Just as the JDBC API brought a standard way to access relational databases, the Java Data Objects API, JDO, brings a standard means for accessing all data stores, relational or otherwise. It has the great advantage of being a very simple API, with none of the complexity or required overhead of Entity EJBs—it can, however, co-exist with Entity beans or with many other persistence techniques, as we will see.

JDO is a deceptively simple API: An application that requires access to persistent object acquires a reference to a PersistenceManagerFactory. This factory is in turn used to request PersistenceManager objects. External XML configuration files specify the classes that are to be capable of persistence—the class itself can be written just like any other JavaBean (in fact, it need not even follow the JavaBean standard method signatures necessarily, although this is usually a good idea in any case). All of the elements dealt with by the developer when interacting with JDO are defined as interfaces—the actual concrete implementation of those interfaces is left up to the provider of the JDO implementation. This means that JDO can be used as a "façade" to many existing data storage methods. There is a project underway now, for example, to provide a JDO-compliant API to the Hibernate project.

JDO also allows implementation-specific meta-data to be provided in its configuration. If dealing with a relational database as the underlying store, this might include things such as table names, index information, and so forth. For other types of storage, the meta-data would be different—but the application would not know or care about these differences.

In the diagram below, for example, you can see where the JDO API fits into the web application scenario we've been describing: the application logic may communicate with JDO directly, or with CMP EJBs, which in turn use JDO. The implementation of JDO in use at the time then determines which of the next blocks we will use—and these are not all of the choices, just some of the more common ones.

One thing JDO does not do, however, is provide low-level connection to the underlying data store. As this data store might be any of a number of different things, there is no way to practically achieve this. This concerns some developers who worry they will not be able to use the high-performance or unique features of their particular database platform of choice—even if they are willing to give up the portability that goes along with such a decision. Some JDO implementations, however, provide extensions to the base JDO API that do allow such access—and of course, JDBC is always there if you really need to get right to the database (in a relational environment, of course).

JDO provides full support for transactions, and the underlying implementation may provide for distributed database capabilities—combining a JDBC-based JDO implementation, such as TJDO, for example, and the clustering capabilities of the C-JDBC project can provide a powerful distributed, fail-safe database environment while still adhering to an established and well-documented Java API.

When working in a J2EE/EJB environment, the Entity EJB implementation might well use JDO as the underlying storage mechanism for container-managed persistence (CMP). The developers would then work exclusively with the Entity EJB API, and can remain unaware of JDO entirely in this scenario. Of course, for Web applications that have broad scalability requirements, being deployed in some situations on small servers with a low user load, and in other instances in a clustered, high-availability environment with very large user load, it may be a better choice to utilize JDO directly, allowing a very simple JDO implementation to be used on the low end, and a much more complex (and scalable) one for the high end. Again, the benefit here is that the application code remains entirely untouched.

Web applications, as we said before, may need many different levels of persistence. Having a single common API to work with means that the application itself need not change, even if the scalability requirements do. Using the JDO standard to communicate to whatever the underlying store mechanism is gives us this freedom, and allows our developers to concentrate entirely on Java. At the same time, what the JDO standard does not specify is almost as important as what it does. The initial Sun reference implementation, for example, uses the filesystem for the actual storage mechanism. More complex implementations use JDBC, and still others communicate with ODBMS systems. In every case, the application itself is unchanged—only the JDO implementation in use.

These advantages, and the existence of a standard for object persistence with such an easily adoptable API, make JDO an item worthy of further study for any Web application developer.

About the Author

Michael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at mnash@jglobal.com

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel