What Is a Session Bean?

In Chapter 5, "Entity Beans," you were introduced to the first type of enterprise bean. This chapter introduces you to the second type, the session bean. Just as entity beans have a purpose in manipulating persistent data, session beans have a purpose in executing business logic on behalf of a client. In fact, you can think of a session bean as an extension of a client. The EJB architecture provides to session beans the same transactional, security, and concurrency support given entity beans. This allows clients to execute reusable business logic running in an application server to do transactional work. The container takes care of the low-level details, so the session bean and client application developers can focus on the application logic they need to implement without worrying about the infrastructure.

A client for a session bean can be a remote client, such as a servlet, a CORBA client, or another enterprise bean deployed in a different container. Just like an entity bean, a session bean can also support an enterprise bean deployed in the same container as a local client.

Typically, you'll design your applications so that entity beans only have other EJBs for clients (session beans mostly). It's your session beans that you'll most often expose to the non-EJB clients of your application. As an example, a banking application might use entity beans to represent customers and their accounts and session beans to perform any work related to them. A request to transfer funds between a customer's savings and checking accounts could be handled by a session bean method that makes the necessary updates to the two entity objects representing the accounts. All the logic related to account transfers would be executed within the application server where the corresponding security and transactional concerns could be managed transparently to the client. Session beans are a good place to implement an application's workflow logic.

Because entity beans typically are accessed only by other enterprise beans, their clients are most often local clients. The nature of session beans makes it more likely for them to be used by remote clients. This is because their behavior is often an extension of the client applications that access them.

Just like an entity bean, a remote client interacts with a session bean through the bean's remote interface. Conceptually, a session bean object that serves a remote client is implemented in the container by an EJBObject , which implements the session bean's remote interface. When a client invokes a method on a session bean, the EJBObject executes on behalf of the client and delegates the method call to an instance of your session bean class. In the case of a local client, an EJBLocalObject that implements the bean's local interface delegates calls to a bean instance. Because calls to a session bean instance are always intercepted by the container, the container is able to handle security, transactions, concurrency, and other lifecycle services for the bean.

Describing a Session Bean

A session bean exhibits the following characteristics:

• It supports transactions.

• It executes on behalf of a single client.

• It's relatively short-lived compared to an entity bean.

• It doesn't represent data in a database, although it can access shared data on behalf of a client.

All enterprise bean types support transactions, but the other characteristics just listed for session beans set them apart from entity beans. When multiple clients want to access the same entity bean object, the container uses a single instance of the bean class to service their requests. The requests are serialized so that each client call waits in line to be serviced. A session bean, on the other hand, is activated by the container for the purpose of serving a single client. You'll see more of how the container manages this behavior when the two types of session beans are described in the next section.

An entity bean represents long-lived persistent data and the container can regenerate a particular entity object in the event of a system restart (either an intentional one or after a crash). A session bean instance is instead intended to serve the needs of its client and then go away. What this really means is that any state associated with that client goes away and the instance is placed back into the object pool ready to be used for a different client.

The final point to address here describes the relationship between session beans and the database. Unlike entity beans, the state held by a session bean doesn't correspond to data held in a database or other persistent data store. However, it's common for a session bean to indirectly modify persistent data by calling methods on entity beans. You'll also find it useful to perform read-only database access directly from session beans. With this as an option, you don't have to limit yourself to using entity beans for all your database access.