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
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
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.