Java Data Objects

About

Features

• The first book on Java Data Objects.
• Shows how to build flexible application architectures that integrate seamlessly with Java 2 Enterprise Edition (J2EE)
• Demonstrates JDO's applicability to enterprise, simple client-server and embedded Java 2 Micro Edition (J2ME) environments.
• Discussion of how to streamline the development of applications with JDO.
• Companion CD-ROM includes the following JDO Implementations - FastObjects, Kodo JDO, LIDO and OpenFusion JDO.
• Covers the latest version of JDO 1.0

Description

Java Data Objects is a standardized Java API for object persistence. It facilitates the storage and retrieval of complex object models with various storage mechanisms, including both object and relational databases. Analysts agree that JDO's transparent persistence will accelerate software development and yield more flexible applications and object models.

According to Infoworld, "The JDO standard promises to be a winner for business leaders and corporate developers alike. Unifying data access--that is, using familiar Java constructs to access information housed in relational databases, object databases, file systems, or even flash RAM--means that corporate applications will experience an increase in usability, portability and integration".

This book is for Java developers, designers and architects with a good understanding of the Java language who wish to write applications that use JDO for persistence. Prior knowledge of JDBC and J2EE is not specifically required, but would help to accelerate the reader's understanding of JDO's relationship with these technologies.

The companion CD-ROM includes the following JDO implementations:FastObjects, Kodo JDO, LiDO and OpenFusion JDO.

Sample Content

Online Sample Chapter

JDO Architecture

Table of Contents

Acknowledgements.
Foreword.
Preface.
What is JDO?
To Whom Will JDO be Important?
Who Should Read this Book?
Organization.
CD contents.
JDO Version Information.
About the Author.
About the Cover Illustration.
1. Understanding Object Persistence.
What is Object Persistence?
Current Techniques for Persistence.
Object Persistence with JDO.
JDO Positioning.
What's Next?
2. Developing a Simple Example.
Order Processing Domain.
Discussion.
Application Source Code.
What's Next?
3. JDO architecture.
JDO Implementations and Vendors.
JDO Instances.
JDO Environments.
Persistent vs. Transient.
Transactional vs. Non-Transactional.
Support for Transactional/Persistent Instances.
JDO Identity.
What's Next?
4. Instance Lifecycle.
Determining the State of an Instance.
Required Lifecycle States.
Required Lifecycle State Transitions.
Optional Lifecycle States.
Optional Lifecycle Transitions.
InstanceCallbacks.
What's Next?
5. Persistent Object Model.
Transparency.
JDO Instances.
First and Second Class Objects.
'Third-class' Objects - Arrays.
Type Restrictions for Persistent Fields.
Inheritance.
Interlude: Order Processing GUI.
What's Next?
6. Primary Interfaces and Classes.
JDOHelper.
JDO Properties Explained.
PersistenceManagerFactory.
PersistenceManager.
Extent.
PersistenceCapable.
What's Next?
7. Transaction Management.
Transactions.
Transaction Interface.
Transaction Strategies.
Advanced Transaction Options.
Transaction Modes to Improve Efficiency.
Synchronization with JDO Transactions.
What's Next?
8. Queries with JDOQL.
Query Architecture.
Constructing Queries.
Query Interface.
Query Examples.
Query Filter Expressions.
Further Examples.
Unconstrained Query Variables.
Dynamic Query Window.
What's Next?
9. JDO Exceptions.
JDO Exception Hierarchy.
Base Exception Classes.
Application Exceptions.
What's Next?
10. Persistence Descriptor.
XML Overview.
Naming the Persistence Descriptor.
Persistence Descriptor Elements.
Example - Persistence Descriptor 'op.jdo' .
Facilities for Vendor-Specific Extensions.
Example - Deletion Semantics.
What's Next?
11. J2EE Integration.
The Managed Environment.
JLEE Overview.
Serialization of JDO Instances.
JDO vs. J2EE Transactions.
JDO Integration with EJB.
JDO Integration with Stateless Session Beans.
JDO Integration with Stateful Session Beans.
JDO Integration with Entity Beans.
JDO Integration with Message-driven Beans.
JDO Integration with the Web Tier.
Bootstrapping JDO in the Managed Environment.
What's Next?
12. JDO Implementations.
enJin by Versant.
FastObjectsß by Poet Software.
FrontierSuite for JDOß by ObjectFrontier.
IntelliBOß by Signsoft.
JDOGenieß by Hemisphere Technologies.
JRelayß by Object Industries.
Kodo JDOß by SolarMetric.
LiDOß by LIBeLIS.
OpenFusion JDOß by PrismTechnologies.
Orientß by Orient Technologies.
PE:Jß The Productivity Environment(tm) for Java by HYWY Software.
13. Epilogue.
Beyond JDO 1.0.
Sources of Further Information.
Appendix A. Properties for JDOHelper Bootstrap.
Appendix B. Strings for Supported Options.
Appendix C. JDO Persistence Descriptor DTD.
Appendix D. PersistenceManagerFactory.
Appendix E. JDOQL BNF.
Glossary.
Bibliography.
Index.

