J2EE Blueprints Design Pattern
Front Component

 name

Front Component

 abstract

Unifies and simplifies user interface and workflow by interpreting user requests and dispatching screens from a single point. Simplifies testing, logging, and security, since all user communication flows through a single component. Acts as a "switchboard" between interface presentation and application functions, and centralizes the "wiring" between the two.

 intent

Simplify implementation and maintenance of user interface presentation and workflow

 category

Object Behavioral Pattern

 motivation

As interactive applications grow, the number of ways to present data, the number of possible user actions, and the number of system functions all increase. A well-factored application will partition responsibility for specific tasks to various classes, with resulting benefits in reuse, testability, and implementation clarity. But the fine-grained partitioning of responsibility between classes increases the number of objects that are involved in performing any particular task, as well as the number of connections between objects. A class that explicitly references many other classes is less reusable, especially if those classes themselves reference many other classes, because everything in the system depends on everything else. Additionally, the interface presented by any particular class becomes arbitrarily complex, making the system difficult to maintain and extend.

These problems can be addressed by introducing a Front Component class that handles the dispatch of user actions to application operations, and the selection of appropriate user views. The interconnection between the fine-grained objects in the system is the responsibility of the controller. This allows component instances to communicate with one another without explicit dependency.

Many Web applications are structured as a highly interdependent, brittle collection of Web pages, a change in any one of which may affect many other pages in ways that are difficult to trace. The Front Component pattern in the Java Pet Store avoids this problem by centralizing the dispatch of HTTP service requests (POST and GET) within a single servlet. This servlet class, MainServlet, along with the RequestProcessor class, maps user requests to application model operations (thereby updating state on the server,) and determines which user views to present next. Both the map of user inputs to application operations and the screen flow map are configurable in the files requestmappings.xml and screendefinitions.xml, respectively.

The Front Component is the single point of entry for http requests to the Controller in the Model View Controller design of the Java Pet Store. It acts as a Mediator between the JSP pages that form the Web user interface and the application model on the server.


 applicability

Use Front Component:

  • To decouple large numbers of presentation components from the actions they perform
  • To pride centralized management of user request dispatching
  • To provide centralized management of screen flow
  • To simplify the interface to user requests

 structure

Figure 1. UML Diagram for the Front Component.

 participants

Client

  • posts user input and requests
  • receive and display data presentations
FrontComponent

  • Dispatches user inputs to application operations
  • Selects data presentation components based on user input and application model state
  • Centralizes initialization of PresentationComponents
PresentationComponent

  • Displays data from ApplicationModel
ApplicationModel

  • Represents application functionality

 collaborations

Client

  • Abstracts user interface
  • Sends user requests to FrontComponent
  • Displays data presentations from FrontComponent
Front Component

  • Abstracts presentation flow and user request/application action map
  • Interprets and dispatches user actions from Client
  • Initiates application actions on Application Model
  • Selects Presentation Component to send to Client
Presentation Component

  • Abstracts data display
  • Displays data from the Application Model
  • Is selected by Front Component
  • Receives and forwards user actions to FrontComponent
Application Model

  • Abstracts application functionality
  • Supplies data to Presentation Component
  • Performs application actions initiated by Front Component

 consequences

The FrontComponent has the following consequences:

The external interface for user requests is simplified. All user requests into the system at a single point, namely the FrontComponent. This consisted system entry point simplifies adding new user interface components.

Increased component reuse and flexibility. Since the Presentation Components and Application Model only communicate through the FrontComponent, there is no dependency between them. This loose coupling simplifies extension of both data presentation and application functionality. Application components can be used more flexibly, since the FrontComponent acts as a "smart switchboard" between presentations and the application model.

Simplified maintenance. The FrontComponent provides a consisted framework for mapping user inputs to application actions, and for selecting the next screen (or other data presentation) to present the user, simplifying maintenance.

Simplified security management. The single point of entry to the system provides a convenient place to enforce security policies.

Centralized control. The FrontComponent centralizes application and presentation control, which can be complex. If the FrontComponent lacks a clear design, the complexity it is trying to manage will simply move into the FrontComponent class, making it a centralized maintenance hazard.

More comprehensible design. The FrontComponent class makes system interactions easier to understand. Instead of multiple presentations interacting with multiple application services, presentations and application services interact only with the Front Component. This isolation makes it easier to understand what any individual component is doing.

Front Component can be a complexity hazard. As mentioned above, the complexity of interconnections between components is encapsulated in the Front Component. If the Front Component does not have a clear, consistent, and extensible mechanism for making these connections, it will become a monolithic chunk of code that is difficult maintain, understand, and extend.


 implementation-issues

Consider the Command pattern to manage Front Component complexity. To manage the potential complexity of the Front Component, apply the Command pattern. With Command, extensions to Front Component functionality don't change the Front Component's API. Each extension simply defines a new command and a way to handle the command.


 sample-code

Java Pet Store Client. The Client participant in the Java Pet Store is the user's browser. It displays HTML from the Front Component, and posts user input to the Front Component.

Java Pet Store Front Component. The Front Component in the Java Pet Store is the servlet MainServlet.java, which is mapped to the single URL namespace /control/*. MainServlet uses the classes RequestProcessor.java and RequestToEventTranslator.java to map user actions to model actions, and the class ScreenFlowManager.java to select and create the next presentation (HTML page). The screen flow and user action maps are expressed as the XML files screendefinitions.xml and requestmappings.xml, respectively.

Java Pet Store Application Model. The Front Component manipulates server-side enterprise beans by way of events, which it dispatches in response to user inputs.

Java Pet Store Presentation Components. The Presentation Components that the Front Component transmits to the client are HTML or JSP pages.


 also-known-as


 related-patterns

Mediator (GoF)
Facade (GoF)
Session Entity Facade (J2EE)