"The Java Data Objects (JDO) interface was later introduced as a new interface for storing objects to a data store, which in many cases could be a replacement for Entity Beans. At first glance, JDO seems to be a solution for Entity Beans' performance problems. In most applications, data operations are retrieving and setting field values. Most JSP pages simply display or change data from databases. In this case, the remote interface is huge overhead; remote getters and setters are unnecessery, especially if you would like to call the same getter many times. (With remote methods, you can’t afford to call a remote getter many times.) In this case, it is much more reasonable to retrieve data so that the client can manipulate it locally, and then send it back to the server."
"Editor's note: In part one in this three-part series on JDO persistence, excerpted from Java Database Best Practices, George Reese described all of the available persistence options for Java architects and developers. In part two this week, George covers JDO persistence best practices for transaction management and query control."
"Editor's note: In last week's excerpt from Chapter 7 of Java Database Best Practices, author George Reese covered basic JDO persistence best practices for transaction management and query control. In this week's concluding excerpt on JDO persistence, George covers using JDO as a bean-managed persistence tool."
"Castor is able to employ a mapping file as a simple way to bind Java objects to SQL database tables. Instead of writing complex procedural code in Java to manage the database queries and updates via JDBC, Castor hides this complexity by using the mapping file entries and transparently performing the proper queries and updates in the background. This declarative mechanism of descibing how the objects and the database are linked makes maintenance easier, because mapping files are relatively easy to understand and can be changed without recompiling code. It's also much simpler in that it operates at a higher level of abstraction than functionally equivalent JDBC mechanisms allow."
"You do not need to write the persistence layer for this pattern to be valid. EJB CMP "delegates" its persistence operations to the container. EJB CMP, however, is not the only automated persistence option for Java architects and developers. This chapter covers the major standard option to EJB CMP, the Java Data Objects (JDO) specification. If you are not familiar with this specification, Chapter 12, "JDO," provides a tutorial to introduce you to JDO programming."
"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."
"When a new technology comes along that introduces a paradigm shift, it often challenges the existing, established technology in use. It is a natural tendency for those with a vested interest in maintaining the status quo to spread fear, uncertainty, and doubt (FUD) about the new technology. Java Data Objects (JDO) is a new technology released from the Java Community Process that allows developers to directly persist their object models in transactional datastores. It supports the development of applications where the Java object model serves as the sole data model used in the application. It provides a query facility that allows applications to filter the objects in their object model using query operators and syntax taken directly from Java. JDBC and SQL are noticeably absent from JDO's interface, yet it has been designed so that it can be layered on top of these relational database technologies."
"Editor's Note: the following is an expert perspective on the Java Data Objects (JDO) name and use issues currently pending in the court of opinion as well as, perhaps, more. This does not necessarily reflect the opinion of O'Reilly & Associates."
"Other useful resources include SolarMetric's 2-page JDOQL 2.0 Quick Reference and the unprintable PDF Edition of my own book, Java Data Objects (Addison-Wesley)."
"Other useful resources include SolarMetric's 2-page JDOQL 2.0 Quick Reference and the unprintable PDF Edition of my own book, Java Data Objects (Addison-Wesley)."
"Well, I want to tell you about the JDO 2.0 kickoff meeting that I was fortunate to be part of last week. Since it wasn't an official JSR meeting (first we need a JSR to be accepted), everything said was public. This is very significant. Noone could hide behind the process, and everything was out there. With all of that, working groups with competing vendors got together over the 3 day meeting to work on things. Vendors were discussing what they did right now, and what they were planning to do in the future. I probably learnt much about the different JDO vendor products just via this information alone."
"Developing a persistent domain model for an enterprise application is challenging. The reason we implement the business logic with a domain model is because the problem domain is complex. Therefore, it is important to be able to easily and quickly make changes and run unit tests. However, quite often the technology that provides persistence can slow down development because it couples the code to the application server and the database. This can significantly lengthen the edit-compile-execute-debug cycle and test-driven development becomes harder to do. This article describes how using Java Data Objects (JDO) [JDO] can avoid these problems and accelerate development."
"The latest issue of the Object Watch newsletter contained an article in entitled Living on the right side of the counter (Java Data Objects). in which Roger Sessions asserts that Sun probably might want to deprecate EJB due to "The technical problems with EJB are well known, and include poor performance, machine affinity, and potential database corruption. But Java Data Objects (JDO) seems to solve none of these problems, and adds to them what I think is the worst implementation of a Distrust Divide in the industry.""
"It was announced that since the JSR for JDO 2.0 had not been submitted nor approved by the JCP EC, this meeting would be held in the open. Nothing discussed in the meeting would be proprietary or covered by non-disclosure. So anyone is free to openly discuss the results of the meeting in public. We all agreed to the policy of the meeting."
"So what makes JDO different? From a technical standpoint, JDO provides an abstraction layer between the application and the data store. Craig Russell from Sun Microsystems and a group of database and persistence experts formed JDO to define a "specification that provides for interface-based definitions of data stores and transactions, and selection and transformation of persistent storage data into native Java programming language objects." In plain English, JDO is a well thought out application programming interface that provides a common layer to access and manipulate data stores of various kinds (e.g., relational databases, legacy databases, object databases, embedded databases, and even flat files)."
"Introducing Object Persistence Persisting Java objects to a relational database is a unique challenge that involves serializing hierarchically-structured Java objects to a tabular-structured database and vice versa. This challenge is currently being addressed by a number of different tools. Most of these tools allow developers to instruct persistence engines as to how to convert Java objects to database columns/records and back. Essential to this effort is the need to map Java objects to database columns and records in a manner optimized for speed and efficiency."
"At the JDO 2.0 Specification kickoff meeting held in Washington DC in August, the JDO Expert group, which consists of commercial and open-source JDO vendors, JDO consultants and trainers, end customers, and vendors with alternative technologies, identified a number of topics as critical to continuing the success of Java Data Objects. This article explores some of these topics and discusses the value of each to Java developers and JDO customers."
"TopLink Thrives To this point, no persistence framework had yet experienced mass-market success. WebGain had been around for some time but only as a bit player. The vendor significantly grew its reputation and market share by providing TopLink, which could be used as a snap-in replacement for EJB CMP, enabling seamless persistence for that defective model. Along with providing rich OR mapping, TopLink supported the richness and complexity of relational databases. It also had a powerful caching model."
"Castor JDO (Java Data Objects) is an open source, 100 percent Java data binding framework. Initially released in December 1999, Castor JDO was one of the first open source data binding frameworks available. Since that time, the technology has come a long way. Today, Castor JDO is used in combination with many other technologies, both open source and commercial, to bind Java object models to relational databases, XML documents, and LDAP directories."
"As an example of an application that uses the Employee class, the following code creates an instance of the Employee class, populates it, and persists it to an IBM DB2 database. A key part in developing an application that uses JDO is the javax.jdo.PersistenceManager. This object creates transactions and persists JDO objects. For more information on the PersistenceManager, see the JDO 2.0 spec available from:"
"Just as the JDBC API brought a standard way to access relational databases, the Java Data Objects API, JDO, brings a standard means for accessing all data stores, relational or otherwise. It has the great advantage of being a very simple API, with none of the complexity or required overhead of Entity EJBs—it can, however, co-exist with Entity beans or with many other persistence techniques, as we will see."
"For Java developers, there is a new way to implement data persistence. Java Data Objects (JDO) is a Java-based solution to help solve data persistence in java systems. JDO can be defined as:"
"Java Data Objects (JDO) is a specification developed to enable transparent persistence of Java objects. It is a high-level API that allows applications to store Java objects in a transactional data store by following defined standards. Examples of traditional data stores are databases and files. This API can be used to access data on platforms such as desktops, servers, and embedded systems. JDO implementations can also be made to support cell phone, PDA, and other wireless technologies. In addition, JDO provides a means for treating data stored in a relational database as Java objects. JDO provides a standard means to define transactional semantics associated with these objects."
