Web-Tier Design Goals

Enough negatives: what features should a good web interface have? The following two goals are central to maintainability and extensibility.

A Clean Web Tier

As JSP Model 1 experience shows, a web app is doomed to failure if markup generation is inextricably mixed with control flow and business object invocations.

Important

A clean web tier separates control flow and the invocation of business objects (handled by Java objects) from presentation (handled by view components such as JSP pages).

Java classes should be used to control flow and initiate business logic. Java classes should not be used to generate markup. It should be possible to change presentation markup without modifying Java classes. JSP pages - or whatever templates are used - will contain only markup and simple presentation logic. This permits an almost complete separation of Java developer and markup author roles.

A Thin Web Tier

However, achieving a clean web tier is not enough. It's also vital to ensure that the web tier is as thin as possible. This means that the web tier should contain no more Java code than is necessary to initiate business processing from user actions, and display the results. It means that the web tier should contain only web-specific control logic (such as the choice of the layout data should be displayed in) and not business logic (such as data retrieval). Why is this so important? apps in which business logic is tied to the webtier - even web tier Java objects such as servlets, rather than JSP pages - fail to meet the goals we identified in . Such apps:

Are hard to test – a very important consideration. Testing web interfaces is much harder than testing ordinary Java objects. If we expose business objects as JavaBeans implementing well-defined interfaces, we can easily write test harnesses that test business logic in isolation from any user interface. In apps in which business objects expose well-defined interfaces, testing the web interface is a comparatively simple problem of checking that the interface correctly translates user actions into the correct business requests and correctly displays the results. If an app's web tier contains business logic, we can only test the business logic through testing the web interface as a whole, which is likely to be much harder.
Reduce potential to reuse business logic code, even within the same web app. Code in a servlet's service() method, for example, won't be available even to other servlets.
Are likely to prove vulnerable to changes in web interface workflow (although not necessarily to changes in presentation). If we have a distinct layer of business interfaces, we can easily run regression tests at any time. If some of our business logic is in the web tier, it's likely that changing the workflow will introduce bugs. Tests against the web interface will need to be rewritten to reflect the changed workflow, making testing the new workflow problematic.
Aren't pluggable. If we expose business operations in a layer of business interfaces, we can easily change the implementing class of one or more business objects without affecting calling code (assuming we have a framework that facilitates interface-based design, like the one I discussed last chapter). If business operations are tied to the web tier, there's unlikely to be such a straightforward way to change implementation.
Make it hard to expose an interface other than a web GUI, such as a web services interface.

Important

In a well-designed J2EE app, the web tier should be a thin layer built on well-defined business interfaces. It should be responsible only for translating user actions into app events, and the results of processing user input into results displayable by the web interface.

This point deserves to be emphasized. Although a thin web tier is as important as a clean web tier, the relationship between web tier and business objects seems to get far less attention than the MVC approach to ensuring a clean web tier.

Previous Next

Comments