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

advertisement

AddThis Social Bookmark Button O'Reilly Book Excerpts: Java Data Objects

JDO Architectures

Related Reading

Java Data Objects
By David Jordan, Craig Russell

by David Jordan and Craig Russell

Editor's Note: In this excerpt from Java Data Objects, authors David Jordan and Craig Russell provide a high-level overview of the architectural aspects of JDO, as well as examples of environments in which JDO can be used.

One of JDO's primary objectives is to provide you with a transparent, Java-centric view of persistent information stored in a wide variety of datastores. You can use the Java programming model to represent the data in your application domain and transparently retrieve and store this data from various systems, without needing to learn a new data-access language for each type of datastore. The JDO implementation provides the necessary mapping from your Java objects to the special datatypes and relationships of the underlying datastore. Chapter 4 discusses Java modeling capabilities you can use in your applications. This chapter provides a high-level overview of the architectural aspects of JDO, as well as examples of environments in which JDO can be used. We cannot enumerate all such environments in this book, because JDO is capable of running in a wide variety of architectures.

A JDO implementation is a collection of classes that implement the interfaces defined in the JDO specification. The implementation may be provided by an Enterprise Information System (EIS) vendor or a third-party vendor; in this context, we refer to both as JDO vendors. A JDO implementation provided by an EIS vendor will most likely be optimized for the specific EIS.

The JDO architecture simplifies the development of scalable, secure, and transactional JDO implementations that support the JDO interface. You can access a wide variety of storage solutions that have radically different architectures and data models, but you can use a single, consistent, Java-centric view of the information from all the datastores.

The JDO architecture can be used to access and manage data contained in local storage systems and heterogeneous EISs, such as enterprise resource planning (ERP) systems, mainframe transaction processing systems, and database systems. JDO was designed to be suitable for a wide range of uses, from embedded small-footprint systems to large-scale enterprise application servers. A JDO implementation may provide an object-relational mapping tool that supports a broad array of relational databases. JDO vendors can build implementations directly on the filesystem or as a layer on top of a protocol stack with multiple components.

JDO has been designed to work in three primary environments:

  • Nonmanaged, single transaction
    Involves a single transaction and a single JDO implementation, where compactness is the primary concern. Nonmanaged refers to the lack of distribution and security within the JVM. The security of the datastore is implemented by name/password controls.

  • Nonmanaged, multiple transactions
    Identical to the first, except that the application uses extended features, such as concurrent transactions.

  • Managed
    Uses the full range of capabilities of an application server, including distributed components and coordinated transactions. Security policies are applied to components based on user roles and security domains.

You can focus on developing your application's business and presentation logic without having to get involved in the issues related to connecting to a specific EIS. The JDO implementation hides the EIS-specific issues, such as datatype mapping, relationship mapping, and the retrieval and storage of data. Your application sees only a Java view of the data, organized as classes using native Java constructs. EIS-specific issues are important only during deployment of your application.

In a nonmanaged environment, you do not rely on the managed services of security, transaction, and connection management offered by a middle-tier application server. Chapters through cover the uses of JDO in a nonmanaged environment, most of which also apply to a managed environment.

When JDO is deployed in a managed environment, it uses the J2EE Java Connector Architecture, which defines a set of portable, scalable, secure, and transactional mechanisms for integrating an EIS with an application server. These mechanisms focus on important aspects of integration with heterogeneous systems: instance management, connection management, and transaction management. The Java Connector Architecture enables a standard JDO implementation to be pluggable across application servers from multiple vendors.

Managed environments also provide transparency for application components' use of system-level mechanisms--distributed transactions, security, and connection management--by hiding the contracts between JDO implementation and the application server. Chapter 16 covers the use of JDO in the web server environment. Chapter 17 explains how to use JDO to provide persistence services in a J2EE application-server environment, which supports the Enterprise JavaBeans (EJB) architecture.

Multiple JDO implementations--possibly multiple implementations per type of EIS or local storage--can be plugged into an application server concurrently, or they can be used directly in a two-tier or embedded architecture. JDO also allows a persistent class to be used concurrently with multiple JDO implementations in the same Java Virtual Machine (JVM) or application-server environment. This enables application components--deployed on a middle-tier application server or client-tier--to access the underlying datastores using the same consistent, Java-centric view of data.

The persistent classes that you define can migrate easily from one environment to another. This also allows you to debug persistent classes and parts of your application code in a simple one- or two-tier environment and deploy them in another tier of the system architecture.

Architecture Within Application JVM

JDO supports a variety of architectures within the application's JVM context. Your application can have one or multiple PersistenceManagers accessing the same or different datastores concurrently. Each PersistenceManager has its own persistent instance cache and its own associated Transaction instance, which manages a distinct transactional context. A JDO implementation may also maintain a shared cache of instances (not visible to applications) to optimize the application's access of data in the datastore.

Single PersistenceManager

The simplest JDO application architecture has a single PersistenceManager, as illustrated in Figure 3-1. A PersistenceManager is the primary interface used by the application to access persistent services. It is an interface that is implemented by an instance of the JDO implementation. The persistent instances are managed in a cache, where they are used directly by the application. The JDO implementation manages the persistent instances both by using application control (e.g., using PersistenceManager and Query methods), and transparently (when the application accesses a field that is not loaded). The cache contains other artifacts, used to track the identity and state of the instances, but these artifacts are not visible to the application. Whenever we mention the cache, we are referring to the cache of persistent instances.

Figure 3-1. Application using a single PersistenceManager to access a datastore

The application cache is not a specific region of memory, as Figure 3-1 might imply; it is simply part of the JVM's object heap. Each persistent class has a field, named jdoStateManager, added by the enhancer to reference a StateManager. The StateManager manages the field values and lifecycle state of the instance, and has a reference to its associated PersistenceManager. A PersistenceManager may use one or more StateManagers; this detail is implementation-specific. The jdoStateManager field for any instance being managed (either a persistent or transient transactional instance) is set to reference a StateManager; otherwise, the jdoStateManager field is null.

A persistent instance in the cache can directly reference other persistent instances in the same cache. You can navigate from one instance to another using standard Java syntax. Instances of transient classes (for example, your application class) can also reference these persistent instances. A persistent instance in the cache can also reference transient instances of both persistent and transient classes. The persistent classes themselves are responsible for managing references to transient instances; the JDO implementation does not manage these references.

Figure 3-2 shows the relationships between the persistent instances, the StateManager, and the PersistenceManager. Each persistent instance contains a reference to a StateManager, which can manage one or more persistent instances. Each StateManager contains a reference to its PersistenceManager, which can manage one or more StateManagers. Each PersistenceManager contains a reference to its PersistenceManagerFactory, which can manage one or more PersistenceManagers. Each PersistenceManager can manage one transaction serially, and contains a reference to its Transaction instance. The PersistenceManager uses a StoreManager to interact with the datastore; this relationship is not defined by the JDO specification.

Figure 3-2. UML diagram of persistent instance cache

Pages: 1, 2, 3

Next Pagearrow