JDO(Java Data Objects)

Java Data Objects (or JDO in short) is a new specification that handles Java objects' storage to any DBMS transparently to the application and the developer. It is the new standard way to interact with any kind of database (RDBMS, ORDBMS, OODBMS, filesystem) without thinking of the specifics of each database. The developer only designs their business model, and it is JDO's task to map it to the database of choice.This standard allows Java developers to use their object model as a data model, too. There is no need to spend time going between the "data" side and the "object" side.

Java Data Objects or JDO is Java's new API for interacting with databases. JDO API is a standard interface-based Java model abstraction of persistence, developed as Java Specification Request 12 JSR 12 under the auspices of the Java Community Process. JDO helps the programmer to write data access programs with less programming and thus increasing the productivity of the programmers. JDO operates at a higher level, transparently transferring data between in-memory Java objects and your database.

JDO UNPLUGGED – PART IJava Data Objects is an 'Object Relational Mapping' Technology developed by Java Community Process (JCP), with active support from Sun MicroSystems. Craig Russell is the specification lead for the JDO expert group and David Jordan is an active member of that group.

Java Data Objects is an 'Object Relational Mapping' Technology developed by Java Community Process (JCP), with active support from Sun MicroSystems. Craig Russell is the specification lead for the JDO expert group and David Jordan is an active member of that group.

Before the advent of JDO, we had various sun's official standards for storing data like JDBC and EJB with CMP and BMP. Also there are a number of ORM tools like Hibernate from SourceForge, Object Relational Bridge (OJB) from Apache, Toplink from Oracle etc., in this article we shall the unique features of JDO and how it differs from the rest of the technologies.

When we use JDBC, we have to manage the values of the fields explicitly and map them into the relational database tables. The developers have to write their SQL code. Also they have to implement their own mapping between the relational data model and their java object model which is very complex. Hence the benefits of Object-Oriented development are lost.

JDO UNPLUGGED – PART IIThe JDO examples can be tested by using sun's JDO reference implementation. A number of other JDO implementations are also available. The JDO reference implementation can be downloaded from www.jcp.org and selecting JSR-12 or can be downloaded from sun java website.1. Jdo.jar: It contains the standard interfaces and classes defined in the JDO specification.2. Jdori.jar: It is the sun's reference implementation of JDO specification.3. Btree.jar: It is software used by JDO reference implementation to manage the storage of data in a file. 4. jdori-enhancer.jar: It contains the reference enhancer implementation. The classes of this jar file are also present in jdori.jar and so we do not need this jar. By using this jar, we can create JDO in

1

any implementation and enhance the classes using this enhancer also. Also there are three other jar files needed for our application. They are,1. jta.jar: The synchronization interface defined in package javax.transaction is used in JDO interface. It is present in this jar file. The jar file can be downloaded form http://java.sun.com/products/jta/index.html2. antlr.jar: It is the parsing technology used in the implementation of JDO query language. It can be downloaded from http://www.antlr.org3. xerces.jar: Xerces-j is used to parse XML file and it can be downloaded from http://xml.apache.org/xerces-j/.These three jars can be found in lib directory of hibernate (both 2 and 3) also.

JDO is now in version 2.0 (JSR 243) with many new additions and enhancements. Advantages:● It is a standard on which vendors are based to build their implementations. This means, that you can choose another vendor, while in the mid of development, and you don't need to change a single line of code of your application (as long as you don't use any of the vendor's extensions to the standard). ● JDO runs with all Java 2 SE 1.3+ versions, J2EE and most implementations support a large number of JDBC drivers. ● Training time to start up on JDO is short ● Development and delivery times are reduced and source code quality is increased ● Version 2.0 is mature for developing production code.

The JDO ArchitectureThe high-level JDO API is designed to provide a transparent interface for developers to store data, without having to learn a new data access language (such as SQL) for each type of persistent data storage. JDO can be implemented using a low-level API (such as JDBC) to store data. It enables developers to write Java code that transparently accesses the underlying data store, without using database-specific code. JDO was developed as a JSR in the Java Community Process (JCP) program: JDO 1.0, in existence since 2002, is JSR 12; and JDO 2.0, approved in early 2005 and under development, is JSR 243. JDO 2.0 is a rich and full-featured JSR specification for Plain Old Java Objects (POJOs) persistence, and multiple vendors are providing competing implementations. In addition, many vendors will likely implement JDO 2.0 and EJB 3.0 in the same product. This will allow you to use both APIs at the same time, giving you an easier way to gradually migrate to EJB 3.0 POJO, which will become the persistence model of choice. The two main objectives of the JDO architecture, which is shown in Figure 1, are to provide Java application developers a transparent Java technology-centric view of persistent information and to enable pluggable implementations of data stores into application servers.

It is important to note that JDO does not define the type of data store: You can use the same interface to persist your Java technology objects to a relational database, an object database, XML, or any data store. The benefits of using JDO are the following: Portability: Applications written using the JDO API can be run on multiple implementations available from different vendors without changing a single line of code or even recompiling.

2

