Figure 8.2 These four types of EJBs are divided into two major classes: entity beans and session
beans. Entity beans build models that are transactional, persistent, and secure. Session beans
wrap distributed transactions.
session beans have no persistent state. They're used as small, fast wrappers
around distributed transactions, and they ensure transactional integrity. State-
ful session beans provide transactional support, with a primitive ability to sup-
port state. This state doesn't assure persistence after a crash. Entity beans with
container-managed persistence are entity beans that can save their state, usu-
ally in a database, through the services of the container. They'll persist
through a crash of the EJB application server. Entity beans with bean-managed
persistence are the same, but they must provide the persistence mechanism.
Each of these types of beans has a specific purpose and can be efficient within
that role. When we step out of that role, we can have problems with perfor-
mance, maintenance, manageability, or scalability.
Bitter BBS with EJBs
In this example, we'll first introduce a full object model for our BBS . As with
all of the “before ” examples in this topic, we'll make some mistakes. Our solu-
tion will suffer from round-tripping and will map every class onto a container-
managed entity bean. Many sources warn against the perils of this type of
architecture, including Core J2EE Patterns , various sources on java.sun.com,
and conferences such as Java One. Still, programming tools and a lack of edu-
cation lead to solutions like this one with alarming regularity. Braden Flowers,
a well-published architect at IBM , has seen numerous poor EJB examples
through his many years of working with IBM 's largest customers. He has
agreed to play the role of a novice and provide the examples in this chapter.
The nature of wrapping legacy architectures is such that we won't always
have a clean, object-oriented design throughout the application, but we