Sun Java Center J2EE Patterns

Print-friendly Version

Dispatcher View

Context

System handles web requests. Presentation processing requires generating a view based on a template and dynamic model.

Problem

Presentation tier changes occur often and are difficult to develop and maintain, due to the intermingling of business data access logic and presentation formatting logic. This makes the system less flexible, less reusable, and generally less resilient to change.

Portions of the business logic that are mixed with the View deal with adapting the intermediate model for display while portions deal with completing processing that is common across multiple requests, such as logging and authentication. The former might best be encapsulated in a component that is used by a specific View, while the latter might be encapsulated in a centralized component.

Intermingling the business and systems logic with the view processing also reduces modularity and provides a poor separation of roles among web-production and software development teams.

Forces

• Need dynamic content generation.
• Content requires dynamic business data.
• Common system services processing, such as authentication and authorization checks, completes per request.
• Decisions that affect content retrieval and adapting the model for the view are often delayed until the time that the view processes.
• Want to encapsulate business logic in components other than the View.
• System services and view management logic are basic and limited in complexity.
• The number of Views that might be mapped to a particular request are few (ie: one or two).

Solution

Combine a Dispatcher with Views and Helpers (see ViewHelper Pattern) to handle client requests and prepare a dynamic presentation as the response. A Dispatcher is responsible for view management and navigation, and can be encapsulated either within a Controller (see FrontController Pattern), or can be a separate component working in coordination.

While this pattern and the Service to Worker pattern describe a similar structure, the two patterns suggest a different division of labor among the components. The Controller and the Dispatcher have limited responsibilities, as compared to the Service to Worker pattern, since the up-front processing and view management logic are basic. Furthermore, if centralized control of the underlying resources is considered unnecessary, then the Controller is removed and the Dispatcher may be moved into a View.

The Service to Workerand Dispatcher View patterns represent a common combination of other patterns from the catalog, and thus each warrants its own name to promote efficient communication among developers. Unlike the Service to Worker pattern, the Dispatcher View pattern suggests deferring content retrieval to the time of View Processing.

In the Dispatcher View pattern, the Dispatcher plays a limited to moderate role in View Management. In the Service to Worker pattern, the Dispatcher plays a moderate to large role in View Management.

A limited role for the Dispatcher occurs when no outside resources are utilized in order to choose the view. The information encapsulated in the request is sufficient to determine the View to dispatch the request. For example,

http://some.server.com/servlet/Controller?next=login.jsp

The sole responsibility of the Dispatcher component in this case is to dispatch to the View 'login.jsp'.

An example of the Dispatcher playing a moderate role is the case where the Client submits a request directly to a Controller with a query parameter that describes an action to be completed:

http://some.server.com/servlet/Controller?action=login

The responsibility of the Dispatcher component in this case is to translate the logical name login into the resource name of an appropriate View such as login.jsp, and dispatch to that View. To accomplish this translation, the Dispatcher may access resources such as an XML configuration file that specifies the appropriate View to display.

On the other hand, in the Service to Worker pattern the Dispatcher might be more sophisticated. The Dispatcher may invoke a business service to determine the appropriate View to display.

The shared structure of these two patterns that is mentioned above consists of a Controller working with a Dispatcher, View and Helper.

Structure

The following class diagram represents the Dispatcher View pattern:

Participants & Responsibilities

The following sequence diagram represents the Dispatcher View pattern:

While the Controller responsibilities are limited to system services, such as authentication and authorization, it is often still beneficial to centralize these aspects of the system. Notice also that, unlike in Service to Worker, the Dispatcher does not make invocations on a business service in order to complete its View management processing.

The Dispatcher functionality may be encapsulated in its own component. At the same time, when the responsibilities of the Dispatcher are limited, as described by this pattern, the Dispatcher functionality is often folded into another component, such as the Controller or the View (see Dispatcher in Controller and Dispatcher in View Strategies).

In fact, the Dispatcher functionality may even be completed by the container, in the case where there is no extra application-level logic necessary. In this case, we are left with the View Helper pattern, with the request being handled directly by the View. An example is a View called main.jsp that is given the alias name first. The container will process the following request, translate the alias name to the physical resource name, and dispatch directly to that resource:

http://some.server.com/first

Thus, the DispatcherView pattern describes a continuum of related scenarios, moving from a scenario that is very similar structurally to Service to Worker, to one that is similar to View Helper.

The Controller is typically the initial contact point for handling a request. The Controller manages authentication and authorization, and delegates to a Dispatcher to do view management.

A Dispatcher is responsible for view management and navigation, managing the choice of the next View to present to the user and providing the mechanism for vectoring control to this resource.

A Dispatcher can be encapsulated within a Controller (see FrontController Pattern) or can be a separate component working in coordination. The Dispatcher can provide static dispatching to the View or may provide a more sophisticated dynamic dispatching mechanism.

A View represents and displays information to the client. The information that is used in a display is retrieved from a model. Helpers support Views by encapsulating and adapting a model for use in a display.

A Helper is responsible for helping a View or Controller complete its processing. Thus, Helpers have numerous responsibilities, including gathering data required by the View and adapting (see GoF Adaptor pattern) this data model for use by the View. Helpers can service requests for data from the View by simply providing access to the raw data or by formatting the data as web content.

A View may work with any number of Helpers, which are typically implemented as JavaBeans (JSP 1.0) and Custom Tags (JSP 1.1+). Additionally, a Helper may represent a Command object, a Delegate (see Business Delegate pattern), or an XSL Transformer, which is used in combination with a stylesheet to adapt and convert the model into the appropriate form.

The BusinessService is a role that is fulfilled by the service the client is seeking to access. Typically, the BusinessService is accessed via a BusinessDelegate. The BusinessDelegate's role is to provide control and protection for the business service (see the Business Delegate pattern).

Strategies

ServletFront Strategy

This strategy suggests implementing the Front Component as a Servlet. Though semantically equivalent, it is preferred to the JSPFront Strategy. The Front Component handles request processing, managing and controlling aspects of this processing. Since these responsibilities are related to, but logically independent of display formatting, they are more appropriately included in a Servlet instead of a JSP.

The ServletFront Strategy does have some potential drawbacks. In particular, it does not leverage some of the JSP runtime environment utilities, such as automatic population of request parameters into Helper properties. Fortunately, this drawback is minimal because it is relatively easy to create or obtain similar utilities for general use. There is also the possibility that the functionality of some of the JSP utilities may be included as standard Servlet features a future version of the Servlet specification.

JSPFront Strategy

This strategy suggests implementing the Front Component as a JSP. Though semantically equivalent, the ServletFront Strategy is preferred to the JSPFront Strategy. Since the Front Component handles processing that is not specifically related to display formatting, it is a mismatch to implement this component as a JSP.

Implementing the Front Component as a JSP is clearly not preferred for another reason: It requires a software developer to work with a page of markup in order to modify request handling logic. Thus, a software developer will typically find the JSPFront strategy more cumbersome when completing the cycle of coding, compilation, testing, and debugging.

JSPView Strategy

The JSPView Strategy suggests using a JSP as the view component. This is the preferred strategy to the ServletView Strategy. While it is semantically equivalent to the Servlet View Strategy, it is a more elegant solution and is more commonly used.

ServletView Strategy

The ServletView Strategy utilizes a servlet as the view. It is semantically equivalent to the preferred JSPView Strategy. However, the ServletView Strategy is often more cumbersome for the software development and web production teams because it embeds markup tags directly within the Java code. When tags are embedded within the code, the view template is more difficult to update and to modify. Additionally, intermingling Java code and markup tags creates a poor separation of user roles within the project and increases the dependencies on the same resources among multiple members of different teams. When an individual works on a template containing unfamiliar code or tags, it increases the likelihood of accidental change introducing problems into the system. There is also a reduction in work environment efficiency (too many people sharing the same physical resource) and an increase in source control management complexity.

These problems are more likely to occur in larger enterprise environments that have more complicated system requirements and that use teams of developers. They are less likely to occur with small systems that have simple business requirements and use few developers, because the same individual may likely fill the roles mentioned above. However, keep in mind that often projects start small-with simple requirements and few developers-but often ultimately evolve to become sophisticated enough to benefit from these suggestions.

JavaBean Helper Strategy

The helper is implemented as a JavaBean. Using helpers results in a cleaner separation of the View from the business processing in an application, since business logic is factored out of the View and into the helper component. In this case the business logic is encapsulated in a JavaBean, which aids in content retrieval and adapts the model for use by the View.

Using the JavaBean Helper Strategy requires less up-front work than does the Custom Tag Helper Strategy, since JavaBeans are more easily constructed and integrated into a JSP environment. Additionally, JavaBeans are well understood by even the most novice developers. This strategy is also easier from a manageability standpoint, since the only resulting artifacts are the completed JavaBeans.

Custom Tag Helper Strategy

The helper is implemented as a Custom Tag (JSP 1.1+ only). Using helpers results in a cleaner separation of the View from the business processing in an application, since business logic is factored out of the View and into the helper component. In this case the business logic is encapsulated in a custom tag component, which may aid in content retrieval and adapts the model for use by the View.

Using the Custom Tag Helper Strategy requires more up-front work than does the JavaBean Helper Strategy, since custom tag development is moderately complicated relative to JavaBean development. Not only is there more complexity in the development process, but there is much more complexity with respect to integrating and managing the completed tags. Numerous artifacts must to be generated with which the environment needs to be configured to use this strategy, including the tag itself, a tag library descriptor, and configuration files.

Dispatcher in Controller

