Power JavaTechniques for Optimizing Web Site Development and Runtime Characteristics
WEB DEVELOPERS FACE many challenges building and maintaining high-performance, flexible, adaptable Web sites. In this article, I demonstrate how to improve Web site development and runtime characteristics through a process that encourages effective analysis and documentation. I first introduce a useful framework design and implementation to improve Web site navigation and maintenance. I then discuss how to use the framework to increase Web site flexibility by overcoming some well-known HTML and Web browser limitations. Finally, I present a few implementation tips and tricks to optimize the runtime performance of the framework participants.
Introducing the Web Director Framework
Let's begin this discussion with an analogy to the movie-making process (see Table 1). All movies begin with a well-defined storyboard developed by a storyboard artist. The storyboard describes the stages, actors, and scenes of the story. Similarly, all good Web sites begin with a well-defined storyboard typically documented during the inception or planning phase of software development.
|Table 1. Movie analogy.
||HTML Container (Frame, Window)
||End-User Selected Action
||Web Site Premier
The next step in the movie-making process is to develop a pilot to provide an animated version of the storyboard that will convince producers to fund additional production of the movie. Similarly, the next step in the Web site development process is to create a semianimated prototype—usually a series of simple, static HTML pages—to convince venture capitalists and other potential shareholders to fund additional development of the site.
A movie pilot typically involves an initial, critical piece of the overall story and involves every component of a movie—e.g., stages, scenes within those stages, actors within the scenes, and the actions performed by those actors. A Web site prototype also displays an important piece of functionality using such interactive equivalents as HTML frames, HTML documents, end-users, and end-user actions.
Once the high-level storyboard and pilot have been approved, more detailed stages, scenes, actors, and interactions need to be defined. For example, scriptwriters define the more detailed interactions of the actors in a document called the script. This detailed analysis and design typically occur in the elaboration, or requirements-gathering phase of Web site development. In this phase, developers build on the storyboard and prototype from the inception phase to define the complete end-user navigation in a document called the script. A simple script defines navigation from one scene (Login) to the next scene (Home) based on a user-selected action (LoginAction) and the result of the action (LoginSuccess). While more complex rules typically define navigation, the example discussed in this article involves a simple storyboard and script for a simple e-commerce order-entry Web site.
While a movie actor follows the script through various scenes with the guidance of the movie director, a Web site end-user can move freely through the various HTML documents with the guidance of the Web director framework.
Our storyboard is documented using a UML state diagram (see Figure 1).
Figure 1. Storyboard using a UML state diagram.
The analyst uses a UML state diagram to break down a site into a series of abstract components (see Table 2) including scenes (states), actions, action results, and transitions (state transitions). An example of a scene is the OrderEntry scene. Each scene exposes a collection of available actions, such as SubmitOrderAction and CancelOrderAction. If SubmitOrderAction succeeds (represented by the state transition arrow labeled "SubmitOrderAction: Success"), the user is directed to the OrderAck scene. However, if SubmitOrderAction fails because of a validation or other recoverable error (represented by the state transition arrow labeled "SubmitOrderAction: RecoverableError"), the user is directed back to the OrderEntry scene. The combination of current scene, action, and action result defines a transition within our movie analogy. Each selected transition leads the user to the next appropriate scene (e.g., OrderAck). The script determines available transitions. The result of the user-selected action determines the User-selected transitions (see Figure 2).
|Table 2. Glossary.
||A scene is a state within the Web site flow defined by a name, a URL of an HTML document, and a stage.
||A stage defines the container within which the scene is displayed.
||the frame labeled "main" within the browser
||An action represents the user's chosen action from a particular scene. An action is generated by events such as a button click, drop-down select, radio-button select, or check-box select.
||Every action generates an ActionResult.
||A transition is the combination of the current scene, the user-selected action, and the action result. Each scene leads the user to the next scene through a transition.
||see Figure 2
Figure 2. Selected transitions.
The developer can now create a script based on the storyboard in Figure 2. The script describes the details of each scene, including scene name, URL of the HTML document, and available transitions. A DTD and XML version of the script is presented in Listings 1 and 2, respectively.
Implementing the Web Director Framework
The Web director implementation is broken up into two areas: the client and the server. Let's start with the server implementation because it is needed by the client implementation. (Note: The server implementation can be used by itself.)
The core component of the server-side Web director is called NavigationFacility. This component uses the script defined earlier to guide the user through the various scenes based on user-selected actions.
NavigationFacility (see Figure 3) improves site maintenance by enforcing a centralized script. Many developers are tempted to defragment and hard-code site navigation into a collection of hidden fields throughout many pages within the site (e.g., NEXT_PAGE="Home.jsp", ERROR_PAGE="FatalError.jsp"). This complicates Web site configuration and maintenance because navigation is fixed and decentralized across multiple pages and tiers. As the Web site navigation evolves, a Web-director-enabled site requires modifications to the central script rather than to many pages throughout the site—reducing the potential for navigational errors. More advanced implementations of NavigationFacility would allow the script to refresh itself at runtime when changes are made, without having to restart the server. This is sometimes called a hot deploy.
Figure 3. NavigationFacility class diagram.
The implementation should ensure that only one copy of the script is loaded into each server's memory, because scripts can grow very large in size.
Servlets are the next key component of the server-side Web director framework. The responsibilities of the servlet layer include adapting the HTML form data to the domain model, calling appropriate business process methods, populating the HttpSession if necessary, and using the NavigationFacility to redirect the user to the next scene.
When developing such servlets, a good practice is to define cohesive and decoupled servlets that are responsible for related business process methods. These methods ultimately correspond to the available actions of the scenes. The OrderEntryServlet, for example, exposes the submitOrder() and cancelOrder() methods that correspond to the SubmitOrderAction and CancelOrderAction actions of the OrderEntry scene.
Figure 4 uses a UML sequence diagram to describe the scene transition flow of a "submit order" button click through the server-side Web director framework. The OrderEntryServlet first creates an Order object from the HTML form data using the createOrderFromHTMLForm() method. Next, the submitOrder() business is called based on the value of the "navAction" hidden field—set by the SubmitOrder button click in the OrderEntry HTML form (see Listing 3). The result of this business method invocation, a submitted order, is then placed into the session to be used by the next scene. Finally, the servlet uses NavigationFacility (and the script) to redirect the user to the OrderAck scene (see Listing 4). This process is known as selecting a transition.
Figure 4. Selecting a transition.
Overcoming HTML and Browser Limitations
The second limitation is called the "Predetermined TARGET Window" problem. This is a limitation in flexibility because an HTML form requires that you define the TARGET window of your form ACTION before the action result is determined and your next scene is chosen. This forces the developer to work within the same window regardless of the outcome of the transition selection. For instance, the script may dictate that if the SubmitOrderAction is successful, the next scene, OrderAck, is displayed in the "top" frame. However, if the action fails, the next scene, OrderEntry, is displayed in another stage—the "top.main" frame. Without a work-around, this is not possible, because the TARGET is determined by the HTML form before the next transition is known.
To overcome these limitations using the Web director framework, I introduce a level of indirection in the browser using an invisible, hidden "buffer" frame of width or height equal to 0 (see Listing 5).
The WebDirectorHelper.jsp and invisible buffer frame combination solves the "Predetermined TARGET Window" problem as well by deferring the choice of the next stage until after the next scene is known and control returns back to the browser.
The implementation of the WebDirectorHelper is straightforward and lightweight to minimize overhead of this technique (see Listing 6). Note: This implementation assumes that the stage names are valid frames within the browser.
The following changes need to occur to the implementation presented earlier to enable these flexibility enhancements:
- Change the TARGET of all form ACTIONs to the buffer frame (see Listing 7).
- Change the sendRedirect() destination within the servlet to be the WebDirectorHelper.jsp (see Listing 8).
The interaction between the client and server Web director framework components is clear to the developer once the framework is in place (see Figure 5).
Figure 5. Selecting a transition using WebDirectorHelper.
Runtime Performance Optimizations
Performance has always been a serious challenge, particularly in the area of downloading large HTML files over slow connections (<=56 k).="" there="" are="" a="" limited="" number="" of="" effective="" html="" optimization="" techniques="" that="" reduce="" the="" size="" of="" the="" html="" document="" and="" improve="" download="" time="" and="" response="" time="" of="" a="" web="" site.="" the="" network="" bandwidth="" between="" the="" client="" and="" server="" limits="" the="" performance="" of="" a="" web="" site,="" particularly="" when="" downloading="" large="" html="" files.="" in="" addition,="" the="" processor="" speed="" of="" the="" client="" machine="" limits="" the="" performance="" of="" rendering="" the="" html="">=56>
As developers, we can only control the size of the HTML that is downloaded through the network and the amount of client-side scripting that executes in the client browser. By reducing the size of the HTML, we directly improve the response time of the application.
Consider a 1,000-line table of products being offered in the OrderEntry scene of our e-commerce Web site. The table repeats a lot of data, including the
tag and its many attributes—color, font, etc. When downloading an HTML table with a list of 1,000 items, saving just one character per item reduces the size of the HTML by approximately 1 K. Listing 9 and 10, respectively, show the before and after optimized HTML.
A cleaner, more maintainable, more acceptable way to reduce the size of an HTML scene is to use CSS to factor out the common code. The idea is to define "classes" with the common code in a separate style sheet document. The large table would then assign these classes to the
CSS was originally designed to improve site consistency and maintenance by separating the data from the presentation. In addition, CSS can improve the performance of your Web site, as many pages reuse the instance of the style class loaded once in the browser.
Listing 11 shows the CSS-optimized table. Listing 12 shows the style sheet maintained in a separate file.
The combination of XML and CSS is even more flexible, maintainable, and optimal than the HTML and CSS technique. Consider a Web page that is purely XML tags and data combined with a style sheet to format the data into a table (available only in a CSS Level-2 table formatting compatible browser).
The ultimate combination in terms of maintenance and flexibility is XML and XSL. XSL does not need to maintain HTML backward compatibility. At press time, neither Internet Explorer nor Netscape Navigator supports XSL natively.
I made the analogy between movie making and Web site development to overcome the challenges of building and maintaining high-performance, flexible, adaptable Web sites. Next, I built on that analogy by introducing a useful Web director framework to improve Web site navigation and maintenance. By overcoming some well-known HTML and Web browser limitations, I increased the flexibility of our order entry Web site. Finally, I demonstrated some implementation tips and tricks to improve the runtime performance of our Web site—the happiest ending a user could ask for.
The techniques presented here represent a typical example of the best practices continually developed at Bauhaus Technologies. For more information regarding these and other best practices, contact firstname.lastname@example.org.