Java Reference
In-Depth Information
In the XML MetaData file, all persistent-capable classes, as well as their relationships, are defined.
Although the XML MetaData files can be created manually, many JDO implementations provide tools to
help you with their creation. You should use the tools whenever they are available.
After the persistent classes are compiled by a Java compiler into bytecode, the Java class files are fed
into the JDO enhancer, along with the XML MetaData file. The enhancer modifies the bytecode by doing
the following:
Making the class implement the
javax.jdo.PersistenceCapable
interface
Adding implementations of
javax.jdo.PersistenceCapable
required methods based on the
object relationship and underlying database structure
Creating a database schema, if needed, for data persistence
Adding any other necessary functionalities for optimized and transparent persistence
These JDO-enhanced classes are loaded into the JVM at the runtime. The XML MetaData file is also
read by the JVM at the runtime to guide data persistence. The JDO-aware applications' development
and execution process is shown in
Figure 23-2
.
Figure 23-2:
The JDO application-development and execution process
You can see from
Figure 23-2
that only JDO enhanced classes are loaded into the JVM. Since the
enhancer does all the persistence-support work, developers can focus on the implementation of
business logic. On the other hand, you have to pay attention to the so-called performance penalty.
Since the enhanced classes are generally larger than the plain class files, business logic is normally
separated from the persistent classes and instead placed into the business classes. The business
classes are not enhanced and thus have smaller footprints. At runtime, it is obvious that unnecessary
network traffic on the database (typically residing on another network note) deteriorates performance.
To overcome this potential weak point, most JDO implementations have a complex cache system.
Another important design target for all JDO enhancers is to provide compatibility among different
database vendors and different JDO implementations. As the technology matures, more and more high-
quality JDO implementations will become available.
In the previous chapters you learned about EJBs, the fundamental components of J2EE framework.
Can you fit the JDO int o the J2EE framework? Absolutely yes. The
next section
explains how it can be
achieved.
Integration of JDO with the J2EE Framework
Unlike J2EE components, JDOs do not need to run inside a container. They can be used in any
standalone applications. This makes them suitable for many batch processes.
On the other hand, JDOs do not enjoy the system-level support provided by containers such as
transaction, security, transparent remote invocation, and so on. Application developers may have to
code these system-lever services if they are needed, which prolongs the development cycle and may
make the application more vulnerable to all kinds of defects.
The best way to develop an enterprise application may be by combining the better of the two worlds:
using the container services provided by the J2EE framework and the transparent persistence provided
