ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button O'Reilly Book Excerpts: Building Java Enterprise Applications, Vol I: Architecture

Business Logic, Part 3

Related Reading

Building Java Enterprise Applications
By Brett McLaughlin

by Brett McLaughlin

This is the final part of an extended excerpt from Chapter 8 of Building Java Enterprise Applications, Vol I: Architecture. This installment focuses on issues of statefulness and statelessness. The second article looked at the UserManager component. The first installment covered the facade pattern, a way to use session beans to access entity beans, and introduced the officeManager component.

State Design

Continuing on with the Forethought business logic, I want to spend some time on the issue of stateful versus stateless beans. I refer to it as an issue because it almost always manages to come up when working with session beans, and can have a drastic effect on your application's performance. Specifically, stateless session beans are much more efficient than stateful session beans.

For a more detailed discussion on the issue, you can check out Richard Monson-Haefel's Enterprise JavaBeans, which spends a great deal of print on how a container handles these two kinds of beans. However, I'll briefly sum up the relevant portions here. A stateless session bean is a very lightweight bean, as it needs to carry around only EJB-mandated variables, and not programmer-defined ones. As a result, most containers have pools of stateless beans. Because no single client needs to have access to a specific stateless bean instance (no state is being kept, remember), a single instance can serve two, three, ten, or even a hundred clients. This allows the bean pool to be kept small, and negates a frequent need to grow or shrink the pool, which would take valuable processor cycles.

A stateful bean is just the opposite: an instance is tied to the client that invoked its create( ) method. This means that an instance must exist for every client accessing the stateful bean. Therefore, the bean pools must be larger, or must frequently be grown as more requests come in. The end result is longer process times, more beans, and fewer clients being served. The moral of this technology tale is that if at all possible, you should use stateless session beans.

The following sections demonstrate these principles, and specifically how a bean that appears to be a better stateful bean can easily be converted into a stateless one. This should provide you with some good ideas about state design and some handy tips on how to convert your own stateful beans into stateless ones.

Starting Stateful

Take the case of an AccountManager bean that will handle a single user's accounts. For this exercise, I'll keep the methods required for the bean simple. Example 8-7 shows the remote interface for this bean.

Example 8-7: The AccountManager Remote Interface

package com.forethought.ejb.account;
import java.rmi.RemoteException;
import java.util.List;
import javax.ejb.EJBObject;
// Account bean
import com.forethought.ejb.account.AccountInfo;
// AccountType bean
import com.forethought.ejb.accountType.UnknownAccountTypeException;
public interface AccountManager extends EJBObject {
    public AccountInfo add(String type, float balance)
        throws RemoteException, UnknownAccountTypeException;
    public AccountInfo get(int accountId) throws RemoteException;
    public List getAll(  ) throws RemoteException;
    public AccountInfo deposit(AccountInfo accountInfo, float amount)
        throws RemoteException;
    public AccountInfo withdraw(AccountInfo accountInfo, float amount)
        throws RemoteException;
    public float getBalance(int accountId) throws RemoteException;
    public boolean delete(int accountId) throws RemoteException;  

As you can see, the manager operates upon a single account for a single user. This allows a client to simply pass in the user's username one time (using the create( ) method), and worry about details of the account independently of keeping up with a username. Example 8-8 shows this method in the manager's home interface.

Example 8-8: The AccountManager Home Interface

package com.forethought.ejb.account;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
public interface AccountManagerHome extends EJBHome {
    public AccountManager create(String username) 
        throws CreateException, RemoteException;

This provides a means to create a new account or to find all existing accounts for a given username. Because the bean is keeping up with the account's user and the account's ID, both required for entity bean interaction, the bean must be stateful. That is, since each individual method uses the data, this information must be kept in the bean instance between requests. For a better understanding of these details, review the bean's implementation code in Example 8-9 on the next page.

Pages: 1, 2, 3

Next Pagearrow