Sams Teach Yourself BEA WebLogic Server 7.0 in 21 Days

While studying the javax.ejb.EJBObject interface in the previous section, you learned that how the javax.ejb.EJBObject delegates requests to the session bean implementation class is left to the container provider vendor. The EJB specification does not define how the implementation class of the javax.ejb.EJBObject should be provided by the container provider vendor.

Because the implementation of the javax.ejb.EJBObject class does not form part of the EJB specification, container provider vendors use different ways to provide the implementation class and the way it delegates the business method requests to the session bean class.

Note

In Object Oriented Designing (OOD), relationships between two objects can be of two types: is-a and has-a. The is-a relationship among objects is essentially an inheritance relationship between two objects. The has-a relationship among objects is a containment relationship. The container provider's implementation class leverages both these ways to implement the javax.ejb.EJBObject interface.

Hence, there are three primary ways that the implementation class of the javax.ejb.EJBObject class interacts with the session bean. You may now take a look at each of these in detail.

EJBObject as Wrapper for the Session Bean Class

The simplest way to implement an association between the javax.ejb.EJBObject's implementation class and the session bean class is by a containment relationship. From the class diagram in Figure 10.7, you can see that the implementation class of the javax.ejb.EJBObject (and the session bean remote interface) implements the session bean interface (as well as the javax.ejb.EJBObject interface inherited by the session bean interface). However, this implementation class provided by the container provider vendor implements only the methods within the javax.ejb.EJBObject interface.

Because the bean provider writes the session bean implementation class to provide the underlying functionality of the business methods in the session bean remote interface, the javax.ejb.EJBObject object uses the session bean class as its instance variable (containment relationship). The container provider's implementation class provides the functionality for the methods in the javax.ejb.EJBObject interface. For the business methods of the session bean's remote interface, the implementation class provides wrapper methods. When the implementation class of the javax.ejb.EJBObject interface receives a request for a business method in the session bean's remote interface, it invokes the wrapper business method. This delegates the request to the actual session bean implementation class to invoke the appropriate business method that it has implemented.

Here is a code snippet of the source code of the implementation class of the javax.ejb.EJBObject interface generated by the container:

MyRemoteEJBOBject implements MyRemote { ... MySessionBean myBean = new MyBean(); public EJBHome getEJBHome() { //container provider's implementation ... } public java.lang.Object getPrimaryKey() { //container provider's implementation ... } public void remove() { //container provider's implementation ... } public Handle getHandler() { //container provider's implementation ... } public void remove() { //container provider's implementation ... } public boolean isIdentical(javax.ejb.EJBObject) { //container provider's implementation ... } public void businessMethod1() { //delegate request to the session bean implementation class myBean.businessMethod1(); ... } public String businessMethod2() { //delegate request to the session bean implementation class String tmpStr = myBean.businessMethod2(); ... return tmpStr; } }

EJBObject Extending the Bean Class

The second way for the container provider to implement the javax.ejb.EJBObject interface and delegate requests to the session bean class is by maintaining an inheritance relationship with the session bean class. In Figure 10.8 you can see that the implementation class implements the session bean's remote interface (containing the business methods) and the javax.ejb.EJBObject interface (inherited by the session bean's remote interface) and extends the session bean class.

Inheriting from the session bean class enables the container-provided implementation class to inherit the functionality of the session bean's remote interface that the session bean class supplies. The container provider's implementation class contains the functionality for the methods in the javax.ejb.EJBObject interface. For the business methods in the session bean's remote interface, the container-provided implementation class contains wrapper methods, which in turn invoke the methods inherited from its super class, the session bean class.

Look at the following code snippet of the source code of the implementation class of the javax.ejb.EJBObject interface generated by the container provider:

MyRemoteEJBOBject extends MyBean implements MyRemote { ... public EJBHome getEJBHome() { //container provider's implementation ... } public java.lang.Object getPrimaryKey() { //container provider's implementation ... } public void remove() { //container provider's implementation ... } public Handle getHandler() { //container provider's implementation ... } public void remove() { //container provider's implementation ... } public boolean isIdentical(javax.ejb.EJBObject) { //container provider's implementation ... } public void businessMethod1() { //delegate request to the inherited method of the session bean super class businessMethod1(); ... } public String businessMethod2() { //delegate request to the inherited method of the session bean super class String tmpStr = businessMethod2(); ... return tmpStr; } }

EJBObject with No Direct References to the Bean Class

The third and least-used way for the container provider to provide the implementation class of the javax.ejb.EJBObject interface and delegate business method requests to the session bean class is by not maintaining any direct references to the session bean class, as shown in Figure 10.9. Now a question arises: If there is no association between the container provider's implementation class and the session bean class, how does the implementation class of the javax.ejb.EJBObject interface forward business method requests to the session bean class? In this scenario, when the implementation class of the javax.ejb.EJBObject interface is being generated, the functionality (source code) of the business methods in the session bean's remote interface supplied by the session bean is copied into wrapper methods in the implementation class of the javax.ejb.EJBObject interface. Hence, any requests for the business methods in the session bean's remote interface are not delegated by the container-provided implementation class but are handled locally within itself (because of the functionality copied from the session bean class).

Now look at the following code snippet of the source code of the implementation class of the javax.ejb.EJBObject interface generated by the container provider:

MyRemoteEJBOBject implements MyRemote { ... public EJBHome getEJBHome() { //container provider's implementation ... } public java.lang.Object getPrimaryKey() { //container provider's implementation ... } public void remove() { //container provider's implementation ... } public Handle getHandler() { //container provider's implementation ... } public void remove() { //container provider's implementation ... } public boolean isIdentical(javax.ejb.EJBObject) { //container provider's implementation ... } public void businessMethod1() { //contains the functionality of the business method copied from the session bean class ... } public String businessMethod2() { //contains the functionality of the business method copied from the session bean class String tmpStr; ... return tmpStr; } }