ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

JDO Architectures
Pages: 1, 2, 3

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.

Figure 3-10. Rich-client connection to an application server using EJB beans

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.

Figure 3-11. Servlets and JSP pages access services of the EJB container

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.

Craig Russell is the specification lead for JDO at Sun Microsystems.


Return to ONJava.com.