Register your product to gain access to bonus material or receive a coupon.
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.
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.
Its 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
What is JDO?
Java Data Objects is an interface-based definition of object persistence for the Java language, which describes the storage, querying, and retrieval of objects from data stores.
JDO is extremely compelling due to the notion of transparent persistence that it supports. This can be summarized briefly as follows:
l
JDO transparently handles the mapping of JDO instances to the underlying data store; the so-called object-relational impedance mismatch.l
JDO is transparent to the Java objects being persisted; you do not have to add specific methods or attributes to your Java classes or alter the visibility modifiers of your class members. Fields with private visibility, and fields without get and set methods, are no problem for JDO!l
JDO can be used against a number of different data storage paradigms, including (but not limited to) relational databases, object databases, file systems, and XML documents. In due course JDO implementations will emerge for accessing persistent data held in legacy applications, for use in Enterprise Application Integration projects.#
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.l
If an application references a persistent object and alters any of its persistent state in the memory, the JDO implementation will implicitly update the data store when the active transaction is committed. This relieves the developer of repeatedly coding explicit save operations.To whom will JDO be important?
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 JDOs 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.Who should read this book?
Although it has been written primarily for Java developers, this books coverage of JDO will also be of significant interest to designers and architects.
I do expect my readers to have a good knowledge of the Java language and its syntax.
Traditionally, Java applications store data to relational databases using JDBC™ and SQL. JDO is capable of completely replacing both of these technologies. Therefore no knowledge of JDBC or SQL is required in order to learn JDO. Of course, developers with prior knowledge and experience in storing objects in databases will benefit from their background.
JDO can be used very successfully with or without a J2EE application server. It has application from standard Java clients, as well as web components (Servlets and JavaServer Pages) and enterprise components (Session, Message-Driven and Entity Beans).
Since JDO is applied largely to domain objects, I have placed significant emphasis on the design of flexible domain object models. This will be of interest to Java designers, who may then choose to skim through the syntactic examples.
Integration of JDO with the full suite of J2EE components will be of interest to Java architects as well as developers, and a chapter is dedicated to this topic. Chapter 11 begins with an explanation of each J2EE component for those not familiar with them. Thus no previous exposure to J2EE is necessary, although readers who do have such experience will naturally gain more insight than those without.
Organization
Chapter 1 Understanding object persistence
An introduction to the storage of objects in data stores, mentioning previous technology solutions.
Chapter 2 Developing a simple example
A step-by-step walk through a simple JDO example.
Chapter 3 JDO architecture
A look at essential architectural concepts, such as environments, transactionality, and identity.
Chapter 4 Instance lifecycle
Coverage of the lifecycle states of JDO instances, and the invocations which applications can make in order to initiate lifecycle transitions.
Chapter 5 Persistent object model
A detailed look at the manner in which JDO treats domain object models.
Chapter 6 Primary interfaces and classes
The essentials of JDO from a programmatic standpoint.
Chapter 7 Transaction management
How to manage transactions, with particular emphasis on optimistic transaction strategies.
Chapter 8 Queries with JDOQL
The new JDO Query Language.
Chapter 9 JDO exceptions
Exceptions defined by JDO.
Chapter 10 Persistence descriptor
A detailed look at the structure of XML persistence descriptors.
Chapter 11 J2EE integration
How to use JDO from EJB components (Session Beans, Entity Beans and Message-Driven Beans) and web components (Servlets and JavaServer Pages).
Chapter 12 JDO implementations
A summary of the available implementations. JDO is remarkably well implemented given its relative newness in the market.
Chapter 13 Epilogue
A look beyond JDO 1.0, considering features that might be expected in future versions of JDO.
Appendix A Properties for JDOHelper bootstrap
Useful property names for initializing JDO.
Appendix B Strings for supported options
Useful string constants.
Appendix C JDO persistence descriptor DTD
The DTD which constrains persistence descriptors.
Appendix D PersistenceManagerFactory
A list of the methods of the PersistenceManagerFactory, which has not been given in the text.
Appendix E JDOQL BNF
The formal grammar notation of JDOQL
A bibliography is also provided.
CD contents
The CD accompanying this book contains trial versions of the following JDO implementations:
l
FastObjects™ by Poetl
Kodo JDO™ by Solarmetricl
LiDO™ by LIBeLISl
OpenFusion JDO™ by Prism Technologies.Each of these products is described in Chapter 12, "JDO implementations." Please refer to the CDs "readme.pdf" file for further information.
Source code for the significant examples from each chapter is available from the authors website:
http://www.OgilviePartners.com
JDO version information
This book covers JDO 1.0.
The Java examples are compliant with JDK 1.3.1_01 and J2EE 1.3.
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