How Everything Works Together

Let us assume that the component BankAccount is not included in an aggregate, but is installed directly in an EJB container, in order to be used by client programs. The installation takes place with the help of the relevant tools. The specification obligates the creator of an EJB container and the persistence manager to provide these tools. It is left to the creator to determine what these tools look like and how they are to be used. As a rule, they support the capturing of all relevant data for the installation of a component via a graphical user interface. However, of primary importance is the result of the tool-supported installation procedure. It provides the missing links in the EJB architecture: the implementation of the home and remote interfaces (respectively the local home and local interfaces) of the Enterprise Bean and in the case of a container-managed entity bean the implementation of the concrete bean class. Figure 3-3 shows these relationships.

Figure 3-3: Generation of the missing architectural components.

As we have already mentioned, an Enterprise Bean uses either local or remote interfaces. The implementation class of the home or local home interface is usually called EJBHome, while that of the local or remote interface is denoted by EJBHome, while the remote interface is usually known as EJBObject. The classes EJBHome and EJBObject are generated from the components of a bean by the tools of the container's creator.

If we are dealing with an entity bean with container-managed persistence, then it is the job of the persistence manager to generate a concrete class. This is derived from the abstract bean class and represents the necessary code for persistence. For this generation, the additionally created instructions regarding the database and table(s) from the persistence descriptor as well as the persistence fields of the components are employed (see in this respect the example in Listing 3-6).

The EJBHome object serves at run time as a sort of object factory, and the EJBObject as a sort of functional wrapper for the Enterprise Bean in question. (See Figure 3-4.) They are the extension of the run-time environment of the EJB container for particular bean types.

Figure 3-4: EJBHome and EJBObject at run time.

If the Enterprise Bean uses remote interfaces, then they are both remote objects in the sense of Java RMI. If the Enterprise Bean uses local interfaces, then they are traditional Java objects. In both cases the client calls upon the methods of the EJBHome and EJBObject, never directly those of the bean instance. EJBHome and EJBObject delegate the respective method calls (after or before particular container-related routines) to the bean instance.

With this indirection the EJB container is able to bring its implementation of the declarative instructions into the deployment descriptor. The content of the deployment descriptor influences considerably the generated code of the EJBHome and EJBObject classes.

The EJBHome class contains the code for the generation, location, and deletion of bean instances. Often, code is generated for resource management into the EJBHome class. The EJBObject class implements the transaction behavior, security checking, and, as needed, the logic for container-managed persistence. The implementation of these classes depends to a great extent on the creator. The specification makes no compulsory prescriptions for the creator with respect to the implementation of EJBHome and EJBObject.

No instance other than the EJBHome and EJBObject objects can cooperate with the bean instance. It is completely protected by the container classes. Communication between beans also always takes place by way of the container classes EJBHome and EJBObject.

From this state of affairs we obtain answers to questions that may have been left unanswered in the previous section. The home and remote interfaces do not need to be implemented, since the implementation classes are generated by the container tools. (The same holds in the case where a local home interface and local interface are used.) The Enterprise Bean is not a remote object, since it is never to be addressed externally. It should be able to be addressed via EJBHome and EJBObject. The EJB container would otherwise have no possibility of intervention to keep up with its tasks. Therefore, the interfaces javax.ejb.EJBHome and javax.ejb.EJBObject (the basic interfaces of the home and remote interfaces) are also derived from java.rmi.Remote.

It is even clear why the signatures of the bean methods and the methods in the home and remote interfaces must agree. The interfaces are implemented by EJBHome and EJBObject classes. They delegate the calls to the interface methods to the corresponding methods of the bean class. The code necessary for this is generated. If the signatures in the methods declared in the interfaces do not agree with the corresponding bean methods or if these methods don't even exist in the bean class, then a complaint will be registered in the generation of EJBHome and EJBObject by the container tools, or else the result will be a run-time error.

Finally, EJBHome and EJBObject ensure that in the case of session beans each client is able to work with an instance exclusive to it, while in the case of entity beans several clients can share the same instance.