6.7. Design Guidelines and Patterns

With the introduction of entity beans, our enterprise application can safely and efficiently model business data that updates a database. Let's review some of the design decisions we've made in implementing our Customer entity bean and associated session facade, CustomerSession EJB.

Using BMP

General wisdom dictates using Container-Managed Persistence (CMP) whenever possible. However, not all entity beans can be implemented with CMP. Bean-managed persistence requires that the bean developer write the database access code for an entity bean. This means writing ejbLoad() and ejbStore() routines to synchronize the database, as well as implementing the ejbFindXXX(), ejbCreate(), and ejbRemove() methods. To minimize actual database updates with ejbStore(), we maintain a dirty flag. We set the dirty flag in any business method that modifies persistent variables and only update the database when persistent variables have changed.

DAO Pattern

An entity bean with BMP is a good candidate to use the DAO pattern. This promotes database independence and allows the bean developer to use alternate DAO implementation classes by changing only the deployment descriptor. We define a CustomerDAO interface that contains the database access routines required by the Customer EJB bean implementation code. In addition, we define the CustomerModel class to hold the persistent data. Like the DAO pattern we presented with the Music Database, we also define a factory class, CustomerDAOFactory, a DAO implementation class for the Cloudscape database, CustomerDAOCloudscape, and a system exception class, CustomerDAOSysException.

Local Interfaces

Performance will improve if you implement entity beans with local interfaces. Because entity beans typically contain find-grained setter and getter methods, remote access in a high-usage system can quickly cause network bottlenecks. Use a session bean to access entity beans through local interfaces. The session bean may be stateless or stateful; however, a stateless bean is more efficient.

Transactions

Since entity beans are persistent and shareable, they are managed by an EJB container that supports transactions. Entity beans must use container-managed transactions. This means that during the deployment process, the bean developer specifies which methods require transactions and the attribute of those transactions. In general, the entity bean finder, create(), remove(), and business methods all execute within transactions. The Required attribute is typical and covers most scenarios. Thus, if the client thread is already in a transaction, the EJB container continues to use this transaction context. If the client thread is not currently executing within a transaction, the EJB container initiates a new transaction.

Session Facade Pattern

The session facade pattern delegates a session bean as an interface to one or more entity beans. The session bean accesses the entity beans using local interfaces and provides a simplified interface for clients to the entity beans. It implements one or more business processes in its business methods. The session facade pattern not only improves performance of entity bean access by using local interfaces, it offers many other advantages.

• A session bean models a business process and it can therefore encapsulate the business rules that affect entity beans.

• A session bean is callable from any client.

• A session bean isolates the entity bean from general clients.

• A session bean's multiple-step business method can execute within a single transaction, providing support for the ACID transaction properties.

• A session bean simplifies the interface between clients and entity beans.

Entity Bean Testing

Since BMP is more complicated than CMP, you may want to implement remote interfaces to the entity bean for testing purposes. You can then write a stand-alone Java client to test your entity bean. Once testing is complete, you may create the local and local home interfaces for access through a session bean.