Presentation-Tier Architecture Selection


Presentation- Tier Architecture Selection

The high-level depiction of J2EE application tiers in Figure 2.1 defined the presentation tier as containing Java servlets and JSP pages. When we talk about presentation-tier architecture, we are essentially defining the manner in which these two types of components will be combined to create a user interface that meets the explicit and implicit requirements for the presentation tier of the application.

Understanding these explicit and implicit requirements is the goal of the next section.

Presentation-Tier Requirements

Defining the presentation-tier architecture is much like designing the application itself: It must depend on the requirements. You don t build a customer management system if the users want an accounting system, and you shouldn t design the presentation tier without understanding presentation-tier requirements.

We re not talking about understanding the user-interface requirements of the system, but rather the general requirements of any well-behaved Web application. Examples include good form validation and error handling, robust handling of bookmarks and browser Back buttons , ability to change graphics or page arrangements quickly, and helpful pop-ups and dialogs. Users are becoming more familiar and comfortable with the Web and are demanding robust behavior from their custom-built Web applications. Meanwhile, the large commercial sites keep raising the bar with respect to usability. Users see constant improvements in areas such as page layout customization, form validation, pick lists and pop-ups, and many other areas, and they wonder why you can t implement something similar for their project.

A detailed discussion of state-of-the-art JavaScript technologies and site design is beyond the scope of this book. If you are interested in user-controlled page layout and content customization, you should investigate BEA s WebLogic Portal product. Our focus is presentation-tier architecture rather than detailed site design and human factors engineering.

Achieving many of the basic usability and flexibility requirements of a site can be helped or hindered a great deal by the choice of presentation-tier architecture. These are some of the presentation-tier requirements:

  • Display requirements

  • Form/update requirements

  • Navigation requirements

The following sections document these requirements and the ways they affect the required architecture.

Display Requirements

Display requirements include all of the user-interface requirements related to the presentation of data on Web pages. As discussed in Chapter 1, JSP pages are considered the best mechanism for creating HTML responses containing dynamic content. We will assume you re using JSP pages for display behavior unless otherwise noted.

In this section, we discuss some of the key display-related requirements that affect presentation-tier architecture decisions. At a minimum, the architecture must support the following:

  • Displaying model data in various modes and forms

  • Displaying lists of objects with flexible sorting, paging, and form-input capabilities

  • Controlling page availability and model data presentation based on user authorization

  • Internationalization of all appropriate content on pages

  • Producing flexible and maintainable pages allowing for multiple deployments and efficient future modifications

Displaying Model Data

Applications must be able to display model data on view-only Web pages for inspection by the user. The architecture must provide a straightforward mechanism to retrieve the model object and place properly formatted attribute values in the HTML response. JSP pages offer expression scriptlets and jsp:useBean -related jsp:getProperty tags for the purpose of embedding the model data in the response, and they require only some mechanism for retrieving the proper model object and making it available in the proper context for display.

Displaying Model Data in a Form

You will often want to allow the creation and modification of model objects through an HTML form with input elements corresponding to the model object attributes. The presentation-tier architecture must provide a mechanism to retrieve the proper model object (or create an empty object) and populate the form elements with the properly formatted attribute values. The same JSP techniques used for viewing model data are appropriate in this case, namely expression scriptlets and jsp:getProperty tags.

Techniques for populating form elements with model data are simple enough for text input fields, requiring a snippet in the JSP page something like this:

 <tr>   <td nowrap>Middle name:</td>   <td><INPUT TYPE="text" NAME="middleName"         value="<%= person.getMiddleName() %>" size="50"></td> </tr> 

Techniques become more challenging when the form elements are formatted dates, select lists, checkboxes, radio buttons, and other fields requiring some form of mapping from the attribute value in the model object to the proper display format or selected value on the page. Your presentation-tier architecture must recognize the need for these complex form elements and provide convenient and reliable mechanisms for producing them.

