Sun Java Center J2EE Patterns

Print-friendly Version

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.
• Decision points exist for content retrieval and manipulation.
• Multiple views are commonly used to respond to similar business requests.
• Want to encapsulate business logic in components other than the View
• System services and view management logic are relatively sophisticated

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 Dispatcher View pattern describe a similar structure, the two patterns suggest a different division of labor among the components. In Service To Worker, the Controller and the Dispatcher have more responsibilities.

The Service to Worker and 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, Views and Helpers.

Structure

The following class diagram represents the Service to Worker pattern:

Participants & Responsibilities

The following sequence diagrams represent the Service to Worker pattern:

As stated, Service to Worker and Dispatcher View represent a similar structure. The main difference is that S2W describes architectures with more behavior "up-front" in the Controller and Dispatcher, while DV describes architectures with more behavior moved "back" to the time of View processing. Thus, the two patterns suggest a continuum, where behavior is encapsulated closer to the "front" or moved farther "back" in the process flow.

The Controller is typically the initial contact point for handling a request. It works with a Dispatcher to complete view management and navigation. The Controller manages authentication, authorization, content retrieval, validation, and other aspects of request handling. It delegates to Helpers to complete portions of this work.

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.

The Dispatcher will use the RequestDispatcher object (supported in the Servlet specification), but will also typically encapsulate some additional processing. The more responsibilities that this component encapsulates, the more it fits into the Service to Worker pattern. Conversely, when the Dispatcher plays a more limited role, it fits more closely into the DispatcherView pattern.

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.

Servlet View 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 and stores 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, even the most novice developers understand JavaBeans. 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 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 Strategy

When the Dispatcher functionality is minimal, it can 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" or moved farther "back" in the process flow. The following diagram describes a scenario in which the Controller is heavily loaded with "up-front" work, but the Dispatcher functionality is minimal.

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:

Consequences

• Centralized Control
  Provides a central place to handle system services and business logic across multiple requests. Because some decisions (such as the JSP to which the request should be sent) can only be made after the completion of certain business logic, it is important that the decision-making process occur in a centralized place. The controller can manage business logic processing and request handling, and can make its decisions utilizing retrieved or calculated values that are based on the business calls. Keep in mind, though, that as control centralizes, it is possible to introduce a single point of failure.
• Improved Reusability
  Promotes cleaner application partitioning and encourages reuse. Code that is common among components is moved into the front controller and reused for each request. Because business logic is factored out of a JSP and into JavaBeans and/or Custom Tags, the logic may be reused across numerous JSPs. Code is not duplicated in different JSPs, making it easier to maintain and debug. Additionally, because the logic is removed from the View, the same business logic may be reused, 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 can also manage validation and error handling, because these operations are often done per request.
• Improved application partitioning
  Using Helpers results in a cleaner separation of the View from the business processing in an application. 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. If the business logic is left in a JSP, large projects result in cumbersome and unwieldy scriptlet code.
• Improved Role Separation
  Separating the formatting logic from the application business logic also reduces dependencies on the same resources among individuals fulfilling different roles. Without this separation, 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 is familiar with the implementation specifics of the other individual's work, it raises the likelihood of modifications accidentally 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.
• Dispatcher View Pattern [SJC]
  The DispatcherView 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