advertisement
javaboutique
Search Tips
Articles  |   Tutorials  |   Reviews  |   Tools  |   by Category  |   by Date  |   by Name  |   Submit  |   Source  |   Forums  |  
javaboutique
Browse DevX


Partners & Affiliates











advertisement



Title: Professional EJB
ISBN: 1861005083
US Price: $ 59.99
Canadian Price:
C$ 89.95
UK Price: £ 47.99
© Wrox Press Limited, US and UK.

Reviews : Java Books :
Professional EJB : The EJB 2.0 Entity Model

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.

How to Add Java Applets to Your Site

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.

 Avaya Developer Showcase
 MSDN Spotlight
 PHP for Windows Showcase
XML error: undefined entity at line 34
advertisement
Receive Articles via our XML/RSS feed
Receive Articles via our XML/RSS feed

JavaBytes
Internet Cyclone
This powerful, easy-to-use, internet optimizer is for Windows 95, 98, ME, NT, 2000 and XP. It's designed to automatically optimize your Windows settings, boosting your Internet connection up to 200%.

IBM Brings Developers Into the Cloud
Apache at 10: You Can't Buy Us
Microsoft's CodePlex Foundation Moving Forward
Apple Claims 100,000 Apps, Google Analyzes Them
Nokia Latest to Play Opera Mobile 10 Browser
PayPal Opens Up Payment Platform to Devs
Ubuntu Linux 9.10 'Karmic Koala' Starts Its Climb
IBM Links Rational Developer Tools, Tivoli Apps
Libraries Give Vista Apps a Windows 7 Look
Ubuntu: The 'Default Alternative' to Windows?

Delivering Web-based Embedded Fonts in CSS 3
Adobe Helps PHP Developers Create Rich Internet Applications
Java Developers Finding a Home at Adobe Flex
Virtualization Delivers a Dynamic Infrastructure
Consuming XML Web Services in iPhone Applications
Build a More Agile Business with IBM
POJO-Based Solutions for LDAP Access: One Good, One Better
IBM Offers Enhanced Measurement and Management for Energy Usage
IBM Helps Transformation to an Information-Based Enterprise
Top Five Touch UI-Related Design Guidelines

Advertising Info  |   Member Services  |   Contact Us  |   Help  |   Feedback  |   Site Map  |   Network Map  |   About

internet.commediabistro.comJusttechjobs.comGraphics.com

Search:

WebMediaBrands Corporate Info

Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs