Session beans

Session beans are the most commonly used of the Enterprise JavaBeans (EJB). Their popularity has grown even more in recent years due to the market shift toward Service-Oriented Architectures (SOAs).

Organizations wanting to implement SOAs built on the Java platform but not necessarily Web Services are exposing business services using stateless session beans.

Session Beans Overview

Session beans are a critical part of the J2EE 1.4 specification. They are the distributed server-side business components that expose the business logic to the Web Tier and Client Tier typically through service-oriented interfaces.

Session beans can also be used to hide the details or aggregation of legacy systems in the Enterprise Information Tier. Often session beans are used in a common J2EE design pattern called the Session Façade. The goal of the Session Façade pattern is to wrap fine-grain access, commonly to entity beans into coarse-grain access to reduce network traffic and improve performance.

The details of the Session Façade pattern are explained in the "Session Façade Pattern" sidebar.

Session beans come in two types: stateful and stateless. Stateful session beans maintain conversational state across methods calls. Therefore, each stateful session bean is dedicated to a single client and is not pooled by the application server.

An example of a stateful session bean would be a shopping cart that remembers what has been added to the cart between calls.

Due to the overhead of managing state, stateful session beans are not known for their performance and are seldom used. A stateless session bean, on the other hand, does not maintain state between calls and requires the state to be passed to the bean as parameters with each call. Because the stateless session beans contain no state, multiple clients can reuse the same bean instance.

This enables the beans to be pooled by the application for better performance. Both stateful and stateless session beans have an implementation class referred to as the bean. Then depending on whether the session bean is exposing functionality to a remote client (client in another JVM) or a local client (client in the same JVM), the session bean requires some additional interfaces.

If the session bean is exposing functionality to a remote client, it requires a remote interface.

This is an interface that extends javax.ejb.EJBObject.

The remote interface typically has the same method signatures of the business methods the bean class wants to expose with one caveat: each of the methods must throw the java.rmi.RemoteException.

This notifies the client developer that something could happen in the process of interacting with the remote server and he or she should handle it appropriately.

A remote interface also requires a home interface. The home interface exposes one or more create methods for getting a reference to the remote session bean.

The home interface must extend java.ejb.EJBHome. A home interface for a stateless session bean may only have a single create method that passes no parameters. A stateful session bean, on the other hand, may have multiple create methods and can optionally include parameters to set up the initial state.

The home interface must be looked up via JNDI. The JNDI lookup returns a application server–specific proxy implementation that implements the home interface.

Exposing functionality to a local client follows the same pattern as exposing functionality to a remote client. You have both a home interface referred to as a local home and a service interface referred to as a local interface. The local home interface must extend the javax.ejb.EJBLocalHome interface, while the local interface must extend the javax.ejb.LocalObject interface.

One other difference besides the inheritance between remote and local is that local interfaces do not require the remote exception to be thrown. A session bean can support both a remote and local interface at the same time. If it does, that is a minimum of five files that must be kept in sync.

Add to that the standard EJB deployment descriptors and possible application server–specific deployment descriptors and that is a lot of files. This is one of the reasons J2EE development is considered complicated.

Plenty of other documents can be found at oxxus.net java wiki