Candidate Presentation-Tier Architectures

Candidate Presentation- Tier Architectures

In this section, we briefly compare two candidate presentation-tier architectures, summarizing their individual solutions to the presentation-tier requirements outlined in the previous section. The first architecture, a JSP-centric architecture , uses JSP pages alone to meet the presentation-tier requirements in a fairly low-tech approach to the problem. The second architecture, a servlet-centric architecture , uses JSP pages and servlets in a more complex and flexible model-view-controller design and represents a more state-of-the-art presentation-tier architecture.

The comparison will be performed by examining the components and techniques necessary to build a simple Person Tracker Web application using each architecture. The Person Tracker application maintains a list of people and allows users to view the list and edit individuals. It employs a simple stateless service Java object, Person-Service , as the business-tier component responsible for managing model objects. PersonService is a simple Java class that maintains a list of Person objects in memory and provides a straightforward interface for retrieving, creating, and updating people.

The complete source code for both solutions, along with a detailed walkthrough of their construction in each architecture, is available on the companion Web site (http://www. wiley .com/compbooks/masteringweblogic). This bonus material is also very valuable as an introduction to the Struts framework if you are unfamiliar with it. We ll be using Struts to build our main example program in the book, so we encourage you to download and examine the bonus material and the source code for the Person Tracker example program.

JSP-Centric Architecture

The JSP-centric architecture we chose for this comparison uses only a single presentation-tier technology, JSP pages, to produce a Web application meeting the presentation-tier requirements. The emphasis is on reducing complexity by eliminating all layers , technologies, and components not absolutely necessary to the design.

Figure 2.5 presents a high-level picture of the JSP components and their interactions in the architecture. Note that although everything in the presentation tier is implemented as JSP pages, there is still a controller component (called an action page in this architecture). This approach is basically an all-JSP implementation of the model-view-controller architecture.

Figure 2.5:  JSP-centric architecture components.

The following list summarizes the JSP-centric solution according to the major presentation-tier requirements outlined in the previous section. See the download- able example programs and bonus material for a detailed discussion of each of these areas.

JSP pages perform display tasks .     JSP pages are responsible for all of the display- related requirements outlined in the previous section. JSP pages fetch data from the service, create list displays by looping through collections of model objects, and create HTML forms containing model data for display and modification.

Action JSP pages process form submissions.    Specialized JSP pages, called action pages, are used to process HTML form submissions. Action pages extract form data using jsp:getProperty or similar techniques, validate the data, and interact with the business-tier components. Errors are handled by forwarding back to the form page after creating a list of errors in the HttpServlet- Request . Form data is redisplayed on the form for correction by special code that looks for it in the request.

Navigation controlled by view and action pages.    Basic navigation definition and outcome-based navigation are implemented in the JSP display pages and action pages using straightforward links and URLs. Navigation information could be stored in external files to reducing coupling at the expense of complexity. Submission controls are implemented using a custom token-based approach involving a hidden HTML form field and matching session attribute. HTTP redirects are used after form submissions, where possible, to alleviate bookmark and browser-navigation issues.

The benefits of the JSP-centric approach include the following:

• The number of components required to build a given application is small.

• The number of technologies used is small, reducing the learning curve for inexperienced developers.

The drawbacks include the following:

• Architecture tends to produce a tightly coupled application with hard-coded page names .

• Action JSP pages are primarily Java code but cannot be developed, compiled, and debugged as easily as pure Java code.

• Reuse of processing and validation logic is hampered by its placement in form-specific action JSP pages.

We recommend the JSP-centric architecture for small to medium- sized Web applications having a relatively static organization and a low potential for reuse of presentation-tier components, especially for development teams lacking the experience and skills required to implement more complex architectures properly. In these types of applications, the coupling and reuse drawbacks of the JSP-centric approach are outweighed by the benefits.

Best Practice  

Consider a simple JSP-centric approach for small to medium-sized projects if the benefits of simplicity and reduced learning curve outweigh the reuse and flexibility drawbacks.

Servlet-Centric Architecture

The servlet-centric architecture chosen for this comparison leverages the open -source servlet-centric framework called Struts to avoid building the required support components and logic from scratch. We re going to use a small subset of the components and features in the Struts framework, concentrating primarily on the features related to form handling and navigation.

Figure 2.6 presents a high-level view of the JSP, servlet, form, and model components and their interactions in the servlet-centric architecture chosen for this application.

Figure 2.6:  Servlet-centric architecture components.

There are still two main JSP pages, ShowPeople.jsp and EditPerson.jsp , but the components responsible for processing forms and controlling navigation have changed considerably in the new architecture. A new PersonForm object has been introduced for use by the EditPerson.jsp page and related processing, and the diagram does not include configuration and properties files required by the architecture. More components are required in the servlet-centric approach, overall, than in the JSP-centric architecture depicted in Figure 2.5.

Let s list the presentation-tier requirements in the same manner as before and examine how the servlet-centric architecture meets them in our example application. We again refer you to the downloadable source code and bonus material for a detailed examination of this solution.

JSP pages perform display tasks.     JSP pages are again responsible for all of the display-related requirements. JSP pages use special Struts custom tags to create HTML forms, favor retrieving model data from the HttpServletRequest rather than fetching it directly, and avoid hard-coding links to other pages by referencing controllers rather than display pages. Struts also provides tags for internationalization and simple role-based conditional logic.

Controller components process form submissions.    A centralized controller servlet invokes action classes to process HTML form submissions and interact with business-tier components. Specialized Java objects, called form beans , are used to extract and validate the HTML form data. Errors are handled by forwarding back to the form page after creating a list of errors in the HttpServletRequest for display by Struts tags on the form. Form data is automatically redisplayed on the form for correction.

Navigation controlled by configuration files.    Basic and outcome-based navigation information is stored in an external configuration file, struts-config.xml . This file is also used by the controller servlet to relate JSP display pages, form beans, and action classes across the application. Submission controls are implemented using a built-in token-based approach involving a hidden HTML form field and matching session attribute. HTTP redirects are used after form submissions, where possible, to alleviate bookmark and browser-navigation issues.

The benefits of the Struts-based servlet-centric approach include the following:

• Display logic, processing logic, and form validation are encapsulated in different components, improving application flexibility and reuse.

• Pure Java code in controller components is easier to develop with IDE tools than JSP action pages.

• Navigation information is external to the components and code, improving flexibility and reuse.

• Developers can be found with experience using the Struts framework, jump-starting your development effort.

Drawbacks of this approach include the following:

• The learning curve increases , due to additional components and files required for operation.

• Dependence on an open-source framework such as Struts may become an issue in the long term .

We recommend the servlet-centric architecture for medium-sized to large Web applications, especially if they require flexible organization and have a substantial potential for component reuse. Using a prebuilt framework such as Struts helps reduce the development effort and complexity of the application and is important in long-term maintenance.

Best Practice  

Favor the servlet-centric approach for medium-sized to large projects unless there are strong arguments related to complexity or learning curve. The flexibility and reuse benefits of a servlet-centric approach almost always exceed the costs of learning and adopting the architecture for all but the simplest projects.

Additional Frameworks

In this section we ve explored two candidate presentation-tier architectures, but clearly there are many more options to choose from. Custom-built architectures might combine elements from the JSP-centric approach and servlet-centric approach, or even adopt different approaches in different areas of the application. Remember, however, that custom-built architectures have an inherent disadvantage relative to standard frameworks such as Struts when it comes time to introduce new developers to a project or hand the code off to others for long-term maintenance and enhancements: No external developer is going to know your custom-built framework on day one.

There are also very good alternative open-source frameworks available if the Struts framework does not meet your particular needs:

• Turbine is an open-source framework from the same organization that developed the Struts architecture. Turbine represents a very strong implementation of the model-view-controller architecture providing enhanced flexibility, but it is arguably more complex than other controller-centric architectures such as Struts. Visit the Turbine home page at http://jakarta.apache.org/turbine for more information.

• WebWork is a recent addition to the open-source architecture offerings. Developed by a group of people at SourceForge.net , headed by the prolific designer and programmer Rickard –berg, the WebWork framework supports both JSP-centric and servlet-centric development. Like Struts, it provides a custom-tag library for use in display JSP pages, an Action -based controller architecture, and facilities for internationalization and external message catalogs. It also provides a powerful Expression Language allowing very compact expressions in the place of unwieldy JSP scriptlet code and jsp:useBean elements. See http://www.opensymphony.com/webwork for more information on WebWork.

We ve barely scratched the surface of what s out there today. If you are making Web application architecture decisions for a large project, avail yourself of all the information and resources available on the Internet to make a well-informed decision appropriate for your organization and project. Don t choose an architecture based on immediate reactions or previous experience. It s very important to the project that you choose well and get started in the right direction.