Displaying a List of Model Objects

No Web application is complete without a search page for choosing criteria and a results page showing a list of model objects meeting the search criteria. Search criteria pages are typically straightforward HTML forms with no new requirements for the presentation-tier architecture. Search result pages, on the other hand, can often present a host of interesting challenges for the presentation tier:

  • You should be able to sort results by different columns , perhaps by clicking on the desired column title.

  • You may need to buffer and page results, presenting only a subset of the results on the page at one time and allowing the user to scroll through the results via Previous and Next buttons.

  • Although most search result pages are simple views of the model data with perhaps a link to drill in and edit the corresponding object, some list pages may require form elements such as checkboxes or input fields associated with each row. The architecture should therefore support the creation of HTML forms containing multiple model objects in a list.

Creating search result pages containing lists of model objects can be accomplished with JSP pages using straightforward scriptlet looping code or iterator custom tags without much trouble. You can also accommodate sorting, results pagination, and multiobject forms through relatively simple techniques. The presentation-tier architecture should define the standard approach for accomplishing these tasks in a manner consistent with the solutions for other display-related requirements.

Presenting Role-Based Views of Data

Most Web applications require user authentication in some form or another, and many applications limit or modify the data presented to the user depending on their authorization. It may be as simple as identifying pages in the site available to particular users and using the declarative security provided through the web.xml descriptor file for the Web application. If that s the case for you, consider yourself fortunate. Web applications commonly require much more sophisticated role- or user-based control of the pages and data presented. Some typical requirements include the following:

  • Selected pages or whole areas of the site are available or off limits based on user or role.

  • Navigation devices such as menus , navigation bars, and hyperlinks must reflect the user or role by eliminating or disabling links leading to off-limit pages.

  • Pages may be available to certain users or roles but exhibit display differences or limited functionality depending on the user. Forms may treat some fields as read-only for certain users, for example, or omit certain information completely.

  • Page display and functionality may differ depending on both user information and attribute information in the model object itself. For example, modifying customer information might require that the user be a salesperson in that customer s region.

Are you beginning to get the picture? Many application-development efforts have abandoned the simplistic declarative security model offered by J2EE in favor of a custom-built authorization framework providing some or all of these features. The presentation-tier architecture you select should provide a mechanism for integrating with your chosen security system and meeting your role- and user-based display requirements.

Of course, writing your own authorization framework comes at a price. You are depending on your developers not only to understand all of the facets of writing a security framework but also to use it properly to protect your application s resources. Chapter 10 describes the WebLogic Server security model in detail, including the WebLogic Server extensions that allow you to address some of these authorization flexibility issues without writing your own security framework.

Internationalization

Your Web application may need to support internationalized content and display formats as part of a comprehensive globalization, localization, and internationalization (GLI) strategy.

Internationalization, often abbreviated as I18N, requires the removal of all language- and culture-specific items from the application source code and display pages. All displayed text, images with embedded text, informational and error messages, button labels, and other language-specific resources should be packaged independently from the application and presented using language-specific mechanisms in the display pages. Date formats, monetary and numeric formats, and other display formats may also require internationalization.

Localization, abbreviated L10N, takes this process one step further by tailoring the application look and feel, site content, currency conversions, business processes, and design considerations based on language and cultural considerations. More than just translating content, localization ensures that users feel the site has been designed specifically for them. Applications cannot be localized unless they are first internationalized.

Globalization seeks to ensure that all customers receive a similar quality of experience regardless of language, culture, and location. It builds on internationalization and localization and ensures the proper language- and location-specific handling of customer interactions at all levels in the system. This might include global site hosting, global content management, multilingual customer support facilities, global invoicing and fulfillment, and many other issues not directly related to the Web application itself.

A complete discussion of internationalization is beyond the scope of this book. We will consider internationalization requirements when choosing a Web application architecture, but we will not include internationalized content or behavior in our example applications.

