Session Beans
This page contains a brief summary of EJB 3.0 Session Beans. It only gives basic information, for more details about life cycle and other functionalities check the EJB 3.0 reference or some book like EJB3 in Action.
Session Beans' usage is mainly to store business logic and make that logic available to clients. They can be accessed locally, remotely or via web services. The container gives some services to enhance these beans like thread safety, transaction and timer services amongst others.
Session Beans (SB) are POJOs with some annotations that tell the container this class is an EJB, and at least one interface (EJB use interface-based programming). As POJO all SB can use inheritance. All SB need at least one no-argument constructor (public or protected) and all the business methods must have public access but no static or final modifiers. There are two kinds of SB: stateless and stateful.
Stateless Session Beans
These beans don't maintain any conversational state so each call is like a new call from a new client. They have no "memory". They are ideal for fast operations and as interfaces to webservices. It may have 3 interfaces, not all of them have to expose the same business methods:
- Local (@Local) can only be accessed from the same container. No special restrictions.
- Remote (@Remote) can be accessed remotely using RMI. All parameters and return values must be serializable.
- Webservice (@Webservice) allows access using SOAP protocol. No special restrictions.
It allows up to two method callbacks to manage bean status that don't need to be public. Usually they are used to load/free resources like DB connection. They are:
- PostConstruct (@PostConstruct) is run after the bean it's been loaded, to initialize it's status
- PreDestroy (@PreDestroy) is run before scrapping the bean, to close any resource it's using
An example of stateless bean with two interfaces, one local and one remote:
@Statelesspublic class Test2Bean implements Test2Remote, Test2Local { //loads a jndi resource using DI
@Resource(name = "HSQLDB")
private DataSource HSQLDB; public void businessMethod1(String parameter1) {
} public String businessMethod2() throws FileNotFoundException {
return null;
} //life cycle methods (below) can be non-public
@PostConstruct
private void methodConstruct(){
} @PreDestroy
protected void methodDestroy(){
}}
An example of Local interface for the previous bean:
@Local
public interface Test2Local {
void businessMethod1(String parameter1);
String businessMethod2() throws FileNotFoundException;
}
An example of Remote interface for the previous bean:
@Remote
public interface Test2Remote {
void businessMethod1(String parameter1);
String businessMethod2() throws FileNotFoundException;
}
Sateful Session Beans
These beans maintain status between calls. This means they have a performance penalty as can't be pooled and one instance is launched per client, but are perfect tools for multi-step processes like wizards. They have an extra restriction: all it's instance variables must be serializable, due to how the container manages this type of beans. A stateful bean may have 2 interfaces, not all of them have to expose the same business methods:
- Local (@Local) can only be accessed from the same container. No special restrictions.
- Remote (@Remote) can be accessed remotely using RMI. All parameters and return values must be serializable.
It allows up to five method callbacks to manage bean status that don't need to be public. Usually they are used to load/free resources like DB connection. They are:
- PostConstruct (@PostConstruct) is run after the bean it's been loaded, to initialize it's status
- PreDestroy (@PreDestroy) is run before scrapping the bean, to close any resource it's using
- PrePassivate (@PrePassivate) is run before passivating the bean. Usually it's similar to PreDestroy
- PostActivate (@PostActivate) is run after restoring the bean. Usually it's similar to PostConstruct
- Remove (@Remove) is called by the client to notify the server it can destroy the bean. It's important to call it to free unused resources. More than one method in the same bean can have this annotation.
An example of stateless bean with two interfaces, one local and one remote:
@Stateful
public class TestStatefulBean implements TestStatefulRemote, TestStatefulLocal { //we call another bean using DI
@EJB
private Test2Local test2Bean;
public void businessMethod1() {
} @Remove
public String businessMethod2() {
return null;
} @PostConstruct
@PostActivate
private void methodConstruct() {
} @PreDestroy
@PrePassivate
protected void methodDestroy() {
}}
An example of Local interface for the previous bean:
@Local
public interface TestStatefulLocal { void businessMethod1();
String businessMethod2();
}
An example of Remote interface for the previous bean:
@Remote
public interface TestStatefulRemote { void businessMethod1();
String businessMethod2();
}