While the Controller responsibilities are limited to system services, such as authentication and authorization, it is often still beneficial to centralize these aspects of the system. Furrthermore, given the limited role of the Dispatcher, it is common for it to be folded into the Controller, as shown in the following sequence diagram.

As stated, the Service to Worker and Dispatcher View patterns suggest a continuum, where behavior is encapsulated closer to the "front" in Service To Worker or moved farther "back" in Dispatcher View.

The following sequence diagram shows the interactions for this strategy.

The Controller does not create an explicit Dispatcher object. Instead, the Controller takes care of dispatching to the View. Alternatively, one could implement a Dispatcher to which the Controller can delegate the dispatching function.

Dispatcher in View

If the Controller is removed due to its limited role, the Dispatcher may be moved into a View. This design can be useful in cases where there is typically one View that maps to a specific request, but where a secondary View may be used on an infrequent basis. For example, based on some information in the request or results of some processing in a view, a custom tag Helper in the View might vector control to a secondary View. A typical case is when a client request is submitted to a specific View, and will be serviced by that View in almost every case. Consider the case where the user has not been authenticated, but requests access to one of the few protected JSPs on a site. Since the site has only a few protected pages, and limited dynamic content, authentication can be performed within in those JSPs, instead of using a site-wide centralized Controller. Those pages that need authentication, include a custom tag Helper at the top of the page. This Helper performs the authentication check and either displays the page for the user or forwards the user to an authentication page.

The following sequence diagram represents this scenario:

Transformer Helper Strategy

The helper is implemented as an eXtensible Stylesheet Language Transformer (XSLT). This is particularly useful with models that exist as structured markup, such as eXtensible Markup Language (XML), either natively within legacy systems or via some form of conversion. Using this strategy can help to enforce the separation of the model from the view, since much of the view markup must be factored into a separate stylesheet.

The following sequence diagram describes a potential implementation of this strategy:

The Controller handles the request and invokes a Command object, implemented as a JavaBean Helper. The Command object initiates the retrieval of Account data. The Account object invokes the Business Service, which returns the data in the form of a Value Object (see Value Object pattern), implemented as a JavaBean.

Content retrieval is complete and control is dispatched to the AccountView, which uses its Custom Tag transformer to manipulate the model state. The transformer relies on a StyleSheet, which describes how to transform the model, typically describing how to format it with markup for display to the Client. The StyleSheet is usually retrieved as a static file, though it may also be dynamically generated.

An example of how the Custom Tag Helper might look in AccountView follows:

<xsl:transform model="accounthelper"
stylesheet="/transform/styles/basicaccount.xsl"/>

Consequences

• Centralized Control
  Centralized control provides a central place to handle system services across multiple requests. Although decisions such as which JSP to dispatch to are already included as part of the request, centralized control enables the controller to better manage the processing of security services and dispatch. However, centralizing control raises the possibility of introducing a single point of failure.
• Improved Reusability
  Moving common code into the front controller and reusing it for each request promotes cleaner application partitioning and encourages code reuse. Business logic that is factored out of a JSP and into JavaBeans and/or Custom Tags may be reused across numerous JSPs. Code is kept in one location rather than duplicated in many different JSPs; thus, it is easier to maintain and debug. Additionally, removing the logic from the View enables reuse of the same business logic, potentially without modification, to service an entirely different user interface, such as a Swing UI.
• User Tracking and Logging
  Allows the tracking of a particular user and logging of related activity.
• Validation and Error Handling
  The controller may also manage validation and error handling, since this is often done per request.
• Improved application partitioning
  Use of Helpers results in a cleaner separation of the View from an applications business processing. The Helpers, in the form of JavaBeans (JSP 1.0) and Custom tags (JSP 1.1+), provide a place for business logic to be factored out of the JSP, where scriptlet code quickly becomes cumbersome and unwieldy in large projects.
• Improved Role Separation
  Separating the formatting logic from the application business logic also reduces dependencies that individuals fulfilling different roles might have on the same resources. For example, a software developer would own code that is embedded within HTML markup, while a web-production team member would need to modify page layout and design components that are intermingled with business logic. Because neither individual fulfilling these roles may be familiar with the implementation specifics of the other individual's work, there is the likelihood of inadvertent modifications introducing bugs into the system.

Related Patterns

• Front Controller [SJC]
  The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• View Helper [SJC]
  The Service to Worker pattern is the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern.
• Service to Worker [SJC]
  The Service to Worker pattern is also the result of combining the View Helper Pattern with a Dispatcher, in coordination with the Front Controller pattern. The Service to Worker and the Dispatcher View patterns are identical with respect to the components involved, but differ in the division of labor among those components. The Dispatcher View pattern suggests deferring content retrieval and error handling to the time of View Processing. Also, the Dispatcher plays a more limited role in View Management, as the choice of View is typically already included in the request.

(c) 2000-2001 Sun Microsystems, Inc. All Rights Reserved.

Version 1.0 Beta