4.2 Understanding the State of a Session Object

Before delving into the details of the example application, it is important to understand the state of a session object. Section 4.2.1 explains how a session bean maintains its state. In particular, it explains the differences between stateful and stateless session beans. Section 4.2.2 describes the conversational state of a stateful session bean.

4.2.1 Stateful versus Stateless Session Beans

You can design a session bean to be either stateful or stateless. An instance of a stateful session bean class is associated with one client. The instance retains state on behalf of the client across multiple method invocations.

Session objects and the stateful instances of the session bean class have a one-to-one correspondence. The EJB container always delegates the method invocations from a given client to the same stateful session bean instance. The instance variables of the stateful session bean class provide a convenient mechanism for the application developer to retain client-specific state on the server.

A stateful session bean typically implements a conversational business process. A stateful instance of a session bean class is associated with an object identity and is bound to a specific client.

In contrast, a stateless session object does not retain any client-specific state between client-invoked methods. The EJB container maintains a pool of instances of the session bean class and delegates a client method invocation to any available instance. It is important to note that the instance variables of a stateless session bean class may not contain any client-specific state when a method invocation completes. The reason is that the EJB container may reuse the instance of the stateless session bean class to service method invocations from a different client.

A stateless session bean typically implements a procedural service on top of a database or legacy application. The service is implemented as a collection of procedures that are bundled into a stateless session bean class. An instance of a stateless session bean class is not associated with any object identity and can be used by any client.

Our example, which we present in detail later in this chapter, uses a session bean, called EnrollmentEJB, to implement a conversational business process. The session bean is implemented as a stateful session bean. The same example uses a different session bean, called PayrollEJB, to implement a procedural service on top of a database called PayrollDatabase. PayrollEJB is implemented as a stateless session bean.

Figures 4.3 and 4.4 illustrate the differences between a stateful and a stateless session bean. In Figure 4.3, obj1, obj2, and obj3 are distributed session objects. Their object type, the EnrollmentRMI type, implements the Enrollment remote interface. The instances inst1, inst2, and inst3 are instances of the EnrollmentBean stateful session bean class. Each session object always delegates to the same instance of the EnrollmentBean bean class.

Figure 4.3. Stateful Session Bean

Figure 4.4. Stateless Session Bean

In Figure 4.4, by contrast, the session object obj is a distributed object. Its object type, the PayrollRMI type, implements the Payroll remote interface. The instances inst1 and inst2 are instances of the Payroll stateless session bean class, and the container keeps them in a pool. The object obj delegates to any available instance of the PayrollBean class. This is in contrast to the Figure 4.3 stateful session bean object, which always delegates to the same instance.

4.2.2 Understanding Conversational State

As noted earlier, a stateful session bean instance keeps the server-side state on behalf of a single client. The instance retains the state across multiple client-invoked methods. Keep in mind that the state consists of

• The instance variables defined in the session bean class

• All the objects reachable from the instance variables

If multiple clients use the same session bean, each client creates and uses its own session object. The session objects do not share state across multiple clients, thus ensuring that each client has its own private application-specific state on the server. The bean developer does not have to synchronize the access to the instance variables of the session bean class.

Because the session bean typically implements a conversation between the user of the application and the application itself, the state retained in the session object is often referred to as conversational state. What information is usually kept in the conversational state? The conversational state typically consists of the following two types of information:

1. Data read from databases The session object reads client-specific data from the database at the beginning of the business process, or the data is read for it by another session or entity object. The session object caches this data in its instance variables for the duration of the business process to avoid multiple database operations. Two examples of client-specific data in our sample application are the employee information and the current employee benefits information. The Enrollment bean reads the employee information first name, last name, department, and so forth and the current benefits information from the respective databases at the beginning of the business process and caches both sets of information for the duration of the user conversation. The Enrollment bean uses the employee information in various steps of the business process and also reads the current benefits information to set the default selections for the multiple-choice options presented to the user.

2. Information entered by the user The session object may keep information entered by the user in a previous step if a subsequent step of the business process requires that information. For example, the Enrollment bean retains the coverage option selected by the user in step 1 and the smoker status entered in step 2, because it must use this information in later steps to calculate the cost of the medical and dental insurance choices.

Why is it important for an application to retain the client-specific conversational state in the session bean instance variables? If the session object could not store a client's conversational state in its instance variables, each client-invoked method on the session object would have to retrieve the state from the underlying database. Fetching data from the database can be expensive, especially if the database is located on a different network node than the application server or if the data requires a complicated database query to retrieve it.

Retaining client-specific state across client-invoked methods is not unique to the session bean or the EJB architecture. For example, Web containers support the concept of session state in which a Web application is allowed to save client-specific state in the Web container. For example, the servlet API supports the ServletContext.setAttribute(String name, Object value) and ServletContext.getAttribute(String name) methods for saving and retrieving client-specific values.

However, using a session bean to implement a conversational business process offers distinct advantages over other approaches.

• A single Java class the session bean class implements a session bean. The same Java class implements both the conversational state and the business methods that access the state. The application developer uses an intuitive paradigm writing a Java class to implement the business process. The instance variables of the Java class hold the conversational state, and the methods of the class are the business methods that can be called by the client.

• The business process is encapsulated in a well-formed session bean component. Both humans and application assembly tools can easily understand the client view of the session bean. Multiple applications can easily reuse the session bean.

• When implemented as a session bean, the business process can be customized at application assembly or deployment, using the enterprise bean environment mechanism. For example, an environment entry could be used to specify whether an Account bean converts local currency amounts to euros.

• The bean developer does not have to be concerned with system-level issues, such as thread management, scalability, transaction management, error recovery, security, and so on. The bean developer codes the session bean as a security-unaware, single-thread, single-user application. The container transparently adds these services to the session bean code at runtime.

The EnrollmentWeb Web application delegates the maintenance of the conversational state to the Enrollment session object. EnrollmentWeb creates this session object at the beginning of the user's conversation with the EnrollmentWeb application and stores its reference in the HTTP session state:

 ... EnrollmentHome enrollmentHome = ...; // get home object from JNDI Enrollment enrollment = enrollmentHome.create(emplNumber); session.setAttribute("EnrollmentBean", enrollment); ... 

EnrollmentWeb keeps the object reference of the Enrollment session object in its HTTP session state.