Chapter 13. Struts and Enterprise JavaBeans

As you've seen so far, you can use Struts to build both the controller and the view components of an MVC-based application. Struts isn't a framework for business logic or data access, so it doesn't play a key role in the model component. This means that business logic (other than presentation validation) would be out of place in an action or form class. It also means that choosing to use Struts in an application shouldn't place any constraints on the design of the model. The separation of responsibilities in a layered architecture means that your Struts classes shouldn't care about how your model is implemented. Likewise, the model shouldn't care (or even know) that the controller and view are built using Struts.

Up to this point, the example applications presented in this book have used the web tier to provide everything needed from the middle tier, including the business logic and database access. With this approach, the application model has consisted simply of regular Java classes deployed in the web container. These classes have had complete responsibility for servicing requests from the action classes that depend on the application model. This architecture is common among web applications, and it works well as long as the requirements in areas such as security, scalability, and transaction complexity stay within the limits of what a web container can do. Trying to do everything within the web tier can prove to be a challenge when these requirements, which aren't necessarily as high a priority in the design of a web container as they are in other container types, become too stringent.

The alternative to building the model into the web tier is to use a true application tier, such as a J2EE application server. With this approach, the web tier provides the controller and view, and the application tier supplies the business data and its associated rules. Such a design is appropriate when the scalability, security, and transactional needs of an enterprise application require a more robust container. This situation is what we want to consider in this chapter. While it's true that the development of your Struts classes can be independent of the model implementation, this does require some effort on your part. This chapter covers some of the issues you need to consider when developing an interface between your Struts actions and an application tier. In particular, the focus here is on interfacing to a model built using Enterprise JavaBeans (EJB).

To EJB or Not to EJB?

As the J2EE architecture grew in significance for enterprise application development, it was often assumed that an application that didn't include EJB wasn't a J2EE application at all. The rush was on to build enterprise-strength systems backed by EJB containers and all they had to offer. For carefully designed applications that required the type of infrastructure inherent with EJB, the technology provided a standards-based approach that led to many successful deployments. However, the focus on the EJB portion of J2EE also led to its use in applications that could have been better served by more lightweight approaches. This, along with some developers' disappointment with the pace of EJB's evolution, has led to a backlash against using EJB at all. Developers fall on both sides of this issue, with some in the Struts community being quite vocal in their criticism of EJB. The more moderate opinion is that EJB offers value where its strengths are truly needed, but can be costly both in performance and complexity otherwise.

This chapter won't attempt to argue the pros and cons of EJB. That topic falls outside the scope of this book. Instead, we'll simply presume that you've been asked to build a Struts- based web tier that needs to interface with an EJB application tier. With that as a starting point, the main concerns will be to identify the key issues and come up with an effective approach for addressing them.