Java Reference
In-Depth Information
after applications terminate or sessions end so that their state may be saved for the next execution or
so that they may be shared between different applications.
You know several mechanisms to serve this purpose. The simplest way is through Java serialization.
The
java.io.Serializable
interface gives the programmer a way to explicitly persist objects to an
output stream and later retrieve them by calling, for example,
writeObject(ObjectOutputStream
out)
or
readObject(ObjectInputStream in)
. As a developer, you only need to declare that the
class you are writing implements the
Serializable
interface; the JVM handles the lower-level details
for you transparently. Since the persisted data is coded as Java classes, serialization persistence
supports the object-oriented design and programming paradigm.
Although Java serialization provides a simple and transparent mechanism for persisting objects to an
output stream (mostly to a file system or local disk), it suffers from many limitations. It does not provide
query capability and cannot handle transaction. It does not support partial read and update. The whole
object is read or written in a single operation. Because of these limitations, it is usually not used to
persist business objects in enterprise applications.
JDBC provides a mechanism to store and retrieve data objects to and from a database. It allows an
application access to many types of relational databases through a standard API. The transaction API
ensures concurrency control and therefore allows multiple applications to share persisted data. In the
previous chapters of this topic, you have learned how to use JDBC APIs and have seen what great
tools they are. The downside is that, as a Java programmer, you must know the database structure and
manually map your class attributes to database fields and write all the SQL commands in your Java
code. In other words, persistence is not transparent. In addition, because of the SQL variants among
different types of databases (for example, Oracle and Sybase), your code is not 100-percent portable.
Although Java is a highly object-oriented language, the JDBC uses the relational data model of SQL. It
is based on tables, rows, and columns. The relationships are specified as primary and foreign keys. As
a consequence, a developer has to struggle between the OO object model and the relational data
model. Although you may get used to it after while, the use of different models in the same application is
generally not considered the best approach, and a better approach using a unified model (most
favorably an object-oriented model) is always preferred.
In Chapters 20- 22, you learn that entity EJBs provide another mechanism for data persistence. If CMP
beans are used, you enjoy guaranteed portability because all the database-access calls are declared in
the deployment descriptor. With the so-called "write once, deploy everywhere" approach, you only need
to modify the deployment descriptor when the EJBs are deployed to a different database type or to a
different database schema. The Java code does not need to be modified or recompiled. The EJB
container provides many system-level services such as transaction, security, transparent remote
invocation, and so on. The synchronization between the instance variables and the persisted object
state is also handled by the EJB container in an automatic and optimized manner.
As Java classes (and interfaces), EJBs also support the object-oriented paradigm. However, the current
EJB specification does not support inheritance, and you cannot have a complex object model. Besides,
if BMP entity beans are used, you will have to write all SQL commands in your implementation class.
The JDO specification provides a new persistent mechanism. It has a set of very simple APIs to support
transparent persistence. The Java code is totally decoupled from the underlying data store, which leads
to the "write once, persist everywhere" approach. JDO is fully object oriented and hence is able to
support complex domain object models. The optimization of database read and update is performed at
the JDO implementation layer and is transparent to application developers. Unlike EJBs, it can be used
outside a container and used for batch processes. If combined with J2EE components (for instance,
servlets, JSPs, and EJBs), it enjoys the system-level services that containers provide.
As an example, the
Yacht
class listed in
Listing 23-1
is all you need to code to persist
Yacht
objects. It
is basically a JavaBean class with some persistable attributes and access methods to these attributes.
Compared with the
YachtEJB
you see in
Chapter 22
, the code is much simpler, and there is not even a
slight hint of an underlying database as the persistent store. Similar to EJB's deployment descriptor, you
declare that the class
Yacht
is persistence-capable in an XML MetaData file. But you see later that an
XML MetaData file is normally much simpler and shorter than an EJB deployment descriptor.
