email article printer friendly get the code more resources

Uncoupling Struts
Use the marker interface design pattern and polymorphism to uncouple your persistence tier from Struts
by Richard C. Murphy

Posted January 21, 2004

Services-oriented architecture (SOA) implies an underlying collection of highly cohesive, loosely coupled components. Although many components claim to exhibit these properties, under close scrutiny some do not exhibit them at all. Tightly bound components pass proprietary recordsets to bound controls creating dependencies between tiers. With the advent of Web services, even language-specific dependencies between tiers can be interpreted as tightly bound. Loose coupling reduces the long-term cost of development by increasing a system's modularity and flexibility. Modularity is a nonfunctional, nonobservable design goal. Flexibility is a nonfunctional, observable system capability. Together, modularity and flexibility support the creation of independent services that enhance reusability of components in SOA.

Here I'll discuss how to uncouple the Struts application framework from the persistence tier of a J2EE application deployed in a Web container. In J2EE application architecture, tiers are logical, not physical subdivisions of a system differentiated by roles and responsibilities assigned to components. Bindings between tiers are created by protocol, package, inheritance, and language dependencies. Although Struts provides an excellent controller component, a tightly coupled Struts decreases component reusability and increases long-term cost of development and maintenance. As application architects, we must loosely couple Struts from the persistence tier to realize the nonfunctional design goals of modularity and flexibility supporting SOA.

Before I demonstrate how to uncouple Struts, let's review three principles of well-designed software and examine in detail the active process of uncoupling. I'll also show how to use the marker interface design pattern (Patterns in Java, Volume 1, Mark Grand, John Wiley & Sons, 2002) along with the object-oriented principle of polymorphism to actively uncouple a persistence tier from a Struts Action class.

Three-Fold Way to Clarity
David Gelernter, in his 1992 visionary book, Mirror Worlds: Or the Day Software Puts the Universe in a Shoebox … How it Will Happen and What it Will Mean (Oxford University Press, 1992), cites three principles of well-designed software that he calls the "Three-Fold Way to Clarity." These three principles are recursive simplicity, espalier, and uncoupling. Gelernter writes "To impose clarity upon complexity through deep and careful design-thinking is the critical achievement of the master programmer." Citing Benoit Mandelbrot, Gelernter describes recursive simplicity as self-similar structures that reuse the same patterns at many scales. Espalier is a simple underlying framework that supports uniform interactions elegantly. Gelernter himself best describes uncoupling. He writes "Uncoupling means to pull a complex problem apart into separate components; solve them separately; minimize the interactions between these separate solutions…. modularity is a passive form of simplification by pulling apart. Uncoupling is the active form."

Based on Apache Jakarta Project's mission statement (see Resources) we know that "… the Struts framework is a flexible control layer …" and that "Struts encourages application architectures based on the Model 2 approach, a variation of the classic Model-View-Controller (MVC) design paradigm." Because Struts provides only the Controller component and "integrates with other technologies to provide the Model and the View," we as application architects must apply best practices to loosely coupling Struts. Over the past 17 years I've witnessed the evolution of application architecture starting with two-tier systems based on client-server, to n-tier systems, all the way through today's SOA. I've had the pleasure of working with dedicated professionals who sought out the best that science and technology could provide for customers.

Yet, as recently as a few years ago I worked in a department where developers tightly coupled the persistence tier with Struts. Developers subclassed Struts Action classes and passed request objects and subclasses of ActionForm to the persistence tier. Passing the request object to the persistence tier created a tight binding between code in the persistence tier and the HTTP protocol. Passing the Struts ActionForm created a tight binding between code in the persistence tier and the Struts application framework. This department has many man-months of refactoring to create highly cohesive, loosely coupled components supporting a modular, flexible SOA. Reusability is low and the cost to change a system is almost as high as replacing the system. Lesson learned; like many technologies that have come before, Struts is no silver bullet!

Now let's turn to how we uncouple the persistence tier from Struts using the marker interface design pattern. However, before I show how to actively uncouple your persistence tier, we'll discuss the marker interface design pattern and the object-oriented principle of polymorphism.