5.5 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 sections discuss the properties and uses of both stateful and stateless session beans.

5.5.1 Stateful Session Beans

A stateful session bean contains conversational state on behalf of its client. The 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.

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 usually cannot be shared among multiple clients.

• Representing non-persistent objects

Stateful session bean state is not stored in persistent storage and cannot be recreated after the client's session with the server ends. Therefore, business objects that are relatively short-lived and non-persistent--whose state must only be maintained for one entire session--should be modeled as stateful session beans. If a stateful session bean needs to save persistent state beyond its own lifetime, it should make use of one or more entity beans for this purpose.

A shopping cart object represents the collection of products selected by a particular customer for purchase during a session. The contents of the shopping cart are specific to a particular customer session and need not be saved unless the customer 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 customer and is alive only for the customer's session with the server. The sample application models the concept of shopping cart as a local stateful session bean. As shown in Code Example 5.3, ShoppingCartLocal provides ability to add and delete items to the shopping cart.

public interface ShoppingCartLocal extends EJBLocalObject {
	public void addItem (String itemID);
	public Collection getItems (Locale locale);
	public void deleteItem (String itemID);
	public void updateItemQuantity (String itemID, int newQty);
	public void empty ();
}

5.5.2 Stateless Session Beans

Stateless session beans are designed strictly to provide server-side behavior. The term stateless means that the session bean does not maintain any state information for a specific client. This means that all stateless session bean instances are equivalent when they are not involved in serving a client-invoked method. However, stateless session beans can have non-client specific state, for example, an open network or database connection.

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 across method invocations, so the same bean instance can be reused to service other clients. For example, in the sample application, the SignOn bean validates a customer 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 may have to perform the state management functions.

• 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. If a business object exhibits such functionality then it should be modeled as a stateless session bean. For example, a stateless session bean can provide facade methods that hide the operations of multiple entity beans behind it.

The sample application uses a stateless session bean 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.4 lists the services provided by the catalog object:

public interface CatalogLocal extends EJBLocalObject {
	public Page searchItems(String keywords, int start, int count, 
Locale l);
	public Category getProduct(String productID, Locale l);
	public Page getProducts(String categoryID, int start, int count, 
Locale l);
	...
}