All things considered, these are relatively simple changes to make, and have the net effect of making your bean faster, more efficient, and only marginally harder to use.

However, as I mentioned, there are times when the changes to the bean's remote interface are more difficult. Passing in a username or any other piece of data ten, twenty, or more times to a bean's methods can result in pain for the developer, and less-clear code. In these cases, a simple helper class on the client can make a stateless session bean behave just as a stateful one did. Example 8-10 shows this principle in action, detailing the AccountManagerHelper utility class.

Looking at the methods available on this helper class, you should realize pretty quickly that it mirrors the remote interface of the AccountManager session bean; however, it looks like the stateful bean version, rather than the new stateless version. The constructor for the class then takes the place of the old stateful bean's create( ) method from the home interface. This class then maintains a bean instance, the username for the manager, and delegates to the session bean. All of the same exceptions are passed through to the client, so the interface is very similar; the only difference is that context lookups are handled within the helper class. This makes the client code even simpler, as this code fragment shows:

You may find that helper classes like this can simplify your own client code, even if you don't need to provide stateful session bean masquerading, where a stateless bean is made to look like a stateful one. In any case, this approach provides the best of both session bean types: the performance of a stateless bean with the interface of a stateful one. This technique will allow you to convert all of your application's stateful session beans into stateless ones, which will yield some dramatic performance improvements.

What's Next?

You now have the tools to build the back-end of almost any enterprise application you may come across, and apply your knowledge to most of the problems you will encounter in the enterprise Java space. In the next chapter, though, I want to move beyond the basics into the less-used realm of the Java Message Service (and specifically, message-driven beans). Although it is still somewhat unusual to see these kinds of beans in action, you will find that JMS offers several attractive features. I'll detail these and how they can help in asynchronous tasks in the next chapter, which focuses specifically on messaging in enterprise applications.

Brett McLaughlin
had developed enterprise Java applications for Nextel Communications and Allegiance Telecom. When that became fairly mundane, Brett took on application servers. He then got hooked on open source software, and helped found several cool programming tools, like Jakarta turbine and JDOM.