Note: This example has been updated. See this essay on connecting stateful session beans for the most recent description.

In my class on large scale distributed systems, we've been talking about enterprise java beans. The question at this point (since they're starting on their project) is how to implement a system so that session state is maintained across multiple JSP pages and inside an associated stateful session bean. Since I've not been able to find many great examples that show how to put it all together, I wrote one today and I thought I'd share it here.

Here's the problem set up. You want to create a web application using JSPs and stateful session beans so that a user can browse multiple screens, making selections from each screen and when finished, use all of that information to perform some calculation. Obviously a shopping cart is a perfect example of this pattern, as are things like selecting classes from a course catalog, reserving seats to a sporting event, and so on. Its easy to see how to implement a stateful session bean (SSB) to do this, but how do you tie the JSP pages to the SSB and maintain context. The answer is a JavaBean on the servlet engine (I call this the ClientBean) that the JSPs can use to maintain their state in between invocations. The ClientBean also maintains the reference to the SSB on the EJB container.

The picture to the right shows the simple example I wrote to illustrate the technique. The example uses XDoclet to deploy on jBOSS. The example has four JSP pages. The first one is a form where the user submits an integer. The second is a form where the user submits a second integer. The third is a form where the user submits two more integers. The final JSP displays the sum. The ClientBean creates the SSB in the container and stores a reference to its remote interface when the ClientBean is initialized. Then as each JSP is loaded and the parameters processed, the accessor functions (setters) in the ClientBean store the form inputs into the SSB. The final JSP calls the process function on the ClientBean which merely invokes the business logic in the SSB and returns the result.

The SSB in this example is obviously contrived, but it illustrates the idea. In real life, the SSB could be using entity beans to update the database and process complex business logic. Also, its not always the case that the ClientBean acts so neatly as a mere servlet side proxy for the SSB in the container---this example is merely meant to display the general technique. The data being passed around in this case is fairly simple (integers). For more complex data, you'd want to use the data transfer object pattern to avoid multiple remote calls.

Note that the overall session state is maintained through the cooperation of multiple entities. The container is keeping the SSB around until its removed (or times out) because its declared to be "stateful." The ClientBean is sticking around because it was created in a JSP with its page scope set to "session." Because the ClientBean persists the reference it hold back to the SSB can be used to keep hold of the state stored there. Each JSP accesses that state through the ClientBean. Its a complex dance, but the end result works.