ServiceToWorker Pattern
Context The system controls flow of execution and access to business data, from which it creates presentation content. Note The Service to Worker pattern, like the Dispatcher View pattern, describes a common combination of other patterns from the catalog. Both of these macro patterns describe the combination of a controller and dispatcher with views and helpers. While describing this common structure, they emphasize related but different usage patterns. Problem The problem is a combination of the problems solved by the Front Controller and View Helper patterns in the presentation tier. There is no centralized component for managing access control, content retrieval, or view management, and there is duplicate control code scattered throughout various views. Additionally, business logic and presentation formatting logic are intermingled within these views, making the system less flexible, less reusable, and generally less resilient to change. Intermingling business logic with view processing also reduces modularity and provides a poor separation of roles among Web production and software development teams. Forces
Solution Combine a controller and dispatcher with views and helpers (see "Front Controller" on page 172 and "View Helper" on page 186) to handle client requests and prepare a dynamic presentation as the response. Controllers delegate content retrieval to helpers, which manage the population of the intermediate model for the view. A dispatcher is responsible for view management and navigation and can be encapsulated either within a controller or a separate component. Service to Worker describes the combination of the Front Controller and View Helper patterns with a dispatcher component. 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. Since the Service to Worker and Dispatcher View patterns represent a common combination of other patterns from the catalog, 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 typically plays a limited to moderate role in view management. In the Service to Worker pattern, the dispatcher typically 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 here 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 Service to Worker and Dispatcher View consists of a controller working with a dispatcher, views, and helpers. Structure The class diagram in Figure 7.20 represents the Service to Worker pattern.
Participants and Responsibilities Figure 7.21 shows the sequence diagram that represents the Service to Worker pattern.
As stated, Service to Worker and Dispatcher View represent a similar structure. The main difference is that Service to Worker describes architectures with more behavior "up front" in the controller and dispatcher, while Dispatcher View describes architectures with more behavior moved back to the time of view processing. Thus, the two patterns suggest a continuum, where behavior is either encapsulated closer to the front or moved farther back in the process flow. Controller 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. Dispatcher 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 "Front Controller" on page 172) or it can be a separate component working in coordination with the controller. The dispatcher can provide static dispatching to the view or it may provide a more sophisticated dynamic dispatching mechanism. The dispatcher uses the RequestDispatcher object (supported in the servlet specification), but it also typically encapsulates 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 Dispatcher View pattern. View 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. Helper 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 storing this intermediate model, in which case the helper is sometimes referred to as a value bean. Additionally, helpers may adapt 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+) components and custom tags (JSP 1.1+). Additionally, a helper may represent a Command object or a delegate (see "Business Delegate" on page 248). ValueBean A value bean is another name for a helper that is responsible for holding intermediate model state for use by a view. A typical case, as shown in the sequence diagram in Figure 7.12, has the business service returning a value bean in response to a request. In this case, ValueBean fulfills the role of a Transfer Object (see "Transfer Object" on page 261). BusinessService The business service is a role that is fulfilled by the service the client is seeking to access. Typically, the business service is accessed via a Business delegate. The business delegate's role is to provide control and protection for the business service (see the "Business Delegate" on page 248). Strategies Servlet Front Strategy See "Servlet Front Strategy" on page 175. JavaServer Pages Front Strategy See "JSP Front Strategy" on page 178. JSP View Strategy See "JSP View Strategy" on page 190. Servlet View Strategy See "Servlet View Strategy" on page 191. JavaBean Helper Strategy See "JavaBean Helper Strategy" on page 194. Custom Tag Helper Strategy See "Custom Tag Helper Strategy" on page 194. Dispatcher in Controller Strategy See "Dispatcher in Controller Strategy" on page 183. 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. Figure 7.22 describes a scenario in which the controller is heavily loaded with upfront work, but the dispatcher functionality is minimal.
Transformer Helper Strategy See "Transformer Helper Strategy" on page 200. Consequences
The pattern also promotes cleaner application partitioning and encourages reuse. Common code is moved into a controller and reused per request and moved into helper components, to which controllers and views delegate. The improved modularity and reuse means less duplication, which typically means a more bug-free environment.
Sample Code The following sample code shows an implementation of the Service to Worker pattern, using a controller servlet, a command helper, a dispatcher component, and a view. The implementation includes the Servlet Front Strategy, Command and Controller Strategy, JSP View Strategy, and JavaBean Helper Strategy. A very basic composite view is used as well. A screen shot of the resulting display is shown in Figure 7.23. Example 7.29 shows the controller servlet, which delegates to a Command object (Command and Controller Strategy) to complete the control processing. The Command object is retrieved via a factory invocation, which returns the generic Command type, an interface shown in Example 7.30. The sample code uses a LogManager to log messages. The screen shots in Figure 7.23 and Figure 7.28 show these messages displayed at the bottom of the page, for the purposes of this example. Example 7.29 Controller Servlet with Command and Controller Strategy
public interface Command {
public String execute(RequestHelper helper) throws javax.servlet.ServletException, java.io.IOException; } Each Command Object helper implements this generic interface, which is an example of the GoF Command pattern. The Command object is an instance of the ViewAccountDetails class, which is shown in Example 7.31. The command instance delegates to an AccountingAdapter to make an invocation to the business tier via business delegate. The adapter class is shown in Example 7.32. It uses a separate dispatcher component to determine the next view to which control should be dispatched and to actually dispatch to this view. Example 7.30 Command Interface public interface Command {
public String execute(RequestHelper helper) throws javax.servlet.ServletException, java.io.IOException; }
The invocation on the business service via the delegate yields an Account Transfer Object, which the adapter stores in a request attribute for use by the view. Example 7.33 shows accountdetails.jsp, the JSP page to which the request is dispatched. The Transfer Object is imported via the standard <jsp:useBean> tag and its properties accessed with the standard <jsp:getProperty> tag. Also, the view uses a very simple composite strategy, doing a translation-time inclusion of the trace.jsp subview, which is responsible for displaying log information on the display solely for example purposes. Example 7.33 View - accountdetails.jsp
Related Patterns
Contact Us© 2001-2002 Sun Microsystems, Inc. All Rights Reserved. |