Java data Object Technology JDO Introduction

As a new language that has sprung up, Java defines a standard runtime environment in which user-defined classes are executed. Instances of these user-defined classes represent data in real-world environments, including data stored in databases, files, or some large transaction-processing systems, and small systems often require a mechanism for local control over data storage.

Because data access technologies are different in various data source types, access to data is a challenge for programmers, who need to use a specific programming interface (API) for each type of data source, That is, at least two languages must be known to develop business applications based on these data sources: the Java language and the data access language determined by the data source. This type of data access language is generally different depending on the source of the data, which makes the development cost of learning to use some kind of data source be promoted accordingly.

Before Java Data Object Technology (JDO) is published, there are typically three ways to store Java data: Serialization (that is, serialization, also known as serialization), JDBC, and the mode of CMP (managed storage) in EJBs. Serialization is used to place the state of an object, and the other object maps it points to are all written into an output stream (such as files, networks, and so on), which guarantees the relationship between the objects being written, so that, at another time, the object map can be completely reconstructed. However, serialization does not support transaction processing, querying, or sharing data with different users. It allows access only on the basis of granularity at the time of the initial serialization (meaning the interface of the Access object), and is difficult to maintain when the application needs to handle multiple or multiple serialization. Serialization applies only to the simplest of applications, or to embedded systems that cannot effectively support the database.

JDBC requires you to explicitly work with data fields and map them to tables in relational databases. Developers are forced to deal with two very different data models, languages, and data access: Java, and relational data models in SQL. Mapping from relational data models to Java object models in development is so complex that most developers never define object models for data; they simply write procedural Java code to manipulate the data tables in the underlying relational database. The end result: they simply cannot benefit from object-oriented development.

The EJB component system is designed to support distributed object computing. It also includes support for container-managed persistence container Managed persistence (see Glossary) to achieve sustainability. Primarily because of their distributed nature, EJB applications are much more complex than jdo and consume a lot of resources. However, JDO is designed to be flexible, so that JDO products can be used to implement EJB storage processing at the bottom, thus combining with the EJB container. If your application requires object storage, but does not require distributed features, you can use JDO instead of EJB components. The most typical JDO usage scenario in an EJB environment is to have the conversation component (session Bean) in the EJB directly access the JDO object, avoiding the use of entity components (Entity beans). The EJB component must be running in an application service environment that is controlled (Managed, see Glossary). However, the JDO application can run in a controlled environment, or it can run in an uncontrolled, independent environment, which gives you the flexibility to choose the most appropriate application running environment.

If you focus on designing a Java object model and then using JDO to store instances of your data class, you will greatly improve productivity and development efficiency. You just have to deal with an information model. JDBC requires you to understand the relational model and the SQL language (translator: JDO is not meant to replace JDBC, but rather an abstract middle tier based on JDBC, providing a simpler data storage interface). Even when using EJB CMP (that is, memory storage, see glossary), you have to learn many other aspects related to the EJB system, and there are some limitations in JDO that are not present in modeling.

JDO regulates the conventions between the JDO runtime environment and your storage object classes. JDO is designed to support a variety of data sources, including databases that are not normally considered. From now on, we use the concept of a database (see glossary) to represent any underlying data source that you access through JDO.

This chapter will expand on the basic capabilities of JDO, based on a detailed analysis of a small application developed by a virtual media mania company. The company rents and sells various forms of entertainment and audio-visual products in many stores throughout the United States. There are kiosks in their stores that provide information about movies and the actors in the movie. This information is open to customers and store staff to help select the product that suits the customer's taste.

Defining the data Object model

We will create a UML class diagram that shows the related classes of a company's object model and the relationships between them. A movie (movie) object represents a particular movie. Each actor who plays a role in at least one movie is represented by a actor (actor) object. The role class, which represents a particular role played by an actor in a movie, also represents a relationship between the movie and the actor, which contains a property (the role name in the movie). Each movie consists of one or more characters. Each actor can play different roles in different movies and even play multiple roles in the same movie.

We'll put these data classes and the programs that manipulate these data class instances into the Com.mecdiamania.prototype package.