Java Reference
In-Depth Information
With bean-managed persistence, the bean developer writes database-access calls using a persistent
storage-specific API. In most cases, the persistent stores are relational databases, and the JDBC
provides a unified API for data access. Effectively, the bean developer is responsible for coding all of
the database queries. The data-access calls can be coded directly into the EJB implementation class,
as you see in the examples given later in this chapter, or can be encapsulated in a data-access object
(DAO).
If database queries are coded directly in the EJB class, it may be difficult to adapt the entity bean to
work with a different type of database or a database that has a different schema. Encapsulating data-
access calls in a DAO makes it easier to adapt the EJB's data access to different schemas or different
databases, since only the DAO, instead of the whole EJB, needs to be modified or rewritten. Detailed
discussion on DAO is beyond the scope of this topic. Interested readers can find the use of DAOs in
many J2EE design-pattern topics.
The main advantage of BMP is its simple deployment process. When an entity bean uses BMP, no
deployment tasks are necessary to adapt the bean to the database type or database schema.
Everything is
hard coded
in the implementation. As you can see, this is also the main disadvantage of
BMP, because an entity bean using BMP is generally tied up with the database type and schema. The
tight coupling between the EJB and database makes BMP entity bean less flexible and less reusable
across different operational environments.
However, an entity bean using BMP can achieve some degree of independence of the EJB code from
the database type and schema by using the DAOs discussed earlier in this section. Since the entity
bean uses the DAO to access the entity object's state stored in the database, the EJB implementation
class is not tightly coupled with the database. The DAO provides the appropriate interface for
customizing the data-access logic to a different database type or schema. For example, a
CustomerEJB
may use a DAO to access the Customer Relationship database on Oracle and use
another DAO to access the Sales database on Sybase. If access to a new database schema (or
database type) is needed, you need only to code a new DAO and do not need to change the EJB code
at all.
BMP reduces the complexity of the deployment process, but the price you pay is the loss of flexibility.
You should choose BMP or CMP based on your own requirements.
Primary Key
Understanding primary keys is an essential part of understanding entity EJBs (both BMP and CMP
beans). One of the fundamental concepts of entity EJBs is that they must be accessible concurrently by
multiple clients. This does not mean that multiple clients need to access the same bean instance; rather,
they need to have access to the state of the same business-entity object stored in the database. To
achieve this, the EJB architects incorporate an entity bean primary key concept similar to the primary
key of a relational database. The primary key is a
unique identifier
for the entity object. The primary key
enables the client to locate a particular business entity it needs to access.
Since every entity bean must have a unique primary key, you can compare two entity EJB instances
without actually using the instances themselves. Rather, you can just compare the contents of their
primary keys. If two EJB instances with the same home interface have the same primary key, they are
considered identical, since they represent the same underlying entity object. For example, a customer
entity bean may be identified by a customer number. Two
CustomerEJB
instances with the same
customer number are considered identical because they represent the same customer. The
synchronization between these two instances and the state of the
Customer
object stored in the
database is the EJB container's responsibility.
Note that the primary key of an entity bean is a Java class object. In most cases, your primary key class
is a
String
, an
Integer
, or some other class that belongs to the J2SE or J2EE standard libraries. For
some entity beans, you need to define your own primary key class. For instance, if the bean has a
composite primary key (that is, one composed of multiple fields), you must create a primary key class.
For BMP entity beans, a primary key class must meet these requirements:
The class is serializable.
