JDO Programming Models 

Overview

Java Data Objects can be used in a variety of application scenarios.

Typically, you might choose to use JDO in a J2EE application designed in accordance with the model-view-controller (MVC). In this scenario, the JDO represents the persistence layer, and the client will work with a web-based front end. A façade session bean implements the communication between the Web component and the JDO. JDO can be used with both stateless and stateful session beans, as well as with message-driven beans. In addition, it is convenient to use the JDO API to implement entity beans with bean-managed persistence (BMP).

A less common scenario is when you access a JDO directly from within a Web component. Although it is possible, this model cannot be used for the implementation of a complex application. In addition, the J2EE standard recommends the use of three-tier applications to clearly separate the persistence logic from the business and the presentation layers.

For more information, see:

·        Using JDO with Session Beans

·        Using JDO with Message-Driven Beans

·        Using JDO with BMP Entity Beans

·        Using JDO with Web Components

JDO or EJB

The discussion about whether it is better to use JDO or container-managed entity beans to implement the application persistence logic has not led to a clear conclusion. Many advantages may be pointed out for both standards. As a result, you should choose which of them to use according to the complexity and the specific features of your application, the development effort required, and any other relevant factors.

The table below shows a brief comparison of the features that JDO and entity CMP beans provide. It is not meant to cover all possible aspects; instead it outlines the most important issues that you might consider when designing your application.

Feature List – JDO and EJB

JDO 1.0	Entity Beans (CMP) 2.0
Not part of the J2EE standard; optional support in J2EE application servers	Part of the J2EE standard – mandatory support in J2EE application servers; provides a complete programming model
Does not support direct remote calls; however, remote communication can be implemented using facade session beans	Direct remote invocations are possible. In spite of this, it is recommended that you use the entity beans locally and delegate the remote communication to a facade session bean.
Security features are not available	Security features
Runs in both managed and non-managed environments	Runs in managed environment only (EJB container)
Supports inheritance and interfaces, multitable mapping, and mapping to legacy tables	Does not support inheritance and interfaces. A bean can only be mapped to a single table.
Primary key class required	Primary key class not required
Unmanaged relationships	Managed relationships
JDOQL enables dynamic queries that always return objects. However, JDOQL has Java-like syntax and is less powerful.	With EJBQL, only static queries are possible. They can return immutable result sets. The EJBQL has an OQL-like syntax and is more powerful than JDOQL.
Faster deployment	Deployment is a more complicated process and is therefore slower
Java knowledge should be sufficient	Implementation requires EJB specific knowledge