Sams Teach Yourself BEA WebLogic Server 7.0 in 21 Days
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:
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:
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:
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:
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. |