< Zurück | Inhalt | Weiter >

Stateful Session Beans

What they are. A stateful session bean is one that remembers its client be- tween method invocations. It maintains some information between calls from a client. Because of this, a given Bean instance can only handle one client at a time, and if an instance is to be switched between clients, the information about the previous client must be saved so that the client’s session may be restored later.

An application that is designed around stateful session beans will generally require more resources than one designed around stateless session beans (described above) because each active client requires a dedicated instance of the Bean.

Why you would use them. We think we’ve beaten the issue of the advan- tages of stateless beans into the ground. But what are the advantages of a stateful bean?

Many types of client interaction require the bean to “remember” some- thing about the client. The classic (and, by now, almost cliché) example is a Web-based shopping cart application. The remote interface for a stateful ShoppingCart EJB might look something like this:


Creates a new shopping cart for the customer.


Adds an item to the shopping cart.


Removes an item from the shopping cart.


Processes the cart; charges the credit card; generates pick list, shipping list, and invoice; discards cart.


Discards the cart.

Here, items like the identity of the customer and the list of items in the cart must be preserved between method invocations. Obviously, it is possible to present such an interface through a stateless bean by creating some sort of a session identifier token and passing that in to every method, thus allowing the stateless session bean to save this data to a database and then load it back, but the primary advantage of a stateful session bean is that this work is done for you through the setting of the bean’s context.

So, the primary advantage of stateful session beans is that the server side can keep track of client data for you. The primary disadvantage is that the container will try its best to keep an instance of the Bean around for every client, so it must sometimes swap an idle instance out to make room for an ac- tive instance, which is an expensive operation. But—and this is important to keep in mind—it is much less expensive than reading and writing this data on every call to a stateless bean! You have to understand what is happening under the hood if you want to produce an optimal design. If you need state between method calls, a stateful bean is likely to be the most effective way to go. Entity Beans

What they are. An entity bean is often described as an object that represents a row in a database table. This is the most typical case, but it isn’t always so. We have worked on a J2EE application where the entity bean represented an XML document in the filesystem.

The general idea is that enterprise applications tend to work on lists of similar things: customers, employees, locations, accounts, servers, inventory items, and so on. An entity bean is an object that represents a single item in such a list. In other words, it is an interface to a data item. And, yes, in practice there is one entity bean class for a table and one instance of the class for each row.

Obviously, a J2EE container doesn’t maintain an in-memory instance for every row of every table. In fact, you can think of both entity beans and session beans as ways to automate keeping the optimal balance between in-memory instances for speed and data storage for memory utilization.

Entity beans can be written to manage the persistent storage itself, using code added to the bean implementation by the bean author (this is known as bean-managed persistence, or BMP), or they may be written to allow the container to automatically manage the data in the underlying database for you (this is known as container-managed persistence, or CMP). Which you use may

depend many factors, including the databases your container supports, the complexity of your database, the quantity of non-Java clients, or the amount of legacy code.

Entity beans can be a hard sell in many development environments. We can see three strong reasons to resist the use of entity beans.

1. Heterogenous environments. In many enterprises, rich and diverse sets of development environments exist—Windows.NET and ASP clients, mainframe clients, C and C++ applications, third-party applications, and Java. The solution many database environments adopt is to use stored procedures that are shared across all of these platforms to concentrate database access into a common set of code. Stored procedures do not tend to be written with the kind of strict row-to-object mapping that entity beans model so well; instead, they are often designed to support specific business processes. That fits so well with the session bean model that you may be tempted to implement a session bean facade in front of such stored procedures and leave it at that.

2. Legacy code. A variation on the above argument exists when there is al- ready a considerable body of code, perhaps even Java code written directly using JDBC, that accesses the database and performs the common opera- tions. Here again, the simplest solution is to put a session bean facade on the already existing code.

3. Mobile cheese. One of the trendy business books published recently is ti- tled Who Moved My Cheese? and it is about the negative ways in which people react to change. You might very well meet resistance simply because the technology is new and unfamiliar, and represents a change in thinking about data persistence from what the development staff is used to doing.

So, where is it suitable? Entity beans are particularly well suited to environ- ments that are homogenous by being based either mostly on Java or on CORBA/IIOP. Further, they are well suited to environments where the bulk of the work is the editing and manipulation of small numbers of entities per session, as opposed to large reports or statistical queries where a session might want to use many or all rows in a table.

Please note that using entity beans in such appropriate cases in no way precludes other types of use! You just won’t likely use entity beans for them. In other words, you don’t have to use it just because it is there.

One further word. This is by no means an established doctrine, but it seems to be common practice to keep entity beans hidden behind session beans. In other words, it seems to be commonplace to not allow clients (Web applica- tions, Java applications) to communicate directly with entity beans, but rather to have session beans perform all entity bean operations. This is probably be- cause the idea of session beans is to decouple business process from implemen- tation details, and entity beans, no matter how much they hide the underlying database, are still rather tightly coupled to the implementation of the data storage.

Why you would use them. Essentially, they allow you to write your data access layer exactly once, and then reuse it any number times without worrying about capacity and management. Also, by trying to keep the most often used data in fast memory, they can, when running on a powerful container or cluster of containers, keep many client operations running much faster than a strict write-read update back end. Message Beans

What they are. We’re going to gloss over message beans in our book, but you should know what they are. A message bean represents an interface to a message queue. An entity bean represents a transaction where completion of the call tells you the operation has fully completed. A message queue, on the other hand, is an interface where you are given the firm promise that system will get to this when it can. The client doesn’t know where or when the message will be handled. It doesn’t know if it was successful or not. But it does know that it is the problem of the queue reader.

There are many such operations in large enterprises. And there are many products that implement such functionality. Microsoft offers Message Queue Server (MSMQ). IBM has MQSeries. Message queues are common with oper- ations that take time, or need to be batched, or require human intervention.

Why you would use them. Let’s go back to our shopping cart idea. Man- agement might want a daily sales report. You could send each and every item purchased to a message bean. Then a process to read that queue might be kicked off once a day and the report produced without hitting the database that supports all the current Web users. That’s a good example of how a message queue (and thus a message bean) might be used. Again, we’re not going to work with message beans here.