Session Beans in EJB 3.0 - Implementing Session Beans
(Page 3 of 4 )
In the last part I detailed the general steps involved in implementing an EJB. Here are those steps for recapitulation:
- Specifying the Bean type
- Developing the POJO
In the case of a Session Bean, there are no different steps. However, the sub-steps involved in implementing the Session Bean vary according to the sub-type of the Session Bean.
Specifying the Bean type: The Bean type as well as the Bean sub-type is no longer based on the interface being implemented or on the deployment descriptor. The basis for the Bean type in EJB 3.0, as already stated in the first part, is annotations. To specify the sub-type of Session Bean there are two annotations
- @Stateless -
This tells the EJB compiler that the Session Bean sub-type is the Stateless Session Bean. So the required helper classes are generated such that the Conversational State is not saved. The Container decides whether or not to save the Conversational State based on the services requested by the Bean and its helper classes.
- @Stateful:
To make a Session Bean stateful, this annotation is used. The EJB compiler then generates the required helper classes to use the container's services for saving Conversational State.
By helper classes, I mean the classes providing details of the annotations which are the part of JEE libraries.
Developing the POJO: All the Beans specified by EJB 3.0 are Plain Old Java Objects (POJO). Session Beans are no exception. With Session Beans there are two steps that are required for developing a POJO, which are defining the business interface and developing the POJO by implementing the business interface. It is here that we see the actual differences between Stateless and Stateful Session Beans.
Defining the Business Interface: The Business Interface is the Plain Old Java Interface (POJI) and not any specialized interface as that in EJB 2.0. This means the Business Interface need not be extended from any other interface. It consists of methods supported by the Bean. There is a difference between the Stateless and Stateful Session Beans in the case of the Business Interface. The following is an example of the Business Interface for a Stateless Bean:
package examples.session.stateless;
/**
* This is the Hello business interface.
*/
public interface Hello {
public String hello();
}
Here the interface contains only the Business methods. There are no instance variables. Now let's have a look at the interface for a Stateful Session Bean:
package examples.session.stateful;
/**
* The business interface - a plain Java interface with only
* business methods.
*/
public interface Count {
/**
* Increments the counter by 1
*/
public int count();
/**
* Sets the counter to val
* @param val
*/
public void set(int val);
/**
* removes the counter
*/
public void remove();
}
Though the interface contains no instance variables, the method has been declared as though an instance variable(s) is present. The reason is that the implementation of this interface i.e. the POJO would have that variable. Next we are going to see how the implementation looks.
Developing the POJO by Implementing the Business Interface: The next step is to develop the POJO by implementing the interface. Since the Bean implementation is a POJO, it need not to implement any interface other than the Business Interface. However, it is described using annotations -- in other words, the sub-type of the Bean, the name of the Business Interface, any interceptors etc. are described using annotation in the Bean class. The annotations, the use of which are mandatory are - type and the remote class annotations. The former is @Stateful or @Stateless and the latter is the @Remote annotation. With a Stateless Session Bean the POJO doesn't contain any instance variables as shown in the following code:
package examples.session.stateless;
import javax.ejb.Remote;
import javax.ejb.Stateless;
/**
* Stateless session bean.
*/
@Stateless
@Remote(Hello.class)
public class HelloBean implements Hello {
public String hello() {
System.out.println("hello()");
return "Hello, World!";
}
}
Here the @Remote annotation is used to specify the class of the Remote object, which with EJB 3.0 is the Business Interface. With the Stateful Session Bean, the POJO contains the instance variables which are evident from the following example:
package examples.session.stateful;
import javax.ejb.*;
/**
* A Stateful Session Bean Class that shows the basics of
* how to write a stateful session bean.
*
* This Bean is initialized to some integer value. It has a
* business method which increments the value.
*
*/
@Stateful
@Remote(Count.class)
public class CountBean implements Count {
/**
* The current counter is our
* Conversational State.
*/
private int val;
/**
* The count() business method.
*/
public int count() {
System.out.println("count()");
return ++val;
}
/**
* The set() business method.
*/
public void set(int val) {
this.val = val;
System.out.println("set()");
}
/**
* The remove method is annotated so that the
* container knows it can remove
* the bean after this method returns.
*/
@Remove
public void remove() {
System.out.println("remove()");
}
}
The private integer val is part of the Conversational State. This is the main difference between Stateful and Stateless Bean implementations.
That brings us to the end of this section. In the next section, I will be developing a real world example for the Stateful Session Bean.
Next: Session Beans in the Real World >>
More Java Articles
More By A.P.Rajshekhar
