Session Beans in EJB 3.0
(Page 1 of 4 )
Enterprise applications revolve mostly around three aspects of data: transfer of data, retrieval of data and transformation of data by applying the business rules of a particular organization. Since these three aspects are specific to an organization, Enterprise Java Beans (EJB) are known as Business Specific Components. Even among the three aspects, the former two are more generic in nature whereas the latter is closer to the policies of a given organization.
That's why Session Beans are more concerned with logic to implement the business rules rather than the retrieval or transfer of data. In this discussion the focus will be on Session Beans. The first two sections would be about the types of Session Beans and their differences. In the third section I will detail the steps involved in implementing both types of Session Beans. The final part will put theory into practice by designing a Session Bean and the relevant deployment descriptors. That is the agenda for this discussion.
More About Session Beans
By definition "A session bean represents a single client inside the Application Server." In other words, a Session Bean represents a user's conversation with the business task implemented within an Application Server. To be more precise, Session Beans are reusable components that contain logic for business processes that perform work on behalf of client code that is calling it. Whenever the context of discussion is EJB, two aspects always come into focus which are:
- Lifetime
- Sub-types
Understanding the lifetime becomes necessary to understanding the Session Bean sub-types. The following are the details.
An instance of a Session Bean does a task on the behalf of the client. That means it is an extension of the client on the server side. Hence as long as the client is present, the instance of that particular Session Bean remains alive. The period between the client accessing an instance of Session Bean and the client calling a remove on the instance is known as a Session or Conversation. The state of an instance of a Session Bean during a Conversation is referred to as the Conversational State. To make a long story short, the lifetime of a Session Bean instance is roughly equivalent to the session of the client.
There are two main aspects of lifetime that must be kept in mind. First is that a single instance of a Session Bean is never shared between different clients. Hence the length of a Session or Conversation is determined by how long the Bean instance has been in use. Secondly, the container is in total control of the life cycle of a Session Bean's instance. So if a timeout occurs, the container can remove the instance. In a nutshell, they are in-memory objects that live and die with the container or surroundings. From this one can conclude that Session Bean instances are non-persistent i.e. their state is not saved into persistent storage such as a file system or a database. Keeping these points in mind, let's move on to the sub-types of the Session Bean.
As stated earlier, the sub-types of Session Beans are based on the lifetime or Conversational state of the Bean. So what happens during a Conversation between a client and an instance of a Bean? A Conversation is composed of a number of method calls between the client and the bean. Simply put, when a conversation is going on, the client calls the business methods exposed by the Bean instance. The difference in sub-types of Session Bean springs from the difference in the saving of the Conversational State i.e. whether the result of previous conversations is saved or not. On the basis of this difference there are two sub-types of Session Beans, Stateless and Stateful. The state in both types refers to the Conversational State.
A Stateless Session Bean can be defined as "A bean that holds conversations that span a single method call." Put differently, a Stateless Session Bean does not save its Conversational State. The container may choose to destroy the instance itself once the conversation is over or it may reuse the instance for some other client request. Whatever the strategy, the bean instance forgets the result it has calculated/computed for the previous client.
An example of a use for the statelessness of a Stateless Session Bean is the verification of a credit card number. The client supplies the bean instance with the credit car number, expiration date, card holder's name and the input amount. The bean returns yes or no based on the validity of the holder's credit card. Once the result has been given to the client, the bean "forgets" all the supplied information. So for the next client the bean is, in essence, a new instance.
Another issue that arises with beans is pooling. With Stateless Session Beans, all instances of the same bean are equivalent and indistinguishable to a client. So any bean instance can serve any client as they are all same. This in turn means that "Stateless Session beans can be pooled, reused, and swapped from one client to another client on each method call."
Next: Stateful Session Beans >>
More Java Articles
More By A.P.Rajshekhar
