5.4 Session Beans

Session beans are used to implement business objects that hold client-specific business logic. The state of such a business object reflects its interaction with a particular client and is not intended for general access. Therefore, a session bean typically executes on behalf of a single client and cannot be shared among multiple clients. A session bean is a logical extension of the client program that runs on the server and contains information specific to the client. In contrast to entity beans, session beans do not directly represent shared data in the database, although they can access and update such data. The state of a session object is non-persistent and need not be written to the database.

A session bean is intended to be stateful. However, the Enterprise JavaBeans specification allows stateless session beans as a way to provide server-side behavior that doesn't maintain any specific state. The next section discusses the properties and uses of both stateful and stateless session beans.

5.4.1 Stateful Session Beans

A stateful session bean contains conversational state on behalf of the client. A conversational state is defined as the session bean's field values plus all objects reachable from the session bean's fields. Stateful session beans do not directly represent data in a persistent data store, but they can access and update data on behalf of the client. As its name suggests, the lifetime of a stateful session bean is typically that of its client.

5.4.1.1 Uses of Stateful Session Beans

A Bean Provider can use the following session bean characteristics as guidelines when deciding whether to model a business object as a stateful session bean:

• Maintaining client-specific state

Stateful session beans are designed to maintain a conversational state on behalf of a client, therefore business objects representing client-centric business logic should be modeled as stateful session beans. Since stateful session bean instances are tied to a client, system resources held by stateful session beans cannot be shared among multiple clients.

• Representing non-persistent objects

Stateful session bean state is not stored in the persistent storage and cannot be recreated after the client's session with the server is over. Therefore, business objects that are relatively short-lived and non-persistent should be modeled as stateful session beans. In other words, a business object that does not need to live after a client's session with the server is over, or be present when the server comes back after a crash, should be modeled as a session bean.

• Representing work flow between business objects

The business objects that manage the interaction of various business objects in a system are excellent candidates to be modeled as stateful session beans. Such objects usually exhibit both of the above characteristics, since they are client specific and represent data-neutral non-persistent behavior.

5.4.1.2 Example: A Shopping Cart Bean

A shopping cart object represents the collection of products selected by a particular user for purchase during a session. The state of the shopping cart object is specific to a particular user session and need not be saved unless the user is ready to place an order. The shopping cart object is short-lived. The data should not be shared, since it represents a particular interaction with a particular user and is alive only for the user's session with the server. The sample application models the concept of shopping cart as a stateful session bean.

As mentioned earlier, stateful session beans can also be used to model an object that manages the interaction of various objects in the work flow on behalf of a client. The sample application follows the MVC architecture. If the view (client) needs to read the data (model) it does it by directly interacting with the data. However, if the view needs to update the data, it uses the controller as a mediator. The controller interacts with multiple objects representing data on behalf of the view or user.

In the sample application, the controller is implemented as a stateful session bean named ShoppingClientController. As shown in Code Example 5.2, ShoppingClientController is responsible for managing the life cycle of model objects such as the shopping cart and account enterprise beans and processes business events. For example, when a user places an order, ShoppingClientController handles the order event.

public interface ShoppingClientController extends EJBObject {
	public Catalog getCatalog() throws RemoteException;
	public ShoppingCart getShoppingCart() throws RemoteException;
	public Account getAccount() throws RemoteException;
	public Collection getOrders() throws 
		RemoteException, FinderException;
	public Order getOrder(int requestId) throws 
		RemoteException, FinderException;
	// Returns a list of updated models
	public Collection handleEvent(EStoreEvent se) throws 
		RemoteException, DuplicateAccountException;
}

5.4.2 Stateless Session Beans

Stateless session beans are designed strictly to provide server-side behavior. They are anonymous in that they contain no user-specific data. In fact, the EJB architecture provides ways for a single stateless session bean to serve the needs of many clients. This means that all stateless session bean instances are equivalent when they are not involved in serving a client-invoked method. The term stateless means that it does not have any state information for a specific client. However, stateless session beans can have non-client specific state, for example, an open database connection.

5.4.2.1 Uses of Stateless Session Beans

A Bean Provider can use the following session bean characteristics as guidelines when deciding whether to model a business object as a stateless session bean:

• Modeling reusable service objects

A business object that provides some generic service to all its clients can be modeled as stateless session beans. Such an object does not need to maintain any client specific state information, so the same bean instance can be reused to service other clients. For example, it would be appropriate to model a business object that validates an employee ID against a database as a stateless service.

• Providing high performance

A stateless session bean can be very efficient as it requires fewer system resources by the virtue of being not tied to one client. Since stateless session beans minimize the resources needed to support a large number of clients, depending on the implementation of the EJB server, applications that use this approach may scale better than those using stateful session beans. However, this benefit may be offset by the increased complexity of the client application that uses the stateless session beans because the client has to perform the state management functions.

• Operating on multiple rows at a time

A business object that manipulates multiple rows in a database and represents a shared view of the data is an ideal stateless session bean. An example of a such business object would be a catalog object that presents a list of various products and categories. Since all users would be interested in such information, the stateless session bean that represents it could easily be shared.

• Providing procedural view of data

In a procedural view of data, methods of the business object do not operate on instance variables. Instead they behave like calls in a procedural language. The method caller provides all the input and the method returns all output to the caller. If a business object exhibits such functionality then it should be modeled as a stateless session bean.

5.4.2.2 Example: A Catalog Bean

The sample application uses a stateless session beans to model a catalog object. A catalog object represents different categories and products and provides browsing and searching services to its clients. Both of the primary functions of the catalog, browsing and searching, are generic services that are not tied to any particular client. Also, the catalog object operates on multiple rows in the database at the same time and provides a shared view of the data. Code Example 5.3 lists the services provided by a catalog object:

public interface Catalog extends EJBObject {
	public Collection getCategories()throws RemoteException;
	public Collection getProducts(String categoryId,
		int startIndex, int count)throws RemoteException;
	public Product getProduct(String productId)
		throws RemoteException;
	public Collection getItems(String productId,int startIndex,
		int count)throws RemoteException;
	public Item getItem(String itemId)
		throws RemoteException;
	public Collection searchProducts(Collection keyWords,
		int startIndex,int count)throws RemoteException;
}

Another example of a stateless session bean is the mailer object used to send confirmation mail to clients after their order has been placed successfully. Mailer provides a generic service that can be completed within a single method call with its state is not tied to any particular client. Also, since the instances can be shared among multiple clients, they are modeled as stateless session beans.