Overview of Persistence Technologies
The second main topic for today is to discuss persistence options and look at some of the Java technologies available in this space. At this point, you might be thinking that this is a moot point; after all, you learned yesterday and on Day 6 how to develop Entity beans, so what else is there to address?
In response to that question, consider the following two points. First, you used JDBC to implement BMP Entity beans on Day 6. However, there are other technologies that may involve less work and could even lend themselves to code generation, or indeed, support persistence transparently. Second, many J2EE applications will not use EJBs. There are many successful J2EE enterprise applications built only with servlets, JSPs, and data access code. Moreover, commercial EJB containers can be costly to purchase, and this might also be a consideration for your organization.
The three technologies that you will learn more about are as follows:
JDBC— This is the most mature of the Java persistence technologies. There have been multiple versions over the last few years (sometimes renamed along the way), which can be confusing.
The JDBC API itself is not covered, because it is presumed that you are or have become familiar with it.
SQLj— This is actually three specifications that combine Java and SQL, either client-side or within the RDBMS. Some aspects of SQLj are supported through JDBC (v2.0 and later).
At the time of writing, SQLj was being developed by a consortium of companies that includes Sun, Oracle, IBM, and Sybase. You can learn more at http://www.sqlj.org.
Java Data Objects (JDO)— This aims to make persistence transparent, either for small embedded applications or large scale enterprise applications. This latter objective means it can either replace or supplement Entity EJBs. (At the time of writing, this specification was still in draft.)
At the time of writing, JDO was being developed through the Java Community Process, JSR-000012. You can learn more at http://access1.sun.com/jdo. You can learn about its relationship with JDBC at http://java.sun.com/products/jdbc/related.html.
This is by no means a definitive list. Specifically, there is nothing to prevent you from using a vendor-specific API to persist your data, as is used by most OODBMS vendors. While OODBMSs are not as mainstream nor as prevalent as RDBMSs, they have many advocates who argue vociferously that the best place to store objects is in an object-based database. Examples of OODBMS products include (in no particular order) O2, Objectivity, ObjectStore, Versant, FastObjects (previously POET), Persistence, Jasmine, Gemstone, and ozone. From a J2EE perspective, many of the OODBMS vendors have re-branded their products to be EJB application servers, while others have positioned their technology to provide a simple way to implement persistence (within a BMP Entity bean).
Yet another alternative is to use an object/relational mapping product. In a sense, these tools combine the familiarity of RDBMS with the intuitiveness of objects. The information that maps the object instances to the relational schema is usually held in a tool-specific repository of some sort, similar in concept to the information provided in a CMP Entity bean's deployment descriptor, although typically much more complex and sophisticated. These O/R mapping products usually have sophisticated caching algorithms (for example, predictively loading related persistent data) that can radically speed up performance. On the other hand, one downside is that there is a learning curve to effectively configure and maintain the mapping data; sometimes professional assistance is needed. There are a number of O/R products around, including (in no particular order) TopLink, CocoBase, JavaBlend, JRelay, OJB, DBGen, JDX, and ObjectDriver.
Whether you can use any of these technologies may depend on the standards and constraints in your organization. Certainly, the vendors of OODBMS and O/R mapping products claim substantial decreases in the time taken to develop code.
Note
As you will see shortly, one of the implicit objectives of JDO is to create a standard Java API for OODBMS and O/R mapping products. This may well cause these products to be adopted by a wider audience.
On the other hand, another consideration for you is the requirement for EJB container vendors to support CMP 2.0. You may find that some EJB vendors address this requirement simply by cross-licensing one of the more established O/R mapping tools. This is arguably the best of both worlds; you have access to a mature O/R mapping technology, but configured using an industry-standard EJB deployment descriptor.