Chapter 13 discusses the two fundamental roles in the RMI environment: the client of the remote object and the object itself, which acts as a kind of server or service provider. These two roles exist in the EJB environment as well, but EJB adds a third role, called the container. Figure 6-1 shows a conceptual diagram of how the three EJB roles interact. The container is responsible for interceding between the client (any code that is invoking the EJB) and the EJB component itself. The container also provides all the extra services for an EJB object mentioned earlier: transaction processing, security, object persistence, and resource pooling. If you’re familiar with CORBA, you can think of the EJB container as being roughly equivalent to the ORB in CORBA, with a few of the CORBA services thrown in as well. In EJB, however, the container is strictly a server-side entity. The client doesn’t need its own container to use EJB objects, but an EJB object needs to have a container in order to be available for client use.
Figure 6-1. The basic roles in an EJB environment
At the heart of an EJB component is the actual implementation object. The EJB implementation class is where the real value of the EJB lies—the business methods that clients want to invoke are implemented here.
The EJB object:
Implements the business logic behind the operations ...