Expert One-on-One™ J2EE™ Development without EJB™

Chapter 12. Replacing Other EJB Services

So far we've focused primarily on the EJB container model and EJB declarative transaction management. We've seen how IoC and AOP can provide a superior replacement for these in many cases.

As the EJB solution for persistence (entity beans) is inferior to alternatives such as Hibernate and JDO, we would not choose to use EJB for its persistence capabilities.

We've also considered EJB remoting. If you want a distributed architecture—and that's a big if—EJB is a pretty good technology for managing your distributed objects. Most of the time, however, co-locating business objects with their callers is a better architectural choice.

There remain other EJB services that we need to consider. Let's look at how we can replace the most important of these in typical applications.

Besides CMT, the EJB services most commonly cited as justifying use of EJB are:

• Thread management. The EJB model aims to allow developers to code EJBs without concern as to concurrency. We'll examine whether this goal is as important as is often supposed, whether EJB achieves it, and look at alternatives that achieve the same ends.

• SLSB instance pooling. Related to thread management: the ability of the EJB container to maintain a pool of SLSB instances and to efficiently delegate incoming requests to a pooled instance.

• Declarative role-based security, built on the standard J2EE security infrastructure.

In this chapter, we'll discuss these important services.

We'll focus on replacing ...