Designing the BMP Entity Bean
Figure 10.2 shows the design of the Student component. The StudentEJB bean-managed entity bean implements the javax.ejb.EntityBean interface. It implements the methods setEntityContext(), unsetEntityContext(), ejbActivate(), ejbPassivate(), ejbLoad(), ejbStore(), and ejbRemove() as defined in the javax.ejb.EntityBean interface. It also implements the ejbCreate() and ejbPostCreate() methods.
Figure 10.2. Student entity bean design.
A StudentEJB entity bean class consists of the persistent fields studentId, firstName, lastName, and address. You code them as instance variables in the entity bean class. A Student entity bean is identified by its primary key, studentId.
The StudentEJB bean class also implements the home method ejbHomeGetTotalNumberOfStudents().
We provide remote interfaces to our entity bean. They include a remote home interface (StudentHome) and a remote interface (Student). The StudentHome home interface extends the javax.ejb.EJBHome interface and defines a single create method, two finder methods(findByPrimaryKey, findByLastName) and one getTotalNumberOfStudents home method. The Student remote interface extends the javax.ejb.EJBObject interface and defines the getters and setters for persistent fields. As you learned on Day 2, “Understanding EJB Types and Interfaces,” container tools generate the classes that correspond to the home and remote interfaces.
The state of StudentEJB is stored in the students table of the relational database. The Data Definition Language (DDL) to create the students table is as follows:
create table students (student_id varchar(64),
first_name varchar(64),
last_name varchar(64),
address varchar(64));
Today's example uses the PointBase database server with WebLogic Server. In the case of the JBoss server, we'll use the HyperSonic database.
The StudentEJB bean class uses database access objects (DAOs) to access the database. Data access objects are discussed in the following section.
Data Access Objects
A data access object is a helper object used to encapsulate access to databases. Data access objects can encapsulate access to more than one database, more than one table within one database, and different types of databases. By encapsulating data access calls, DAOs allow the adaptation of data access to different schemas or even to different database types. Both session beans and entity beans with bean-managed persistence can use DAOs.
When an entity bean with bean-managed persistence or a session bean needs to access a database within a method implementation, a corresponding method in the DAO implements the actual logic of fetching or updating data in the database. This removes the data access logic from the enterprise bean class. The bean's business logic is not cluttered with data access calls, such as JDBC calls, which makes it much cleaner and readable.
As shown in Figure 10.3, the application uses the interface StudentDAO to access the students table. The sample application contains the subclass StudentDAOPB, which is used to access a PointBase database.
Note
Many database vendors provide proprietary extensions to SQL to provide additional functionality and to achieve higher performance. If the enterprise bean contains data access logic in addition to business logic, it would be difficult to modify it to use a different type of database. The DAO design pattern is used to separate business logic from data access logic. The DAO interface provides a well-defined API for accessing and manipulating the data. The enterprise bean is coded to use this DAO interface. Typically, you would write one DAO class for each database that you want to support. At deployment time, the deployer would choose the DAO corresponding to the database. This ensures the enterprise bean class is not modified to use a different database type.