Display Flexibility and Maintainability

The final display-related requirement emphasizes planning for the future in the design of the Web application.

First, unless the application is a short-lived throwaway , it will undergo maintenance and enhancement at some time in the future. Plan for this eventuality by designing in the right level of flexibility and modularity from the start.

Next, don t assume that the layout, look and feel, style sheets, images, logos, or any other visual elements will remain constant over time. Customer- facing Web sites are part of the brand image of the company, and companies are continually updating their sites to adopt the latest marketing and branding directions. Even internal sites can undergo significant modification in display characteristics when functionality is added or removed ”for example, if new groups of users are given access or usability issues require major changes.

Finally, your site may need to be flexible enough to use in an application service provider (ASP) environment. The site appearance, colors, behaviors, and even layout may need to be easily customizable for multiple clients . You cannot copy the site and tweak it for the new client; you ll end up with multiple copies of the site to maintain, enhance, and update with desired functionality and look-and-feel changes. That s not where you want to be.

How might these relatively fuzzy requirements for flexibility and maintainability affect the presentation-tier architecture?

  • Style sheets are critical for defining fonts, sizes, colors, and other display attributes. Every single table cell , input field, and piece of text on the site should use a class attribute.

  • Define page layout details such as the overall HTML table structure in a way that allows modification in the future. For example, if the header, body, footer, and gutter contents and sizes are specified on every page in the site (a technique often referred to as the composite view pattern ), how easy will it be to shuffle the table structure around and move advertisements from the left to the right gutter? Not easy at all if you must edit every page to change the < jsp:include .../ > elements.

  • Modularity of display content is important. Any common element, whether it is a copyright message or a navigation bar, should be separated from surrounding content and placed in its own JSP page for inclusion via jsp:include elements or < %@ include file ... % > directives.

We discuss various template and page-assembly options in Chapter 3 to provide some best practices related to display flexibility and maintainability, and in Chapter 4 we build an example Web application that demonstrates many of the topics outlined here.

Form/Update Requirements

The requirements in the previous section dealt primarily with the flow of data from the model to the view and with the proper formatting and display of that data. This next set of presentation-tier requirements deals with data flow in the opposite direction, from the view back to model components, normally through the posting of HTML forms. Figure 2.3 illustrates the basic flow of this data and the role of the presentation tier in the transfer process. Remember that we re talking about only presentation-tier requirements in this section, so this discussion will not cover business-tier requirements, such as transactional behavior or object-relational mapping.

click to expand
Figure 2.3:  Steps required during form processing.

In this section we walk through the process from the HTML form to the model object, highlighting the presentation-tier requirements. At a minimum, the architecture must support the following:

  • Client-side validation to provide immediate feedback to users when input does not meet constraints

  • Extraction of HTML form data to facilitate subsequent validation and transfer steps

  • Server-side validation to catch input errors before transferring data to model objects

  • Display of errors and original data in the HTML form to allow user correction and resubmission

  • Efficient interaction with the business tier to coordinate transactions properly and meet the interface requirements imposed by the business-tier architecture without undue complexity

Client-Side Validation

Although client-side validation is not strictly part of the presentation-tier architecture, it s commonly used, and it s important in the overall design of the view-to-model transfer process. Users expect form pages to warn them if required fields are left blank or inconsistent selections are made, without requiring a round trip to the server. You can apply client-side validation techniques in a light manner, perhaps checking only for required fields, or your design can include heavier levels of validation, such as checking fields for valid formats and content consistent with other fields.

Client-side validation is almost universally performed with JavaScript code that is executed just before submitting the form contents to the target. Errors are often displayed in a JavaScript alert window, and the cursor is placed in the offending field. A detailed examination of the mechanisms for providing client-side validation is beyond the scope of this book.

You should recognize that including client-side validation of fields in your application does not eliminate the need for server-side validation of the same required fields and formatting rules. Users may turn off JavaScript in their browsers or bypass the validation in other ways, causing invalid data to be passed to the server for processing.

