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).
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. |
|
لطفا منتظر باشید ...
