web server - Borland Technical Publications

Container-managed persistence and Relationships
Container-managed persistence and Relationships
Borland's EJB container provides tools that generate the persistence calls at the time
that the entity bean is deployed; that is, when the entity bean is installed into a
Partition. The tools use the deployment descriptors to determine the instance fields
which must be persisted. Instead of coding the database access directly in the bean,
the bean provider of a container-managed entity bean must specify in the deployment
descriptor those instance fields for which the container tools must generate access
calls. The container has sophisticated deployment tools capable of mapping the fields
of an entity bean to its data source.
Container-managed persistence has many advantages over bean-managed
persistence. It is simpler to code because the bean provider does not have to code the
database access calls. Handling of persistence can also be changed without having to
modify and recompile the entity bean code. The Deployer or Application Assembler can
do this by modifying the deployment descriptor when deploying the entity bean. Shifting
the database access and persistence handling to the container not only reduces the
complexity of code in the bean, it also reduces the scope of possible errors. The bean
provider can focus on debugging the business logic of the bean rather than the
underlying system issues.
Borland's Persistence Manager (PM) not only persists CMP fields but also CMP
relationships. The container manages bean relationships and maintains the referential
integrity of these relationships. Just as you defined container-managed persistence
fields in a bean's deployment descriptor, you can now define container-managed
relationship fields in the deployment descriptor. The container supports relationships of
various cardinalities, including one-to-one, one-to-many, and many-to-many.
Packaging Requirements
Like session beans, entity beans can expose their methods with a remote interface or
with a local interface. The remote interface exposes the bean's methods across the
network to other, remote components. The local interface exposes the bean's methods
only to local clients; that is, clients located on the same EJB container.
Entity beans that use EJB 2.0 container-managed persistence should use the local
model. That is, the entity bean's local interface extends the EJBLocalObject interface.
The bean's local home interface extends the EJBLocalHome interface. You must deploy
these interfaces as well as an implementation of your bean's class.
Each Entity Bean must also have corresponding entries in its JAR's deployment
descriptors. The standard deployment descriptor, ejb-jar.xml contains essentially
three different types of deployment information. These are:
1 General Bean Information: This corresponds to the elements
found in the descriptor file and is used for all three types of beans. This information
also includes information on the bean's interfaces and class, security information,
environmental information, and even query declarations.
2 Relationships: This corresponds to the elements found in the
descriptor file and applies to entity beans using CMP only. This is where containermanaged
relationships are spelled out.
3 Assembly Information: This corresponds to the element
which explains how the beans interact with the application as a whole. Assembly
information is broken down into four categories:
■
■
Security Roles: simple definitions of security roles used by the application. Any
security role references you defined for your beans must also be defined here.
Method Permissions: each method of each bean can have certain rules about
their execution. These are set here.
128 BES Developer’s Guide