Best Practice  

Use client-side validation to enhance the usability of the application, but do not rely solely on it for field validation. Perform the same validation in the server-side processing.

Remember that all fields appearing on the HTML form are visible to the user if he or she looks at the HTML source, so creating spurious form submissions with bad input data or even different hidden field values is a trivial matter for someone who wants to bypass your validation and security requirements. Design accordingly .

Extracting Form Data

The HTML form data is presented to the server-side processing component, normally a servlet or JSP page, as a series of parameters in the HttpServletRequest object. The first step in server-side processing is normally extracting the form data and placing it in an intermediate Java object appropriate for server-side validation and subsequent transfer operations. The type of Java object is determined by the presentation-tier architecture, but it is often a simple JavaBean, Value Object, or other straightforward data structure. Normally the form data is not extracted directly into a model object if the model is implemented using EJB components because of the overhead of creating and discarding temporary entity beans.

Note that you can perform most server-side validation by examining the HttpServletRequest parameters themselves without first extracting the data to an intermediate object, but this direct-inspection technique has at least two negative effects:

  • Directly examining request parameters places the validation logic in the presentation-tier component itself rather than encapsulating the validation rules in an object used exclusively for this purpose. Many server-side validation rules involve multiple form fields and their interrelationships, and this logic is best encapsulated in the object containing all the attributes.

  • If errors are encountered during server-side validation, the intermediate object plays a valuable role in preserving the original form input data for redisplaying it to the user. Without this object, it can be difficult to redisplay the HTML form properly to the user. We ll discuss this requirement in more detail in a moment.

    Best Practice  

    Extract HTML form data to a special-purpose intermediate object before performing server-side validation to improve encapsulation and assist in redisplaying the form data in case of validation errors.

You can extract HTML form data with an ugly and error-prone process of retrieving the parameter values field by field from the HttpServletRequest and placing them in the corresponding attributes of the intermediate object using code like this:

 person.setLastName(request.getParameter("lastName")); 

Instead, the presentation tier should provide helper methods or standard techniques for extracting form data and placing it in the intermediate object. One example is the < jsp:setProperty .../ > element discussed in Chapter 1. An asterisk in the property attribute signals that the run-time processing should use reflection to examine the HttpServletRequest and call set methods on the bean for each matching parameter in the request.

Server-Side Validation

Once the HTML form data has been placed in an intermediate object, the presentation-tier components should perform server-side validation to identify problems with the incoming data, collect all of the resulting error messages, and display them to the user. Server-side validation should include simple required-field checks as well as all formatting validation, interrelated field rules, and foreign-key constraints.

Do not use the database constraints to perform input validations. The database may very well have the same validation rules embedded in constraints, but you should not use these constraints as the primary line of defense against such data errors. Catching the problems during server-side validation will avoid starting and rolling back transactions in the business tier of your application. This will improve system performance and reduce database-related exceptions, which might mask or be confused with true errors needing attention during testing or production operation.

Best Practice  

Perform all server-side validation in application code rather than by relying on database constraints. This improves performance and reduces confusion during testing.

Don t stop performing server-side validation upon encountering the first error. The validation process should collect all errors encountered and make them available for display to the user for input correction and resubmission, as discussed next.

Best Practice  

Server-side validation should collect and return all errors encountered in the submitted data rather than stopping with the first error. This provides a clearer picture of the validation requirements and reduces user frustration.

Displaying Errors

Errors discovered in server-side processing must be sent back to the client for display. This is easier said than done because users expect to see the original form and input data along with the error messages. The presentation-tier architecture must therefore include a mechanism for displaying the errors on the original HTML form and allowing resubmission through the same validation process.

