Session beans are used to implement business objects that hold client-specific busi- ness 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 exe- cutes 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 behav- ior that doesn’t maintain any specific state. The next section discusses the proper- ties 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 con- versational state is defined as the session bean’s field values plus all objects reach- able 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 busi- ness 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 can- not 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
SESSION BEANS 127
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 shop- ping 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 (cli- ent) 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,Shop- pingClientControlleris 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
RemoteException, DuplicateAccountException; }
Code Example 5.2 ShoppingClientController Remote Interface
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 architec- ture provides ways for a single stateless session bean to serve the needs of many cli- ents. 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 main- tain 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 state- less 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
SESSION BEANS 129
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 repre- sents 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 vari- ous products and categories. Since all users would be interested in such infor- mation, 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 oper- ate on instance variables. Instead they behave like calls in a procedural lan- guage. 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;
int startIndex,int count)throws RemoteException; }
Code Example 5.3 Catalog Remote Interface
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.