Preface

It’s official! For the last two weeks, the executive committee of JCP has been considering the JDO specification and voting on it. JDO has now been approved as a standard, and as I write these words the first announcements of JDO 1.0 are being made on JavaDataObjects at Yahoo!Groups and on JDOcentral.com.

I believe that JDO will have a profoundly positive impact on the way that we architect, design, and implement Java applications. Conservative improvements of 20% in the development time (and therefore cost) of enterprise applications are being quoted, with some analysts suggesting that the actual savings may be much higher.

Support for the standard is considerable; there is already a significant number of products on the market, most of which target full compliance with JDO 1.0 in the immediate future.

Robin M. Roos

March 2002

#l JDO is transparent to the data store itself, so applications can be ported to any data store for which an appropriate JDO implementation is available. The binary compatibility of JDO instances, guaranteed by the JDO specification, means that this can be achieved without even recompilation, let alone any alterations at source code level.

JDO will be important to Java architects, because they can use it to build flexible application architectures that integrate seamlessly with Java 2 Enterprise Edition (J2EE™). They will appreciate its portability across relational, object and other data storage paradigms, as well as JDO’s applicability to enterprise, simple client-server, and — in due course — embedded Java 2 Micro Edition (J2ME™) environments.

JDO will be important to Java designers, because they can finally use all the good object modeling techniques (including interfaces and inheritance) that previously caused significant complication to the persistence infrastructure of their applications.

JDO will be important to Java developers, because it is intuitive and works at the domain object level — without them having to implement a persistence infrastructure for their applications. They will also appreciate the new Query Language with its Java-like syntax and semantics.

Finally, JDO will be important to development and project managers, because it will streamline the development of applications. Designers and developers can concentrate on the functional aspects of the application, without spending huge amounts of time and money implementing, and subsequently debugging, non-functional persistence infrastructures.

Each of these products is described in Chapter 12, "JDO implementations." Please refer to the CD’s "readme.pdf" file for further information.

Source code for the significant examples from each chapter is available from the author’s website:

Foreword

The JDO (Java™ Data Objects) standard has a long history, only some of which is visible by looking at the development of the standard itself. Its roots are in the ODMG (Object Data Management Group), which was an early attempt to standardize transparent access to databases from object oriented programming languages. The ODMG standard predates Java, having been developed when the biggest debate in the object development community was whether Smalltalk or C++ would be the dominant object oriented programming language. The debate turned out to be academic, as Java became the de facto standard for writing object oriented applications. And the ODMG responded by adapting its C++ and Smalltalk interfaces to Java.

The process of adapting the ODMG standard to Java was problematic. It was written when two-tier architectures were dominant. Application servers were difficult to model. And the standard had no compliance test; any vendor who had an implementation that looked anything like ODMG was free to claim compliance with the standard.

Enter the Java Community Process (JCP). At first glance, it appeared to solve the most immediate problems inherent in the ODMG process; the requirement for a reference implementation and compliance test suite. After further investigation, the process was adopted and the Java Specification Request was submitted and approved for development, with support from major database players, middleware vendors, and tools suppliers.

Development of the JDO standard proceeded in parallel with two other standards: the Java Connector Architecture (JCA), and container-managed persistence (CMP). The expert group felt strongly that keeping JDO in line with these two standards would be of primary importance, yet ease of use for simple applications was still an absolute objective.

The JCP requirements for a reference implementation and compliance test suite turned out to be the determining factor in the timing of the final release of the standard. The reference implementation was staffed with one full-time engineer, and the test suite with one contractor. By normal engineering standards, the projects were woefully understaffed. But this turned out to have a bright side, as commercial implementations were developed in parallel with the development of the reference implementation and test suite. While deficiencies were found in the standard by the reference implementation, even more were found in the attempt to adapt commercial database products to the standard. In fact, several products shipped even before the tests were complete, building more support for the standard-under-development.

# I am gratified to see the adoption of JDO in the user community as well as in the vendor community. Its widespread availability in two- and multi-tier architectures and across database implementations brings new meaning to Java's promise of "write once, run anywhere."

Craig Russell

JDO Specification Lead

Sun Microsystems

Mountain View, California

April 2002

Updates

Submit Errata