Product Description
Java Data Objects revolutionizes the way Java developers interact with databases and other datastores. JDO allows you to store and retrieve objects in a way that's natural to Java programmers. Instead of working with JDBC or EJB's container-managed persistence, you work directly with your Java objects. You don't have to copy data to and from database tables or issue SELECTs to perform queries: your JDO implementation takes care of persistence behind-the-scenes, and you make queries based on the fields of your Java objects, using normal Java syntax.
The result is software that is truly object-oriented: not code that is partially object-oriented, with a large database-shaped lump on the back end. JDO lets you save plain, ordinary Java objects, and does not force you to use different data models and types for dealing with storage. As a result, your code becomes easier to maintain, easier to re-use, and easier to test. And you're not tied to a specific database vendor: your JDO code is entirely database-independent. You don't even need to know whether the datastore is a relational database, an object database, or just a set of files.
This book, written by the JDO Specification Lead and one of the key contributors to the JDO Specification, is the definitive work on the JDO API. It gives you a thorough introduction to JDO, starting with a simple application that demonstrates many of JDO's capabilities. It shows you how to make classes persistent, how JDO maps persistent classes to the database, how to configure JDO at runtime, how to perform transactions, and how to make queries. More advanced chapters cover optional features such as nontransactional access and optimistic transactions. The book concludes by discussing the use of JDO in web applications and J2EE environments.
Whether you only want to read up on an interesting new technology, or are seriously considering an alternative to JDBC or EJB CMP, you'll find that this book is essential. It provides by far the most authoritative and complete coverage available.
From the Publisher
Whether you only want to read up on an interesting new technology, or are seriously considering an alternative to JDBC or EJB CMP, you'll find that this book is essential. It provides by far the most authoritative and complete coverage available.
About the Author
David Jordan founded Object Identity, Inc. in 2001 to provide JDO consulting services. He became interested in the integration of object type systems and databases while earning his M.S. in Computer Science in the early 1980s. At Bell Labs in 1985, he initiated the development of the first C++ object database. He has developed a variety of applications using C++ object models on top of network, relational, and object database systems. Bell Labs appointed him a Distinguished Member of Technical Staff in 1990 for his contributions in object and database technologies. The Object Data Management Group (ODMG) asked him to serve as their C++ editor in 1993. He served in that role until 2000 and was appointed their Java editor in 1998. He coedited four books published by the ODMG. David served as a C++ Report columnist describing the ODMG standard from 1994 to 1996, at which point he stopped to write his first book, C++ Object Databases. David started using Java in late 1995. Upon his selection as ODMG's Java editor, he became a columnist for Java Report, initially covering ODMG and then JDO. David was part of the small group that initiated JSR-12, and he became one of the initial members of the JDO expert group. The JDO specification has a special acknowledgment of David's contributions to the JDO standard. When the JDOcentral.com community web site was formed, David was selected to serve as its moderator. David can be reached at david.jordan@objectidentity.com
Craig Russell studied applied mathematics at Harvard University (B.A. '70 - '71) and acquired practical experience working as a technician repairing mainframes with the computing power of a 1997 model laptop. His early experiences in distributed computing included building applications with CICS and DL/I and designing heterogeneous network server implementations for file, print, and communications sharing among personal computers. Craig later dealt with issues of persistent object interoperability among Smalltalk, C++, and Java and integrating object and relational databases using X/OPEN XA protocols and commercial transaction processing systems. Craig served as the Java Chair of the Object Data Management Group and played a key role in the development of the ODMG 3.0 Java binding. For the next standard for database access from Java, the ODMG decided to support the Java Community Process as the delivery vehicle. With support from all major relational database and middleware vendors, Java Specification Request 12, Java Data Objects, was proposed in May 1999 and released in April 2002. Concurrent with the development of the JDO standard, Craig's primary responsibility was to lead the implementation of the object-relational database engine for several Sun products, including Java Blend and Forte for Java Transparent Persistence. Craig currently is the architect for the Container Managed Persistence implementation of Sun ONE Application Server, where he deals with the reality of implementing the high-performance, specification-compliant version of the object-relational database component of the J2EE application server.
Excerpted from Java Data Objects by David Jordan, Craig Russell. Copyright © 2003. Reprinted by permission. All rights reserved.
Java is a language that defines a runtime environment in which user-defined classes execute. Instances of these user-defined classes may represent real-world data that is stored in a database, filesystem, or mainframe transaction processing system.
Additionally, small-footprint environments often require a means of managing persistent data in local storage.
Because data-access techniques are different for each type of data source, accessing the data presents a challenge to application developers, who need to use a different application programming interface (API) for each type of data source. This means that you need to know at least two languages to develop business logic for these data sources: the Java programming language and the specialized data-access language required by the data source. The data-access language is likely to be different for each data source, driving up the costs to learn and use each data source.
Prior to the release of Java Data Objects (JDO), three standards existed for storing Java data: serialization, Java DataBase Connectivity (JDBC), and Enterprise JavaBeans (EJB) Container Managed Persistence (CMP). Serialization is used to write the state of an object, and the graph of objects it references, to an output stream. It preserves the relationships of Java objects such that the complete graph can be reconstructed at a later point in time. But serialization does not support transactions, queries, or the sharing of data among multiple users. It allows access only at the granularity of the original serialization and becomes cumbersome when the application needs to manage multiple serializations. Serialization is only used for persistence in the simplest of applications or in embedded environments that cannot support a database effectively.
JDBC requires you to manage the values of fields explicitly and map them into relational database tables. The developer is forced to deal with two very different datamodel, language, and data-access paradigms: Java and SQL’s relational data model.
The development effort to implement your own mapping between the relational data model and your Java object model is so great that most developers never define an object model for their data; they simply write procedural Java code to manipulate the tables of the underlying relational database. The end result is that they are not benefiting from the advantages of object-oriented development.
The EJB component architecture is designed to support distributed object computing. It also includes support for persistence through Container Managed Persistence (CMP). Largely due to their distributed capabilities, EJB applications are more complex and have more overhead than JDO. However, JDO has been designed so that implementations can provide persistence support in an EJB environment by integrating with EJB containers. If your application needs object persistence, but does not need distributed object capabilities, you can use JDO instead of EJB components.
The most popular use of JDO in an EJB environment is to have EJB session beans directly manage JDO objects, avoiding the use of Entity Beans. EJB components must be run in a managed, application-server environment. But JDO applications can be run in either managed or nonmanaged environments, providing you with the flexibility to choose the most appropriate environment to run your application.
You can develop applications more productively if you can focus on designing Java object models and using JDO to store instances of your classes directly. You need to deal with only a single information model. JDBC requires you to understand the relational model and the SQL language. When using EJB CMP, you are also forced to learn and deal with many other aspects of its architecture. It also has modeling limitations not present in JDO.
JDO specifies the contracts between your persistent classes and the JDO runtime environment. JDO is engineered to support a wide variety of data sources, including sources that are not commonly considered databases. We therefore use the term datastore to refer to any underlying data source that you access with JDO.
This chapter explores some of JDO’s basic capabilities, by examining a small application developed by a fictitious company called Media Mania, Inc. They rent and sell various forms of entertainment media in stores located throughout the United States.
Their stores have kiosks that provide information about movies and the actors in those movies. This information is made available to the customers and store staff to help select merchandise that will be of interest to the customers.
