Problems with the EJB 1.1 CMP Model
There were two obvious problems with the EJB 1.1 model of container-managed persistence:
-
The difficulty of modeling coarse-grained entity objects
-
The lack of a portable way to specify finder queries
The first of these, especially, was enough to require the use of bean-managed persistence in many
common circumstances.
The EJB 1.1 specification suggested that entity beans be modeled as coarse-grained objects. In other
words, an entity bean should represent a business object that has an independent identity and lifecycle,
and is referenced by multiple clients. In practice, this would mean that an entity bean would often map
to multiple tables and records in a relational database. In the entity's implementation, the complex data
would be modeled as dependent value objects.
A dependent object is a helper class that is used to model an entity's state. Its most obvious use is to
model aspects of the entity's state that have a multiplicity greater than one. Java programmers use
dependent objects all the time without thinking twice about it. Anytime we have a Collection class
state variable (a java.util.List or a java.util.Map) its contents are dependent objects. For
example, an Order business object might contain LineItem dependent objects. An Employee business
object might have Children dependent objects. A Customer business object might have
ContactNumber dependent objects.
In the EJB 1.1 model, a dependent object class can be represented in your entity in one of two ways:
-
Another entity bean
-
A simple Java class, known as a dependent value object
Representing a Dependent Object with Another Entity Bean
It is possible to model your complex objects using other entity beans. Consider the example of an
OrderEJB entity bean with line items. Those line items could be modeled by LineItemEJB entity
beans. The LineItemEJB instances could be retrieved programmatically by defining an appropriate
finder method in the LineItemEJB home interface (findByOrder(long orderNumber)).
Unfortunately, there are several disadvantages to this approach:
-
Poor performance. (This is probably the most important disadvantage.) Invocations of EJB
components are heavyweight, because the EJB container has the responsibility to manage
their security and transactional integrity, copy their non-remote parameters, and perform
logging and exception handling.
-
The details of the object model are unnecessarily exposed to the client. In other words, the
client has access to implementation details that should be hidden behind a façade. As a result,
the application is less easily changed. For example, if the client has access to those LineItem
beans, and a future version of the application changes the LineItem bean to an
OrderAspect bean with line item dependent objects, the client will need to change.
-
The relationship between the EJB components needs to be managed in the component's code
(the finder method that retrieves the line items needs to be written, and reissued whenever the
contents may have changed within that transaction).
Representing a Dependent Object with a Dependent Value Class
It was also possible to define an entity that used simple Java classes (dependent value classes) to model
its complex state. Consider again that example of an OrderEJB entity bean with line items. Those line
items could be represented by a simple Java class stored in a java.util.LinkedList in the
OrderEJB implementation. They are stored to, and retrieved from, the database along with the rest of
the state data.
However, there were also several problems with this approach:
-
The EJB container did not have visibility into the structure of the OrderEJB implementation.
In other words, the contents of the linked list (line item classes) wasn't declared anywhere in
the deployment descriptor. This made it more difficult for the EJB container to save the state
of the bean to a normalized relational database schema.
-
There was no foolproof way for the container to implement the load-on-demand optimization.
Load-on-demand means that data is loaded from the persistent store when it is needed, and
not before. For example, the line items for an order wouldn't be retrieved from the database
until they were used in the code. If the line items weren't used in the transaction, that database
access would be avoided. As data access operations are typically slow and expensive, this is an
important optimization.
-
There was no foolproof and efficient way for the container to implement dirty checking. Dirty
checking means that data is only saved to the persistent store when it has been modified. For
example, if some line items had been changed, some deleted, and some added, only the
necessary SQL UPDATES, DELETES, and INSERTS should be issued. As data access operations
are typically slow and expensive, this is also an important optimization.
-
There was no portable way to ensure that the state of the Collection classes would be
appropriate for the EJB container's persistence strategy. For instance, there was nothing in the
EJB 1.1 specification that prevented a bean developer from saving objects of different classes
in a collection or map. Vendor-imposed restrictions affected the portability of EJB
components.
-
There were potential data-aliasing problems with dependent objects used by two or more
objects in the same transaction. Data aliasing basically means that there are two
representations of the same data. The problem occurs when you update one, and expect the
other to be updated, but it isn't. For example, consider two Person entities representing a
husband and wife. Each has a reference to the same dependent object that stores their address.
You expect that if you update the husband's address, the wife's address should also be
updated. Since there was no way for the container to update the entity's data cache (such as its
address object) within a transaction, logic errors could result.
Various work arounds to these problems were developed by some container vendors. One common
strategy for basic dirty checking at the entity level was to add support for an isModified() method.
Of course, this strategy, despite being common, was not (strictly-speaking) portable. However, it was not
uncommon for these problems to go completely unresolved, and more than one widely-used EJB
container saved entire collections of objects in serialized form, in a single database table column.
An earlier draft of the EJB 2.0 specification introduced a new type of container
managed object, called a dependent object. Dependent objects were intended to be used
for implementing coarse-grained entities. That concept has been removed from the
specification (although many of the same problems are addressed by the addition of
local interfaces). Whenever you see the words 'dependent object' in this chapter, I am
referring to the general concept of a dependent object, and not this discarded EJB 2.0-
specific concept.
Finder Queries
A finder query is a declarative expression of the appropriate behavior for a finder method in an entity
bean with container-managed persistence. The EJB container is responsible for implementing these
finder methods, but it needs to be told what these finder methods should do.
The EJB 1.1 specification did not provide a format for these finder queries, which meant that each
application server or EJB container had its own format. This damaged an EJB component's portability.
Consider an entity bean that was intended for commercial resale and reuse by multiple application
programmers across multiple platforms. Each deployer of that bean would need to re-implement the
business logic that was inherent in the finder query, or the bean developer would need to provide a
complete set of finder queries for each potential deployment platform.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
