Java Reference
In-Depth Information
deployment phase, the life cycle of these CMP bean instances are same as that of BMP instances
discussed in the previous Chapter 21 .
For each create method defined in the home interface, you need to write a corresponding ejbCreate
method. As a bean developer, your job is to assign the persistent fields with their initial values by calling
the setters . You may find something weird by looking at the implementation shown in Listing 21-3 .
Although the return type is supposed to be the primary key, the ejbCreate method actually returns
null at the end of the code. This is required by EJB specification. The rationale is that this method will
only be called by the EJB container and that the container always knows exactly what the primary key is
for each EJB.
Note
For a BMP bean, you must write code for the ejbRemove method. For a CMP bean,
since the database-access logic is implemented by the EJB container, you typically do
not need to write any code.
In the code shown in Listing 22-3 , you do not see even the empty implementation of any finder
method defined in the home interface. How does the EJB container generate the implementation for
finder methods? For the method findByPrimaryKey , the container knows how to implement it by
looking at the primary key class type in the deployment descriptor and the corresponding database
column specified. For implanting all other methods, the EJB container follows your orders, given in the
form of EJB QL in the deployment descriptor. The EJB QL is discussed in detail later.
You still need to implement all the business methods defined in the remote interface, except for the
getters and setters . In the YachtBean , you only need to code the business method
createYachtSession . You first look up the YachtSessionEJB 's home interface from JNDI, then
create a remote interface handle. Since this will always be an EJB -to-EJB call, you may want to use
YachtSessionEJB 's local interface for better performance.
To summarize this discussion, Table 22-2 lists major differences between coding a BMP bean
implementation class and coding a CMP implementation class. All the database-access calls by bean
developers for BMP beans are automatically generated by the EJB container. Since the bean-
implementation classes you write contain no implementations, it is important to declare them as abstract.
The corresponding concrete classes are automatically generated by EJB container at the deployment
phase.
Table 22-2: Coding Differences between CMP and BMP
Item
CMP
BMP
Class Definition
Abstract
Not abctract
Database access calls
Generated by tools
Coded by developers
Persistent state
Represented by virtual persistent
fields
Coded as instance variables
Accessor to persistent and
relationship fields
Required
None
Customized finder
methods
Handled by EJB container (but
the developer must define the
EJB QL queries)
Coded by developers
Select Methods (??)
Handled by EJB container
None
Return type of ejbCreate
method
null
Primary key
With CM entity bean, no database code is needed. The database access functionality is specified by
EJB developers or application assemblers in description descriptor in EJB Query language that is
discussed next.
Search WWH ::




Custom Search