Connecting Stateful Session Beans and JSPs

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.

Architecture for a simple JSP/JavaBean/EJB example. (click to expand)

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 three JSP pages. The first one, index.jsp, is a form where the user submits an integer. This is meant to simulate selecting something from a page to buy, etc. The second, addnum.jsp, is a form where the can either return to select another number, or select the final option for processing the numbers entered so far. The final JSP, final.jsp, displays the sum or product of the numbers entered.

This pageflow is tied together by a JavaBean I call ClientBean that is scoped to live for the entire user session. 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 correct 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 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.

If you enjoyed this article, consider subscribing to my RSS feed or signing up for my free newsletter.

Last Modified: Saturday, 01-Jan-2005 16:06:12 MST