Integrating a Web Application Framework into Overall Application Architecture

Any good web application framework will help us achieve our first goal - a clean web tier. However, this doesn't guarantee that we achieve the second goal - a thin web tier.

All three frameworks we've discussed enable us to clean up the web tier, separating presentation and content. However, none gives us much help in integrating our web tier with well-designed architecture.

WebWork helps us to create interface-agnostic commands; however, it doesn't provide an infrastructure to enable these commands to invoke business objects in a standard way.

Struts enables custom "plug-ins" to be defined in struts-config.xml files, as a way of enabling Struts web components to access other application objects. Plug-ins are configuration wrappers for user-specific application components, and must implement the org.apache.struts.action.PlugIn interface. Struts plug-ins can expose simple bean properties, which can be populated from elements in the struts-config.xml file, as in the following example from the Struts 1.1 sample application:

    <plug-in      className="org.apache.struts.webapp.example.memory.MemoryDatabasePlugIn"    >      <set-property        property="pathname"        value="/WEB-INF/database.xml"/>                                                                                         </plug-in> 

Population is performed by the Struts Digester. Plug-ins normally set themselves as attributes on the global ServletContext to allow action implementations to access them. However, this is a much less capable and less general approach than the bean-based configuration approach we discussed in the last chapter:

• It's impossible to build a graph of application objects that depend on each other, as only primitive properties, not object references, are supported

• The only way to define business objects is in the Struts XML configuration file

• Plug-in implementations are tied to the Struts API

• The configuration of business objects is dependent on the web framework - a problem if we want to implement a different kind of interface

The Java Pet Store sample application (version 1.3), which includes its own web application framework, makes one of the most determined attempts I've seen at achieving a thin web tier, by formalizing the creation of events and the invocation of a centralized event processor (which must implement the com.sun.j2ee.blueprints.waf.controller.web.WebClientController interface).

This has the significant advantage that web-tier application code only creates events or commands representing user actions, and displays the result of business processing; framework code (not web -ier application code) invokes business objects to process the events. Unfortunately, this approach, while interesting in theory, isn't workable for real applications. There's a reason successful web application frameworks don't attempt to enforce such prescriptive workflow: it's inflexible and is inappropriate in many cases.

Thus we need to use a web application framework in conjunction with an overarching application infrastructure, and the more easily the two integrate, the better off we are.

Important 

Since the web interface should be thin, a web application framework should not provide the center of gravity for an application, imposing overall structure. This is the role of the application's business interfaces. A web application framework should merely make it easy to process user input and display the results, and offer easy - interface-based - integration with business objects.

It's possible to integrate the bean-based infrastructure I discussed in the last chapter with any web application framework. The root com.interface21.web.context.WebApplicationContext object, which defines JavaBeans and their relationships without the need to use the Singleton design pattern, is added to a web application's ServletContext by the com.interface21.web.context.ContextLoaderServlet, and can thus be accessed by any object with access to the ServletContext, which includes controllers in any framework. This will provide a superior alternative to using Singleton business objects, or simple factory objects, in any framework. It's achieves as close integration with the web application framework as do Struts plug-ins, despite the fact that they are defined in the Struts configuration file.

Note 

Close integration with Struts could easily be achieved by implementing a generic Struts plug-in that created an ApplicationContext object - for example, based on a string parameter specifying the location of an XML bean definition file - and added it to the ServletContext. This would enable a Struts configuration file to specify the location of business object bean definitions via a <plug-in> element, and Struts actions to access business objects by looking up the ApplicationContext in the ServletContext.

However, with a powerful JavaBeans-based infrastructure, it's not only possible to achieve closer integration of application objects with web application components: it's possible to configure most of the framework itself within the overall application context, meaning that framework components can be transparently configured in exactly the same way as application objects. Such a beans-based infrastructure simplifies both the implementation and the use of a framework.