Session Bean Concepts

As stated earlier, the EJB specification defines a standard component-based architecture for performing the two primary server-side activities: business logic processing and data logic processing. To perform business logic processing, the EJB architecture defines a component model to develop transactional server-side components that can be easily deployed on any application server that supports the EJB architecture.

A session bean is a reusable piece of code residing on the server that performs processing on behalf of a client application. In a three-tier application, session beans reside on the middle tier and contain the business logic to process data residing in the back-end tier.

As you have seen in previous days, transaction processing can be either session aware or non session aware. A good example of the technology that you have studied earlier is HttpSessions in Java servlets. Java servlet applications use the HttpSession API for session-oriented transactional functionality apart from their normal non session-oriented transactional functionality. Similarly, the EJB architecture defines a specification to develop session-aware and non session-aware transactional components called session EJBs. The EJB specification defines two types of session EJBs:

• Stateful session bean A stateful session bean, as the name suggests, is a session bean that is session aware. This essentially means that a stateful session bean maintains state a session with a client application. All transactional actions are carried out by a stateful session bean on behalf of a specific client. The stateful session bean lives as long as the client application requires it. Once a client application has finished use of the stateful session bean, it gives an indication to the EJB container to remove the stateful session bean and free up resources used by the session bean.

• Stateless session bean A stateless session bean is a lightweight version of a stateful session bean without the session-aware functionality. Because no state is maintained between a client application and a stateless session bean, the EJB-compliant container maintains a pool of stateless session beans that can serve more than one client application. Stateless session beans will be studied in detail tomorrow.

Before you learn about the different components of a stateful session bean, take a look at Figure 10.4. It shows how different EJB client applications access EJBs deployed in the EJB container.

Figure 10.4. Different client applications accessing stateful session beans.

Components of a Stateful Session EJB

Figure 10.5 shows the parts that compose the stateful session EJB. They will be described in detail in the following sections.

Figure 10.5. Class diagram of the different components of a session bean.

Remote Interface

The remote interface is the first piece that is developed when building a session EJB. The services that the session bean provides to the outside world are defined as a set of business methods in the remote interface. As you can see in Figure 10.5, the remote interface must extend the javax.ejb.EJBObject interface. The java.rmi.Remote interface is the parent of the javax.ejb.EJBObject interface. This hierarchy ensures that the business methods defined in the interface by the bean provider form part of the EJB design contract and the class implementing the functionality of the remote interface can be invoked remotely. A code snippet is given here:

 public interface MyRemoteIF extends javax.ejb.EJBObject  {        public void businessMethod1() throws javax.rmi.RemoteException        {        }        public String businessMethod2() throws javax.rmi.RemoteException        {        } } 

The preceding code snippet shows the session bean's remote interface named MyRemoteIF that extends the javax.ejb.EJBObject interface. The session bean provides two kinds of services represented by the methods businessMethod1() and businessMethod2(). Because the session bean can be accessed remotely, all the methods in the session bean's remote interface throw the java.rmi.RemoteException.

Home Interface

After defining the business methods in a remote interface, the bean provider needs to define a mechanism to enable client applications to obtain a handle to the session bean. To do this, the client application looks up the session bean's home interface in the naming service using the JNDI API. The home interface contains methods that are used by the client application to obtain the handle to the session bean. The client application uses this handle to the session bean to invoke the business methods advertised in the remote interface.

Actually, the client application obtains an object reference whose type is the session bean's remote interface. The session bean's home interface is part of the client-view design contract of the EJB specification. This design contract ensures that client applications can access EJBs in a consistent and standard fashion. The session bean's home interface extends the javax.ejb.EJBHome interface. The session bean's home interface is analogous to a factory for creating session beans. The session bean's home interface contains overloaded create() methods to enable client applications to create session beans initialized with the values passed as parameters to the session bean. The overloaded create() methods in the session bean are implemented in the session bean implementation class as overloaded ejbCreate() methods. They have the same method signatures as the create() methods in the session bean's home interface.

The EJB container provider supplies the implementation class that implements the methods in the session bean's remote interface. A code snippet follows:

 public interface MyHomeIF extends javax.ejb.EJBHome  {        public MyRemoteIF create() throws javax.rmi.RemoteException        {        }        public MyRemoteIF create(String sessionID)                throws javax.rmi.RemoteException        {        } } 

From this code snippet, you can see that the session bean's home interface enables client applications to obtain a handle to the session bean using any of the overloaded create() methods defined in the home interface. The create(String sessionID) method enables the client application to provide a value (sessionID) to initialize the session bean.

Session Bean Implementation Class

The implementation of the functionality behind the methods described in the session bean's remote interface is written in the session bean implementation class. The session bean implementation class does not implement the remote interface. However, as a part of the component design contract of the EJB specification, the session bean implementation class implements the javax.ejb.SessionBean interface.