Note that normally the input data is not contained in a model object yet, so the redisplayed form cannot simply be an instance of the typical HTML form display of a model object (a requirement outlined earlier in this chapter). Instead, you need to display the input data submitted during the previous iteration without having created a model object. This represents a new display requirement not previously identified because previously you always displayed the contents of a model object in the HTML form. How the presentation tier preserves the submitted input data and makes it available for the redisplay of the HTML form depends on the architecture.

The error messages themselves may be presented in a separate section of the redisplayed form, as shown in Figure 2.4, or may cause individual error messages to appear near the offending fields. Other designs may present the errors as a pop-up alert window and highlight offending fields with appropriate colors or formats. The type of error display is an application-specific requirement negotiated with the users, but the presentation-tier architecture may need to support general or field-specific errors and should be selected with this flexibility in mind.

click to expand
Figure 2.4:  Typical validation error display.
Interacting with the Business Tier to Update Model Objects

Once the form data has been extracted and validated , the presentation tier must interact with the business-tier components to perform the desired object creation, update, or deletion. The details of this interaction will depend greatly on the business-tier architecture and the type of intermediate object created during HTML form extraction.

For example, if the intermediate object is serializable and the business-tier architecture leans toward a stateless-service approach, the presentation tier may simply pass the intermediate object to the business-tier services for processing. In this case, the requirement for the presentation-tier architecture is minimal beyond creating the intermediate object.

On the other hand, if the business-tier architecture uses entity bean EJB components as model objects, the data in the intermediate object must be transferred to the entity bean attributes in a user- or container-demarcated transaction in some tier of the application. This transfer may be performed in a business-tier component, such as a fa §ade or service that accepts the intermediate object as input and performs all the necessary steps, in which case the presentation tier again doesn t have much to do. If the transfer from intermediate object to entity bean is a requirement of the presentation tier, however, it does represent a significant design requirement for the presentation-tier architecture.

Confused? It boils down to this: Depending on the specifics of the business-tier architecture and interfaces, the presentation-tier requirements may include more or less work associated with preparing the model objects for update. You need answers to questions such as these:

  • Does the business tier provide a set of services using simple beans or data structures as parameters? Can you use the same beans or structures for the intermediate objects used during parameter extraction and server-side validation?

  • Must the presentation tier coordinate transactions and transfer data directly to entity-bean model components? Can the business tier provide a fa §ade or service that performs this task?

You must consider business-tier and presentation-tier architecture together to produce a good, efficient design. A key goal is to provide the right level of separation and encapsulation of the work required to perform the overall HTML form-to-model object transfer process without requiring numerous extra bean objects and hundreds of lines of related get/set transfer code. Don t lose sight of this goal in your zeal to minimize coupling between the tiers or create reusable services.

Best Practice  

Presentation-tier architecture requirements depend on the business-tier architecture and interfaces. Design the overall architecture with the requirements of both tiers in mind to avoid unnecessary complexity.

Obviously, the presentation-tier architecture is a little more complicated than just some JSP pages and a servlet for handling forms. The next few sections will round out the presentation-tier requirements.

Navigation Requirements

The previous sections outlined the requirements for the presentation of model data and the processing of form submissions as an isolated event. But in a large Web application, the individual search pages, results pages, model display pages, HTML forms, and other pages are all connected to form the overall Web site. Users navigate through the Web site performing the desired activities and receiving the proper display pages by clicking on appropriate hyperlinks or navigation-control elements in the site. These navigation activities impose significant requirements on the presentation-tier architecture.

Defining the related presentation-tier requirements depends less on how navigation is accomplished visually than on the answers to questions such as these:

  • How are these navigational controls and links established? Does each page have hard-coded links representing all of the paths available to the user?

  • Will individual pages or sections of pages be reused in multiple areas of the current application or in other applications?

  • Does the presence or absence of navigation links depend on some state in the system, such as an attribute of a model object or the identity of the user? Where are these rules implemented?

  • On which page does the user end up after submitting a form and performing a processing step? Is this target page hard-coded in the processing component? How is branching logic that depends on the outcome of the processing implemented?

  • Does the site guard against multiple form submissions and improper use of the back/forward capability of browsers? Can the user safely bookmark pages deep within the site?

