Datastore Access

We have explored the architecture in the application's JVM and
discussed the application cache and implementation cache. Now let's examine
the architectures of JDO implementations. We'll discuss each type of datastore
separately.

These architectures don't affect your application's programming
model, but they affect the configuration of the environment in which your
application executes. In particular, the ConnectionURL property of the Properties instance used to construct the PersistenceManagerFactory refers to a local or remote
datastore.

Direct Access of Filesystem or Local Datastore

Some JDO implementations store the objects directly in a local
filesystem or datastore. Figure 3-1 illustrates this architecture. There is only a single process context in this architecture. The JDO implementation uses the Java I/O classes
directly to manage the storage of the objects in a file. The JDO Reference
Implementation implements this architecture, as do some object databases.

Remote Access of a JDO Server

Some JDO implementations connect to a separate server that
manages the datastore, as illustrated in Figure 3-7. The JDO Reference Implementation implements this architecture, as do most object databases. In this particular example, the JDO implementation
itself provides a server built specifically for object storage, which then
manages the filesystem directly. The component that executes in the same JVM
as the JDO implementation and communicates with the remote server is called a
resource adapter. The protocols between the client JVM
and the JDO Server are vendor-specific.

Figure 3-7. Client access of a JDO server

Remote Access of a SQL Datastore

Figure 3-8 illustrates the use of a relational database server for object
storage. This is the most common architecture used by current commercial JDO
implementations. Since the application is written in Java, the JDO
implementation uses JDBC to communicate with the database server. When you
deploy your application, you use a proprietary tool supplied by the JDO vendor
to map your application's Java objects to tables in the relational database.
Some JDO implementations use your application's persistent object model to
create the relational schema for you.

Figure 3-8. Client access of a SQL datastore

The relational vendor or a third party provides a JDBC driver to
communicate with the database, using protocols specific to the database. The
JDBC driver is the resource adapter in this architecture.

Since the JDBC interface is well defined, this architecture
offers a high degree of portability. JDO implementations have been written to
use a variety of datastores that provide a JDBC driver implementation. While
the JDBC interface is standard, the SQL data manipulation language, used by
the relational databases, varies considerably; the JDO implementation hides
these differences from JDO applications.

System Architectures with a JDO Application

Now we'll examine where JDO objects and application logic can be
placed relative to an application's overall system architecture, including
both managed and nonmanaged environments. In the remaining examples in this
chapter, we don't show the details of how the JDO implementation manages the
storage for the persistent instances.

JDO Rich Client with Local Datastore

The simplest form of system architecture is a one- or two-tier
application that may be executed from the command line, from a shell script,
or via a graphical user interface. We refer to the application as a rich client to distinguish it from a browser that simply displays HTML and executes applets. The application uses local filesystem and
JDO persistent services directly.

JDO Applications in a Web Server

Figure 3-9 illustrates how an application can use JDO to provide persistent
services to the implementation of a web servlet or JavaServer Pages (JSP).
When using JSP pages, the application typically will use JDO in one of two
ways: by calling JDO's APIs directly in Java, or using a JSP tag library to
abstract the JDO API (similar to the way the JSP Standard Tag Library
abstracts the JDBC API).

Figure 3-9. JDO application running in a web server

With this architecture, the servlet/JSP page gets data from the
browser in the form of strings from an HTTP doGet( ) or doPost( ) request and uses JDO to
implement the request. Your application may use the Struts framework to implement the servlets and JSP pages
in this architecture. We will discuss the web-server access patterns in detail
in Chapter 16.

JDO Applications as Web Services

Figure 3-9 also illustrates the use of JDO as the persistence implementation for
a web server implementation of a web services endpoint. The web server may
register the service using UDDI and a registry service, and clients may find
the service via the same registry.

A web server implementation uses a servlet to implement the
service endpoint. The servlet can use the JDO API for the persistent service,
exactly as it does for servicing HTTP requests. The primary difference between
SOAP and standard HTTP is that with SOAP requests, the message data in the
HTTP message is formatted as SOAP XML instead of get/post data.

Rich Client Connecting to Application Server with EJB Components

Figure 3-10 illustrates a rich client connecting directly to an application
server using EJB beans. This architecture typically is implemented behind the
firewall of a company, as it directly exposes enterprise services to clients.
The clients use the JNDI services of the J2EE client container to look up
services by name (including EJB beans) and to connect to the server via
RMI/IIOP or a proprietary protocol. Alternatively, a client may use SOAP
protocols to access the middle-tier server.

The EJB components inside the EJB container use other EJB
components to implement their services. They use a combination of JDBC and JDO
to access persistent services. Session beans and message-driven beans use JDO
and JDBC directly. Entity beans use JDO transparently (the container
implements CMP entity beans using JDO but does not expose JDO as an API to the
CMP developer).

Web Server with EJB Server

Figure 3-11 illustrates servlets and JSP pages that use the services of an EJB
container to implement the business logic of an enterprise application. The
EJB beans executing inside the EJB container use JDO as their persistence
service. The web and EJB containers often reside in the same JVM in this
architecture, even though they represent different tiers of the architecture.

EJB Session Beans Using Session Bean Fašades

Figure 3-12 illustrates the session bean delegating parts of the business logic
to session bean fašades that use JDO as their implementation. This
architecture allows location transparency among the components. For example,
if the session bean that interacts directly with clients delegates part of the
functionality to other session-bean components, this architecture allows the
other components to be located in different machines. Chapter 17 describes
this architecture in detail.

Figure 3-12. EJB session beans using session bean delegates

JDO Providing Container-Managed Persistence

As a side note, an EJB server may implement J2EE
container-managed persistence (CMP) entity beans using JDO as the persistence
layer. The J2EE components and the users of these components are unaware that
JDO is used for the implementation of the persistence
service.

David Jordan
founded Object Identity, Inc. to provide Java Data Objects (JDO) consulting and training services. David is also a coauthor of O'Reilly's book on Java Data Objects, with Craig Russell.