Loose Component Coupling

One of the reasons for JSP applications to follow the MVC pattern is that this pattern encourages distinct, clearly defined roles for model, view, and controller components. You should keep these components as loosely coupled as possible. However, you should not keep the CustomerServlet loosely coupled, because it encodes specific workflow states and hard codes the names of specific JSP pages.

Tight coupling between the controller and view components means that changes to one component demand corresponding changes to the other component. In this case, if you add additional JSP pages to the shopping workflow, you must add additional conditions to the CustomerServlet program logic. Alternately, the CustomerServlet forces you to give specific names to the JSP pages.

This sample application would be more maintainable and more scalable if you could remove the tight coupling between the CustomerServlet and its JSP pages. One way to minimize this close coupling would be to create a helper bean for each JSP page. You can install these helper beans in the CustomerServlet to manage all HTML requests directed at the associated JSP page. Such encapsulation of each request in a request handler object illustrates the command pattern. As with the bridge pattern, the key to implementing a command pattern is to declare a common interface that each request handler must implement. In this case, the simplest form of such an interface might be a single method, such as redirect(), into which you pass the request parameter and the BasketBean object. Because every concrete implementation of the interface supports this method, the CustomerServlet can invoke the interface on any given handler without knowing anything specific about its implementation (see Figure 7.6)^[1].

Figure 7.6: The command pattern helps decouple request managers from request handlers.

You can customize each helper bean for its partner JSP page and make it as complex as necessary. For example, it can validate input parameters passed in the request, whether by simply guaranteeing nonblank entries or by performing more complex tasks such as verifying credit card information.

If you adopt the helper bean architecture, then you might wonder how you install the bean. After all, although the JSP framework translates JSP pages into servlets at runtime, JSP pages are just files until the framework translates them. It’s a kind of chicken-and-egg problem.

A JSP page has exactly one input point, but it could have multiple outputs based on the number of submit buttons. Each output could be associated with a different JSP page. For instance, Inventory.jsp has two outputs, one for Purchase.jsp and one back to itself. You could associate a helper bean with each output point using a hidden tag.

Finally, the JavaServer Pages extend servlet technology in useful ways. By supporting Java scripting, they provide a role for Web designers alongside developers and add flexibility to servlet architectures. JSP pages do not replace servlets; servlets, JSP, and JavaBeans play complementary roles in Web architectures. By following the MVC pattern, JSP applications can independently extend or enhance the controlling servlet, JSP page, and application model to support real-word scaling. The application model can be extended to a two- or three-tier design; in addition, adding helper beans can manage the JSP workflow and support loose coupling of application components.