These are significant and involved questions. The answers applicable in your application may drive your presentation-tier architecture in many different ways and require significant infrastructure development. We ll boil these questions and issues down to three main requirements: basic navigation definition, outcome-based navigation, and submission/bookmark controls.

Basic Navigation Definition

Web applications are complex, interconnected sets of pages tied together with hyperlinks and other navigational controls. The specific target page for each link or control must obviously be specified somewhere in the architecture, but not necessarily in the JSP pages themselves. It may be more consistent with good maintainability and flexibility to defer the actual page name definition to some other component in the presentation-tier architecture.

Consider the following example snippet from a display JSP page that establishes a simple link to edit a particular person:

 ...  Display person elements ... <a href=EditPerson.jsp?id=...>[Edit]</a> 

The target page, EditPerson.jsp , is hard-coded in the JSP page, making it painful to change the name of the target page without affecting every page that links to this target page. Reusing this display page elsewhere in this application or subsequent applications is also made more difficult. The coupling between pages is strong and implemented in the pages themselves.

Contrast that snippet with a different JSP snippet using a general servlet as a controller to accept requests and pass the user to the proper page:

 ...  Display person elements ... <a href=ActionServlet?action=editperson&id=...>[Edit]</a> 

The ActionServlet would receive the action parameter in the HttpServlet- Request and perform a lookup or conditional branching of some sort to determine the name of the target page, forwarding or redirecting the user to that page, as appropriate. The specific technique used to perform this activity is determined by the presentation-tier architecture.

We recommend that you use some form of controller servlet or other similar mechanism outside of the JSP pages themselves to define basic site navigation. Therefore, the presentation-tier architecture must enable and support this capability.

Best Practice  

Avoid hard-coding navigational links and controls in JSP pages. Use controller servlets or other presentation-tier components to define basic navigational logic.

Outcome-Based Navigation

Defining outcome-based navigation is, in some ways, the flip side of the previous section. In the previous section, the navigational information was removed from the JSP pages and placed in a controller layer of some sort. In this section, the outcome of a processing step defines the next page displayed for the user, and this navigational information too must be removed from an inappropriate place and delegated to the controller layer.

For example, a processing step that creates new users on the site may want to send a user to the CreationComplete.jsp page if the creation was successful and to the CreationProblem.jsp page if not. Where are these specific page names defined in the application? The name could be embedded in the processing component itself, as indicated by the following code snippet:

 public void service(HttpServletRequest request,                      HttpServletResponse response)      throws ServletException, IOException {     ...     boolean result = service.createUser(userinfo);     String nextpage =          (result ? CreationComplete.jsp : CreationProblem.jsp);     RequestDispatcher disp = request.getRequestDispatcher(nextpage);     disp.forward(request, response); } 

In this crude example, the processing servlet will forward control depending on the outcome of the call to the service. Clearly, the hard-coding of the target pages in the servlet affects the maintainability and reusability of this component, making the coupling with the JSP page names and locations very strong. Although the controller or processing servlet is the right layer to determine the target page, hard-coding the names in the servlet is not appropriate.

We recommend that navigation information that depends on outcomes of processing steps, model object states, or other branching conditions should be defined in the controller layer using an external definition mechanism, such as a properties file or XML descriptor, to define the target page names. This minimizes coupling between controller-layer components and the display pages and allows for efficient maintenance and reuse of both controller and display components.

Best Practice  

Avoid hard-coding page names in controller servlets and other components. Use an external file or descriptor to define page names based on outcomes or branch conditions.

Submission/Bookmark Controls

It s a common lament for Web application designers: Site development would be easy if it weren t for the users! Users will explore every corner of the site, set and use bookmarks deep in the site, and make use of the Back and Forward functions of their browsers with wild abandon. Be prepared for the worst!

