SESSION BEAN | J2EE Tutorial pdf

SESSION BEAN

A session bean represents a single client inside the J2EE server. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server. As its name suggests, a session bean is similar to an interactive session. A session bean is not shared--it may have just one client, in the same way that an interactive session may have just one user. Like an interactive session, a session bean is not persistent. When the client terminates, its session bean appears to terminate and is no longer associated with the client.
State Management Modes
There are two types of session beans: stateful and stateless.
Stateful Session Beans
The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts ("talks") with its bean, this state is often called the conversational state.
The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears. This transient nature of the state is not a problem, however, because when the conversation between the client and the bean ends there is no need to retain the state.
Stateless Session Beans
A stateless session bean does not maintain a conversational state for a particular client.
When a client invokes the method of a stateless bean, the bean's instance variables may contain a state, but only for the duration of the invocation. When the method is finished, the state is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client.
Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.
At times, the EJB container may write a stateful session bean to secondary storage. However, stateless session beans are never written to secondary storage.
Therefore, stateless beans may offer better performance than stateful beans.
When to Use Session Beans
In general, we should use a session bean if the following circumstances hold:
=> At any given time, only one client has access to the bean instance.
=> The state of the bean is not persistent, existing only for a short period of time (perhaps a few hours).
Stateful session beans are appropriate if any of the following conditions are true:
=> The bean's state represents the interaction between the bean and a specific client.
=> The bean needs to hold information about the client across method invocations.
=> The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
=> Behind the scenes, the bean manages the work flow of several enterprise beans. To improve performance, we might choose a stateless session bean if it has any of these traits
=> The bean's state has no data for a specific client.
=> In a single method invocation, the bean performs a generic task for all clients. For example, we might use a stateless session bean to send an e-mail that confirms an online order.
The bean fetches from a database a set of read-only data that is often used by clients.
Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month.
The Life Cycle of a Stateful Session Bean
Figure illustrates the stages that a session bean passes through during its lifetime. The client initiates the life cycle by invoking the create method. The EJB container instantiates the bean and then invokes the setSessionContext and ejbCreate methods in the session bean. The bean is now ready to have its business methods invoked.
While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. The EJB container invokes the bean's ejbPassivate method immediately before passivating it. If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, moving it back to the ready stage, and then calls the bean's ejbActivate method.
At the end of the life cycle, the client invokes the remove method and the EJB container calls the bean's ejbRemove method. The bean's instance is ready for garbage collection.
Our code controls the invocation of only two life-cycle methods--the create and remove methods in the client. All other methods in Figure are invoked by the EJB container. The ejbCreate method, for example, is inside the bean class, allowing we to perform certain operations right after the bean is instantiated. For instance, we may wish to connect to a database in the ejbCreate method.
Code samples for stateful session bean using weblogic server:-
Home Interface: chhabi_home.java
import javax.ejb.*;
import java.rmi.RemoteException;
public interface chhabi_home extends EJBHome {
public chhabi_remote create(int var)
throws CreateException,RemoteException;
}
Remote Interface: chhabi_remote.java
import javax.ejb.*;
import java.rmi.RemoteException;
public interface chhabi_remote extends EJBObject {
public int count() throws RemoteException;
}
Bean Class: chhabi_bean.java
import javax.ejb.*;
public class chhabi_bean implements SessionBean {
public int var;
public int count() {
System.out.println("count()");
return ++var;
}
public void ejbCreate(int var) throws CreateException {
this.var=var;
System.out.println("create()");
}
public void ejbPassivate() {
System.out.println("ejbActivate()");
}
public void ejbActivate() {
System.out.println("ejbPassivate()");
}
public void ejbRemove() {
System.out.println("ejbRemove()");
}
public void setSessionContext(SessionContext ctx) {
System.out.println("setSessionContext()");
}
}

Client Program: chhabi_client .java
import javax.rmi.PortableRemoteObject;
import javax.naming.*;
import java.util.Properties;
public class chhabi_client {
public static void main(String a[]) {
try {
Properties p=new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory"
);
p.put(Context.PROVIDER_URL,"t3://localhost:7001");
Context ctx=new InitialContext(p);
chhabi_home home=(chhabi_home)ctx.lookup("chhabi_stateful_jndi");
chhabi_remote r[]=new chhabi_remote[4];
int ct=0;
System.out.println("Bean intialization......");
for(int i=0;i<4;i++) {
r[i]=home.create(ct);
ct=r[i].count();
System.out.println(ct);
Thread.sleep(5000);
}
System.out.println("Calling count method....");
for(int i=0;i<4;i++) {
ct=r[i].count();
System.out.println(ct);
Thread.sleep(5000);
}
for(int i=0;i<4;i++) {
r[i].remove();
}
}catch(Exception e) { }
}
}

The Life Cycle of a Stateless Session Bean
Stateless session beans, like all session beans, are not persistent business objects as are entity beans. They do not represent data in the database. Instead, they represent business processes or tasks that are performed on behalf of the client using them. The business methods in a stateless bean act more like traditional procedures in a legacy transactionprocessing monitor. Each invocation of a stateless business method is independent from previous invocations. Because stateless session beans are "stateless" they are easier for the EJB container to manage, so they tend to process requests faster and use less
resources.
Because a stateless session bean is never passivated, its life cycle has just two stages: nonexistent and ready for the invocation of business methods. Figure illustrates the stages of a stateless session bean.
Code samples for stateless session bean using weblogic server:-
Home Interface: cegonhome.java
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface cegonhome extends EJBHome {
public cegonremote create() throws CreateException,RemoteException;
}
Remote Interface: cegonremote.java
import java.rmi.RemoteException;
import javax.ejb.*;
public interface cegonremote extends EJBObject {
public int xadd(int m,int n) throws RemoteException;
}
Bean Class:
import javax.ejb.*;
import java.rmi.*;
public class cegonbean implements SessionBean {
public int xadd(int m,int n) {
return m+n;
}
public void ejbCreate() throws CreateException {
System.out.println("Create Method");
}
public void ejbRemove() { }
public void ejbActivate() { }
public void ejbPassivate() { }
public void setSessionContext(SessionContext sc) { }
}
Client Program: cegonclient.java
import javax.naming.*;
import java.util.Properties;
public class cegonclient {
public static void main(String a[]) {
try {
Properties p=new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFa
ctory");
p.put(Context.PROVIDER_URL,"t3://localhost:7001");
Context ctx=new InitialContext(p);
cegonhome home=(cegonhome)ctx.lookup("cegon_home_jndi1");
cegonremote rem=home.create();
System.out.println(rem.xadd(100,200));
} catch(Exception e){
System.out.println(e.getMessage());
}
}
}