By implementing the javax.ejb.SessionBean interface, the session bean implementation guarantees that the bean life-cycle methods, such as ejbCreate(), ejbActivate(), and ejbPassivate(), are implemented by the session bean implementation class. The EJB container will invoke these callback methods at different stages of the life cycle of the session bean implementation class. Because the EJB specification defines that the client application never obtains a direct handle to the session bean, the session bean implementation class never needs to implement the remote interface. The EJB container provider generates an intermediate implementation class that intercepts requests from the client application and delegates the business methods as follows:

 public interface MyBean implements javax.ejb.SessionBean  {        public void setSessionContext(javax.ejb.SessionContext)                throws javax.rmi.RemoteException        {             ... // functionality as required        }        public void ejbActivate() throws javax.rmi.RemoteException        {             ... // functionality as required        }        public void ejbPassivate() throws javax.rmi.RemoteException        {             ... // functionality as required        }        public void ejbRemove() throws javax.rmi.RemoteException        {             ... // functionality as required        }        public void businessMethod1() throws javax.rmi.RemoteException        {             ... // business method functionality as required        }        public String businessMethod2() throws javax.rmi.RemoteException        {             ... // business method functionality as required        } } 

Internal Classes and Interfaces in EJB

In the previous section you saw the hierarchy of the classes and interfaces of the different components of a stateful session bean. Now take a look at the different interfaces defined in the EJB specification.

javax.ejb.EJBObject Interface

javax.ejb.EJBObject is the base interface that must be inherited by remote interfaces of all enterprise beans. A remote interface of an enterprise bean defines all the business methods/ services that an enterprise bean provides to client applications. The javax.ejbe.EJBObject object is the primary object with which a client application interacts.

Recall that the EJB specification mandates that a client application never gets a direct reference of the bean implementation class. When a client application calls the create() method on the javax.ejb.EJBHome object, the EJB container returns the object reference of the javax.ejb.EJBObject and not the reference of the actual bean class. After obtaining the EJBObject reference, the client application invokes the business methods defined in the remote interface. The EJBObject reference intercepts the remote method invocations and delegates the business method requests to the actual bean implementation class because the bean implementation class implements the functionality of the business methods. But then what implements the methods that are part of the javax.ejb.EJBObject interface? The answer is the EJB container.

The EJB container provided by the vendor implements the methods in the javax.ejb.EJBObject interface. The invocation of these methods of the javax.ejb.EJBObject is not delegated to the bean implementation class.

There is one other aspect that is not covered in this section: how javax.ejb.EJBObject delegates the business method request to the actual bean implementation class. You will study this topic in the section titled "Strategies for Implementing EJBObject or ELBLocalObject Request Delegation." Look at the following methods, which are found in the javax.ejb.EJBObject interface:

• getEJBHome() Returns the javax.ejb.EJBHome object reference. This method is implemented by the EJB container provider and invoked when a client application performs a lookup to obtain a bean's EJBHome object reference.

• getHandle() Returns a javax.ejb.Handle object. The javax.ejb.Handle object is a reference to the EJBObject deployed in the EJB container. The javax.ejb.Handle object reference can be used again in the future by the client application to obtain the same EJB object reference. This method is implemented by the EJB container provider and invoked when a client application performs a lookup to obtain a bean's EJBHome object reference.

• getPrimaryKey() Is invoked only on an entity bean and not on a session bean. The getPrimaryKey() method, as the name suggests, returns a PrimaryKey object reference of an entity bean. In order to return any PrimaryKey object, the method returns a java.lang.Object reference. This method is implemented by the EJB container provider and invoked when a client application performs a lookup to obtain a bean's EJBHome object reference.

• isIdentical(EJBObject) Compares two EJB object references and checks whether or not they are alike. The isIdentical() method accepts the object reference of the EJBObject reference to compare with as a parameter and returns a Boolean true or false value as the result of the comparison. This method is implemented by the EJB container provider and invoked when a client application performs a lookup to obtain a bean's EJBHome object reference.

• remove() Destroys an EJBObject object reference. This method is implemented by the EJB container provider and invoked when a client application performs a lookup to obtain a bean's EJBHome object reference.

javax.ejb.EJBHome Interface

The javax.ejb.EJBHome interface is the first object that a client application interacts with when the client application wants to use an EJB. The javax.ejb.EJBHome interface contains methods that act as a factory for creating EJB bean object instances. Every home interface of an enterprise bean must extend the javax.ejb.EJBHome interface. You define create() methods with different signatures in the home interface for its enterprise bean.

The methods in the javax.ejb.EJBHome interface like remove(), remove(Handle), getHomeHandle(), and getEJBMetaData() are implemented by the automatically generated classes of the EJB container provider/vendor (in this case the EJB container in the WebLogic application server). These classes are automatically generated during deployment of the EJB. The bean provider (in this case, the developer) must define any additional methods in the home interface as required, such as create() or find().

A client application obtains a reference to the home interface of the EJB by looking up the object reference using the JNDI API for naming and directory services. The bean provider/deployer must ensure that the home interface to be used by client applications is registered in the JNDI. The client application then invokes methods in the home interface object reference to initiate the EJB instance's life cycle. Take a look at the following methods, which are found in the javax.ejb.EJBHome interface:

• getEJBMetaData() Is used by a client application to obtain metadata information of the EJB. When the getEJBMetaData() method is invoked, the method returns the metadata information packaged in the javax.ejb.MetaData object reference. The javax.ejb.EJBMetaData interface contains methods like isSession() and isStatelessSession() that can be used to detect the type of a session bean, whether stateful or stateless.

• create() Is used by the client application to obtain a reference to the remote (or local) EJBObject reference. The client application uses this object reference to interact with the bean. Because the home interface is used by client applications to generate and create bean instances, the bean provider, namely the developer, must define the create() methods with different signatures in the home interface. The EJB bean provider provides an implementation of the create() methods in the bean class.

• getHomeHandle() Is used by the client application to obtain a reference of the home object of the EJB. A call to this method returns a javax.ejb.HomeHandle object reference. The client application can store this returned javax.ejb.HomeHandle object reference and use it in the future to obtain a reference of the home object of the bean without doing a lookup in the naming or directory service.

• remove() Destroys an EJB object. The remove() method accepts a javax.ejb.Handle object as a parameter. The javax.ejb.Handle object is a reference of the EJB object. This javax.ejb.Handle object reference is obtained by the client application by calling the getHandle() method on the remote EJB object reference.

• remove() (overloaded) Removes the PrimaryKey object of an entity bean. This overloaded method takes a PrimaryKey object as a parameter. Because PrimaryKey objects can be implemented by any entity beans, this remove() method takes a java.lang.Object as a parameter, thus enabling any PrimaryKey object to be destroyed using this overloaded remove() method.

javax.ejb.SessionBean Interface

The javax.ejb.SessionBean interface is a design contract defined by the EJB specification between the SessionBean and the EJB container. This means that in order for the EJB container to manage and interact with the session bean, the session bean must implement the methods in the javax.ejb.SessionBean interface. Because the session bean guarantees implementation of the methods in the javax.ejb.SessionBean interface, which the EJB container is aware of, the EJB container can invoke these methods.

The methods in the javax.ejb.SessionBean interface are callback methods. Each of these methods is invoked by the EJB container at certain stages during the life cycle of the session bean.

Do you recall the methods that were listed for each stage in the section titled "Life Cycle of a Stateful Session EJB"? In that section, you saw that the methods ejbCreate(), ejbPostCreate(), ejbActivate(), ejbPassivate(), ejbRemove(), and setSessionContext() were invoked by the EJB container at different life-cycle stages. Now look at each of these methods in detail:

• ejbCreate() The first method invoked by the EJB container on the session bean when the create() method is called by a client application on the javax.ejb.EJBHome object. The ejbCreate() method is not a part of the javax.ejb.SessionBean interface. A session bean class implements the ejbCreate() method. For a stateful session bean, the ejbCreate() method is used by the client application to initialize or set certain properties in the stateful session bean class. A stateful session bean can have overloaded ejbCreate() methods, which take different parameters. The signature of each of the overloaded ejbCreate() methods must match the signature of the create() methods defined in the EJBHome object of the stateful session bean.

• ejbPostCreate() A callback method invoked on the session bean class by the EJB container. The ejbPostCreate() method is executed at the end of the creation of an instance of the session bean. This callback method enables the session bean to perform any initialization at the end of the creation process.

• ejbActivate() A callback method invoked by the EJB container on the session bean during the Process Operations stage of the session bean's life cycle. The ejbActivate() method is executed when the container activates (restores) the state of a session bean that has been passivated. A session bean can use the ejbActivate() method to reinitialize any nonserializable resources held by it, for example, database connections.

• ejbPassivate() The corresponding callback method to the ejbActivate() method. The EJB container invokes the ejbActivate() method on the session bean when it determines the least frequently used session bean instance and removes it from memory. The state of the removed session bean instance is passivated, that is, stored in a temporary storage. A session bean can use the ejbPassivate() method to free up any nonserializable resources held by it, such as database connections.

• setSessionContext() The EJB container calls the setSessionContext() method implemented by the session bean when a new instance of the session bean is created. The setSessionContext() method is passed a SessionContext object as a parameter. The EJB container populates this SessionContext object when it invokes the setSessionContext() method. The session bean is required to store this SessionContext object reference in an instance variable and save it for future use.

• ejbRemove() The final method invoked in the last stage of the session bean's life cycle. The EJB container invokes this method on the session bean instance at the end of its life span. This method is invoked when the client application calls the remove() method on the EJBHome object or when the EJB container destroys the instance of the session bean when a timeout of the session bean instance occurs.

After this discussion, take a look at Figure 10.6: It shows the sequence of interactions between an EJB client with a stateful session bean. This will give you an idea of how the different classes and interfaces of an EJB participate in a client application request.

Figure 10.6. Sequence diagram of client interaction with a stateful session bean.