Introduction

This guideline focuses on identifying Session Beans. Additional guidance on Session Beans is provided in Guideline: Session Bean General guidance on EJBs is provided by Guideline: Enterprise JavaBean (EJB).

Identifying Session Beans

Control classes are often good candidates for session beans, as session beans are geared to providing control logic, in particular when this control logic involves a conversations with a client. A session beans is also often identified as a facade for a set of objects in the Business Tier (see Session Facade Pattern below). Also since J2EE 1.4, stateless session beans can be used to implement web services.

If you are working with J2EE 1.3, a standard practice is to handle all remote client access through session EJBs, which manipulate entity EJBs in the same JVM through local component interfaces.

Modeling Session Beans

See Guideline: Identifying Enterprise JavaBeans (EJBs).

Stateful vs. Stateless

There are two types of session beans: stateful and stateless. Part of identifying a session bean is defining its responsibilities - one of which may be to maintain client state between calls.

Stateful session beans hold state information about the conversation between the client and the EJB container. A stateful session bean instance only exists for the duration of the client conversation. Stateful session beans typically perform services using this data for the client. The services provided by the stateful session bean might coordinate the interactions of other business objects (session beans and entity beans). For example, a shopping cart containing objects for purchase might be implemented using a stateful session bean, because it retains information while the client is interacting with the application. Because stateful session beans are allocated to a specific client, they consume more system resources than a stateless session bean, for the advantage of retaining client state. The container manages these resources, typically by "passivating" (writing to disk) stateful session beans and reactivating them when and as needed.

Stateless session beans don't hold state information about the conversation between the client and the EJB container. "Stateless" really means no client conversation state. Thus, a stateless session bean can contain other kinds of state, such as a database connection that any client can use. Stateless session beans perform generic services that don't use client state data from previous method calls, but instead receive all relevant input as parameters in the current method call, or obtain the data from other sources during the method call (such as from entity beans or by accessing a database via JDBC). Stateless session beans are typically drawn from a ready pool and dispatched as needed to handle incoming requests. Because all instances are equivalent, stateless session beans don't need to know about their client. This can allow for increased performance and scalability. Stateless session beans are more efficient, because an instance can be shared among discontiguous requests, rather than "tied" up with a particular session of activity.

In general, choose the kind of session bean most naturally suited to the conversation with the client. There are strategies to force-fit a stateful session bean into a stateless session bean, such as storing client state on the client, and resending on each invocation, or storing and retrieving client state from a database on each method invocation. These strategies, however, may actually reduce scaleability due to overheads in network traffic and data access.

If the session bean will be created to implement a web service, you must use a stateless session bean as defined in the JSR 1.3 API specification.

Different approaches to designing client state is covered by Guideline: Designing State for J2EE Applications.

Session Facade Pattern

A common use of session beans is as a facade that encapsulates interactions between objects in the Business Tier. The session bean serves to abstract this complexity, providing a simpler interface for clients. This pattern is described in detail in J2EE Patterns - Session Facade Pattern ([ALU01]).

For example, it is generally good practice to pull out inter-entity bean logic and move into session beans to minimize coupling between entity beans. The entity beans can be accessed via local interfaces, as the session bean facade provides access to remote clients. This approach is most effective when there are several closely related entity beans.

Web Services Endpoint

As we have seen previously, stateless session beans can be used to implement web services.Such bean is also called Service Implementation Bean and need to fill the following requirements:

• It must have a default public constructor.
• It must implement all the methods declared by the Service Endpoint Interface and its business methods must be public and not final or static.
• It must be stateless.
• The class must be public, but not final nor abstract.

For more information about using session beans to implement web services, please see EJB 2.1 and JSR 109 specifications.