Home > Articles > Programming > Java

J2EE Session EJB Development

  • PrintPrint
  • Share ThisShare This
  • DiscussDiscuss
Session beans are EJB components designed to perform an action on an enterprise system on behalf of the client. They often serve as the entry points or "frontline" EJBs for EJB clients. EJB clients interact with session beans so that they can obtain the functional behavior and services of the enterprise system that the clients desire want to utilize. In this article, Paul Perrone describes how to create session bean component implementations that adhere to the EJB component-container model contract. This enables the components to operate inside an EJB container and offer their services to session bean clients.
This article contains excerpts from Building Java Enterprise Systems with J2EE.

Stateless Session Beans

Session beans are EJB components designed to perform some action on an enterprise system on behalf of the client. Session beans are often designed to serve as the entry points or "frontline" EJBs for EJB clients. EJB clients interact with session beans to obtain the functional behavior and services of the enterprise system that the clients want to utilize.

Stateless session beans are session beans that are designed to not require the preservation of state within the EJB that is specific to a particular EJB client. This does not imply that the EJB does not actually maintain any state within its fields or associated objects. However, it does imply that the state it maintains is not required to be accessed or utilized for a specific EJB client later. This also implies that the state is not important for access by another client later.

Such a designation gives an EJB container some flexibility in maximizing the efficient management of such EJBs. Because using stateless session bean components implies that any of their instances created by the container can be used by any client at any time, the container can maintain a pool of such instances that are allocated to clients on an as-needed basis without regard to which instance belongs to which client. Containers can also easily create and destroy bean instances as needed, to adjust for scalability and resource demands. Thus, although stateless session beans can have state, no assumptions are to be made by the programmer about the validity of that state between successive uses of the bean instance. EJB containers may create stateless session beans, destroy stateless session beans, and allocate stateless session beans for use as they please.

Stateless Session Bean Logical Component Architecture

Figure 1 depicts the basic architecture involved in creating stateless session bean components.

Figure 1 Stateless session EJBs.

At the top of the figure is the javax.ejb.EnterpriseBean marker interface, which is the base interface for all EJBs. The EnterpriseBean interface is extended by the javax.ejb.SessionBean interface, which is required to be implemented by all session EJB classes. Public, nonfinal, and nonabstract stateless session bean EJBs, such as MyStatelessSessionEJBean, as shown in the figure, must implement the SessionBean interface. Stateless session bean EJBs implement public, nonfinal, and nonstatic business-specific methods, such as someMethod() and anotherMethod(), shown in the figure. Session bean implementations must also have a public parameterless constructor and should not implement the finalize() method.

Stateless Session Bean Interfaces

The setSessionContext() method defined on a stateless session bean is used to pass an instance of a SessionContext object to the EJB. It is also the first method defined in the SessionBean interface that is called by the container. A SessionContext object encapsulates an interface to the EJB session container context.

A key operation required by a custom stateless session bean, such as MyStatelessSessionEJBean, but not defined within the SessionBean interface is the ejbCreate() method. A single ejbCreate() method must be defined on stateless session bean implementations with a void return type. This method is called by the EJB container when the container decides to create an instance of the stateless session EJB. The container may decide to do this when it wants to create an initial pool of bean instances, or it may do this when it receives a client's request. The ejbCreate() method is thus akin to a special type of constructor or initialization method implemented by EJBs.

The ejbRemove() method is called by a container on a session bean object when the container is about to decommission the bean instance from handling any more client requests. For stateless session beans, the container is solely responsible for determining when it will call ejbRemove() on a particular session bean instance. It is not bound in any way to the EJB client.

Because no assumptions are made about the importance of state in a stateless session bean, there is no assumed need to passivate and activate stateless session beans. That is, containers do not assume that a stateless session bean must close any open resources when it is to be removed from active memory (that is, passivated) and do not need to re-create any connections to open resources when brought back into active memory from persistent memory (that is, activated). Thus, the implementations for ejbPassivate() and ejbActivate() methods for stateless session beans are often simple empty implementations.

  • Share ThisShare This
  • Your Account

Discussions

Make a New Comment

You must log in in order to post a comment.

Related Resources

Danny KalevMinutes from the October 2009 Meeting
By Danny Kalev on November 19, 2009 No Comments

The minutes from the Santa Cruz (October 2009) meeting are available here. Even if you're not a language layer at heart, I encourage you to read them.

Danny KalevA Reader's Opinion on Attributes
By Danny Kalev on October 20, 2009 No Comments

In August I dedicated a series to the debate about C++0x attributes. I believe that it covered the subject in a balanced and detailed way, but I keep getting complaints from C++ users who don't like attributes for various reasons. Here's a recent email I received from a Polish C++ programmer. While it  doesn't represent my opinion about attributes -- I'm rather neutral about this feature and consider it a "solution waiting for a problem" -- but it suggests that attributes are still a highly controversial issue that will haunt C++ for a long time. The email is quoted here with minor edits that and as usual, with all private details removed.

Danny KalevFollowup: The Web 2.0 Guy I Ain't
By Danny Kalev on October 16, 2009 1 Comment

Almost a year ago, I posted here The Web 2.0 Guy I Ain't. People wonder whether I still resist all those Web 2.0 features and technologies at the end of 2009.

See All Related Blogs

Informit Network