Transparent database access: Application developers write code to access the underlying data store without any database-specific code.Ease of use: The JDO API allows application developers to focus on their domain object model (DOM) and leave the details of the persistence to the JDO implementation.High performance: Java application developers do not need to worry about performance optimization for data access because this task is delegated to JDO implementations that can improve data access patterns for best performance. Integration with EJB: Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security using the same DOMs throughout the enterprise.

Use of JDO vs. JDBC and EJBJDO is not meant to replace JDBC. They are complementary approaches with unique strengths, and developers with different skill sets and different development objectives can use either. For example, JDBC offers developers greater flexibility by giving them direct control over database access and cache management. JDBC is a more mature technology with wide industry acceptance. JDO, on the other hand, offers developers convenience by hiding SQL. This frees Java platform developers to focus on the DOM without necessarily knowing or having to learn SQL, while JDO takes care of the details of the field-by-field storage of objects in a persistent store. JDO is designed to complement EJB. EJB CMP provides portable persistence for containers, and JDO can be integrated with EJB in two ways: (1) through Session Beans with JDO persistence-capable classes to implement dependent objects (persistent helper classes for Session Beans) and (2) through Entity Beans with JDO persistence-capable classes used as delegates for both Bean Managed Persistence (BMP) and Container Managed Persistence (CMP).

JDO Class TypesThere are three types of classes in JDO: Persistence-capable: This category represents classes whose instances can be persisted to a data store. Note that these classes need to be enhanced according to a JDO metadata specification before they are used in a JDO environment.Persistence-aware: These classes manipulate persistence-capable classes. The JDOHelper class provides methods that allow interrogation of the persistent state of an instance of a persistence-capable class. Note that these classes are enhanced with minimal JDO metadata.

3

Normal: These classes are not persistable and have no knowledge of persistence. They require no JDO metadata.

Life Cycle of JDO InstancesJDO manages the life cycle of an object from creation to deletion. During its life, a JDO instance transitions among various states until it is finally garbage collected by the Java Virtual Machine (JVM). The transition between states is achieved using methods of the PersistenceManager class including the TransactionManager -- such as makePersistent (), makeTransient (), deletePersistent () -- and committing or rolling back changes that such operations make. Table 1 shows the 10 states defined by the JDO specification. The first seven states are required, and the last three are optional. If an implementation does not support certain operations, then the three optional states are not reachable.

Table 1: The JDO Life-Cycle States

State Description

TransientAny object created using a developer-written constructor that does not involve the persistence environment. No JDO identity is associated with a transient instance.

Persistent-new

Any object that has been requested by the application component to become persistent using the makePersistent() method of the PersistenceManager class. Such an object will have an assigned JDO identity.

Persistent-dirty Any persistent object that was changed in the current transaction.

HollowAny persistent object that represents specific data in the data store but whose values are not in the instance.

Persistent-cleanAny persistent object that represents specific transactional data in the data store and whose values have not been changed in the current transaction.

Persistent-deletedAny persistent object that represents specific data in the data store and that has been deleted in the current transaction.

Persistent-new-deleted

Any persistent object that has been made newly persistent and deleted in the same transaction.

Persistent-nontransactional

Any persistent object that represents data in the data store, whose values are currently loaded but not transactionally consistent

Transient-clientAny persistent object that represents a transient transactional instance whose values have not been changed in the current transaction.

Transient-dirtyAny persistent object that represents a transient transaction instance whose values have been changed in the current transaction.

The goal of the JDO is to allow a Java application to transparently store instances of any user-defined Java class in a datastore and retrieve them again, with as few limitations as possible. This book refers to the instances that JDO stores and retrieves as persistent objects. From the application perspective, these persistent objects appear as regular, in-memory Java objects. However, the fields of these instances are actually stored in some underlying datastore persistently—all without any explicit action on behalf of the application.

4

JDO has nothing to do with where methods are executed; it does not provide a means of remote method invocation a la RMI and EJB, nor does it store and execute methods in some datastore. JDO simply specifies how the fields of a persistent object should be managed in-memory, being transparently stored to and retrieved from an underlying datastore. With JDO, methods are invoked on a persistent object by an application as per any regular in-memory Java object.

State transitions of JDO instances.

5

RMI and JDO

The Transfer Money logic is as follows:1. The IIOP Client (IIOPClient.java) obtains a reference to the TellerRemote (TellerRemote.java) remote object from Teller Server (TellerServer.java).2. The IIOP Client (IIOPClient.java) invokes the transferMoney () method of the TellerRemote (TellerRemote.java) object.3. The TellerRemote (TellerRemote.java) invokes the TransferMoney () method on the JDO Client (Teller.java).

6

4. The JDO Client (Teller.java) obtains a configured PersistenceManagerFactory from the JDOAdapter.5. The JDO Client (Teller.java) uses the configured PMF to get a PersistenceManager.6. The JDO Client (Teller.java) uses the Persistence Manager to obtain a Transaction object.7. The JDO Client (Teller.java) begins a new Transaction using the Transaction object.8. The JDO Client (Teller.java) invokes the credit method on the Checking object.9. The JDO Client (Teller.java) then invokes the debit method on the Savings object.10. The JDO Client (Teller.java) then commits the transaction by invoking the method in the Transaction object.11. The JDO Client (Teller.java) then closes the Persistence Manager.12. The JDO Client (Teller.java) then closes the JDOAdapter.

7