Although a complete discussion of this topic is beyond the scope of this book, there is at least one concrete requirement that you should impose on the presentation-tier architecture: The site must guard against multiple submissions or out-of-order submissions of HTML forms. Users may, by accident or intent, submit a form one time and perhaps continue to navigate through the site, then back up to the HTML form page again, and resubmit the form with the same or modified data. How will your site react if the form was used to place an order or create a new record?

Solutions to this problem vary from architecture to architecture, but they normally employ some form of token or timestamp in the form that is good for only a single submission. Preventing multiple form submissions and handling them properly when they occur represent important requirements for the presentation-tier architecture.

Best Practice  

Include safeguards in your presentation-tier components to prevent erroneous form submissions and handle user bookmarking and back/forward navigation properly.

We ve barely scratched the surface of issues related to navigation definition and the handling of special situations and conditions caused by user activity. Clearly, additional requirements might affect the presentation-tier architecture, such as support for navigation bars or menus, security-based navigation behavior, customizing navigation on a per-user basis, and many others. The important thing to note is that achieving good maintainability and reusability of presentation-tier components imposes significant requirements on the presentation-tier architecture, which must be taken into consideration during architecture selection and design.

Building a Presentation-Tier Architecture

The preceding sections identified a number of important requirements imposed on the presentation-tier architecture based on typical user-interface requirements and good design principles. These requirements represent a tall order for any architecture and may seem somewhat daunting at this point.

Fortunately, you don t have to build a presentation-tier architecture from scratch unless you feel compelled to do so. Some kind folks in the open -source community have already built it for you; it s called Struts.

We need to finish up our general discussion of the presentation-tier architecture selection process with a few additional items, and then we will present a brief comparison of a typical hand-made presentation-tier architecture and the Struts architecture using the requirements discussed so far as the basis for comparison.

Other Architecture Considerations

Requirements imposed on the presentation-tier architecture are important but are not the only considerations that affect the selection or design of an architecture. Essentially, the requirements specify a minimum set of behaviors for the presentation tier but do not actually define the solution. The solution itself should take into account other factors, such as the following:

  • How important is the separation of roles between so-called creative resources working with site visual design, page layout, and overall look and feel and the J2EE development resources? Is JSP scriplet code completely off limits or simply discouraged and replaced with jsp:useBean elements or custom tags where possible?

  • What is the experience level of the J2EE development team? What about the team expected to perform ongoing maintenance and enhancements after the application rolls out? There is almost always a trade-off between flexibility and maintainability of the design and the apparent complexity of the original development. Find the right balance.

  • Does it make sense to impose requirements such as the elimination of hard-coded navigation links based on the site size, need for reuse, and other factors? Can a compromise set of rules be established that mandates the use of controller navigation control in some areas but not others?

  • Will performance be adversely affected by presentation-tier design decisions? Creating additional layers in the architecture and steps in processes such as form submission have a performance cost associated with them. Weigh this cost against the benefits of the additional design elements to justify the design.

  • Is the design consistent with WebLogic Server clustering and other production-environment deployment practices and options? Don t preclude the use of clustering through some design feature or assumption, for example, or assume that the Web application will always be collocated with the EJB components if this is not true.

In the end, the presentation-tier architecture design or selection process comes down to a judgment call based on all of the available information and requirements. There is no single correct answer or even a set of hard-and-fast rules to go by. What makes sense for one application or development team may not make sense for a different development effort.

One fact remains: The presentation tier defines the behaviors closest to the user, and because of this it is subject to the highest variability of inputs, must react to the need for constant change, and can make or break your development effort. Don t rush the design decisions or jump on any given framework bandwagon unless you understand the details and have a clear picture of the costs and benefits for your application.




Mastering BEA WebLogic Server. Best Practices for Building and Deploying J2EE Applications
Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
ISBN: 047128128X
EAN: 2147483647
Year: 2003
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net