W R I T E   A N D   D E P L O Y   J 2 E E   A P P L I C A T I O N S  

Session Beans 

Session Beans represent business objects and offer its functionality. As example a bank's 

customer Enity Bean delivers information like id, address, number of accounts but the 

customer Session Bean offers services like to create a new type of account for this customer, 

transfer money between accounts of this customer etc. 

Session Beans contain the business logic and uses Entity Beans to retrieve and store data 

persistently. 

A Session Bean contains an  ejbCreate()  method where no parameters are allowed. This is 

due to the fact that even when a client calls the  create()  method on the Home interface it 

does not mean automatically that a Session Bean instance is created. It is up to the 

application server to decide when to create a new instance and when to pick one from a pool 

of inactive Session Beans. The next method is the  ejbRemove()  which is called by the 

application server when the Session Bean is destroyed and not automatically when the 

client calls  remove()  on this instance because the application server can put this instance 

in the instance pool. Finally there are the methods  ejbPassivate()  and  ejbActive  which 

are called just before the bean is made persistent from the pool or recreate and put into the 

pool. This allows the bean developer to close or reopen used resources. 

Because the application server can use advanced features to manage and pool Session Beans 

the client should hold on them as brief as possible. This means you should create a Session 

Bean just before you use it and should remove it afterwards. It is bad programming practice 

to keep a reference to a Session Bean for a unnecessary long time like for example as a 

member variable in the client program. The length of this period is naturally much longer 

for Stateful Session Beans than for Stateless Session Beans. 

But it is ok to keep the Home interface as a member variable with the exception that you 

have to be prepared that in a hot redeployement this Home interface is not available 

anymore and a new copy has to be looked up on the JNDI server. 

Stateless Session Beans 

Stateless Session Beans (SLSB for short) do, as the name implies, not maintain any state 

between calls. This means that one client could call a SLSB and afterwards another client 

could call the same or another method on the same SLSB. Note that this does not mean that 

a SLSB cannot store informations like various Home interfaces of Enity Beans it is using 

but they must not be assigned to a particular call or client. 

The advantage of a SLSB is that the application server can easily balance the number of 

SLSBs because the assignment to a client is limited to the call. So even there are thousands 

47