- The client’s view
- Fundamentals of the EJB architecture
- Types of EJB
- Distributed and local EJB semantics
- Anatomy of an EJB
- Principle of operation: session and entity EJBs
- Principle of operation: message-driven EJBs
- The EJB container and its proxies
- Overview of the EJB API
- EJB rules, standards and limitations
- Assembly and deployment
3.6 Principle of operation: session and entity EJBs
When the EJB is deployed, the server and the deployment tools inspect the factory interface and generate the appropriate (local or remote) home object. ‘Generation’ in this context means that the home object is produced as Java source code, which is then compiled into a Java class. The resulting home object class is then instantiated, and its name made available for clients to look up. The server also generates the EJB object from the remote interface, but does not necessarily instantiate it at this point. The implementation class is made available on the server, but this also is not instantiated.
So when an EJB is first deployed, and whenever the server is restarted, the client can expect to see a home object instance in place for each EJB. The interaction diagram of Figure 3.6 shows a simplified, general interaction between the client, the container, and the implementation class. In later chapters, we will see how this interaction is managed for specific types of EJB. Note that this overview does not depend on whether the client is using the local or distributed client view of the EJB.
Figure 3.6 . Basic principle of operation of a session or entity EJB.
The client does a name lookup to find the home object; the name lookup service returns a reference to the home object (with the distributed client view, it actually returns the home stub—that is, a stub configured to communicate with the home object).
The client calls a ‘create’ or ‘find’ method on the home object, according to whether it wants to create a new EJB or find an existing EJB. Only entity EJBs are subject to ‘find’ operations.
The home object, in conjunction with the container (if these aren’t the same object), initializes an instance of the implementation class. This may involve creating a new instance or finding a free instance in the pool. In either case, an instance is made ready for use.
The home object or container initializes an EJB object for the selected EJB. Again, this may be a new instance or a pooled instance.
The home object returns to the client a reference to the EJB object. With distributed operation, this is actually the remote stub—that is, a stub connected to the EJB object.
The client calls whatever methods it needs on the EJB object.
The EJB object checks the credentials of the caller, creates a new transaction if necessary, and delegates the business method call onto the implementation. If the EJB object creates a new transaction, it will attempt to complete it before returning control to the caller.
The client can make repeated business method calls on an active EJB reference: For each call, the container repeats the sequence of operations described in step 7.