| Building Web Components |    
|
| Building Web Components |
|
| C H A P T E R 1 |
|
Addressing the Challenges of Web Application Development |
This chapter introduces web applications and discusses how they differ from standalone desktop applications you might have developed previously. It then explores the ways the Forte for Java 4 IDE helps you to build these applications.
A web application is a collection of web components. It provides features to end users through an interface typically presented in a web browser. Examples of web applications might include an electronic shopping mall or auction site. A web application is based on a client-server model. In this model, the client is the web browser, and the web server is the feature set that runs remotely.
In the simplest form of a web application, the browser is the client. The browser sends requests to JSP pages and servlets. When the web server receives the request, it generates a response that is eventually sent back to the browser. The web server passes on the requests to a servlet container, which manages the web application.
FIGURE 1-1 shows the relationship of the requests and responses to filters, servlets, and JSP pages and of session data to servlets and JSP pages in a web application.
[ D ]
Web applications consist of a varied set of interrelated web components. This set includes JSP pages, servlets, and tag libraries that work together. Resources utilized within the web application must be coordinated using a deployment descriptor file. This file contains the meta-information that describes the web application. The servlet container translates JSP files into servlets in order to run them in the web server.
Two key characteristics distinguish web applications from standalone applications:
As shown in FIGURE 1-1, the web server is the center of the action. Information storage and database access all take place in the server.
When you implement a project as a web application, it is easy to deploy and maintain. Since the application resides on a server, users do not need to install any software on their own computers. Moreover, upgrades are performed in one place by the server administrator.
In addition, the architecture of a web application can make the creation of reusable components easier. They are more loosely coupled than components in a standalone desktop application.
In a stand-alone application, the components can interact directly with one another. For instance, data objects can each have a specific type and are passed from method to method. In addition, data representation, data flow, and data processing are all managed by the application itself. For example, in a wizard, each pane is part of the application with direct access to application data. Developers focus on the data and features within their applications. Hence, they do not need to understand the runtime environment, that is, the virtual machine.
On the other hand, in a web application, web components are more encapsulated than their standalone counterparts. Web components communicate with one another through the servlet container. Data is passed as strings. Hence, information can travel safely among the cooperative processes of the client browser, web server, and servlet container. When creating a web application, developers need to understand variations among execution environments. Testing must take place on multiple browsers and, sometimes, on multiple web servers. Actual file locations and structures vary, as do steps to deploy the web application. Deployment onto servers and execution are typically time-consuming tasks.
Everything in a web application executes in the server rather than in the client browser. Therefore, web applications face associated challenges and rely on the HTTP protocol for support.
As shown in FIGURE 1-1, data representation, data flow, and data processing are distributed among the browser, servlet container, and individual web components. See Common Errors in Web Applications for how this situation affects compile time, runtime, and debugging tasks.
In distributed web server situations, the servlet container must be dispersed among the web servers running on multiple machines. Furthermore, session information must be shared to process requests from a single client browser encountering different server instances.
To improve productivity and deliver the benefits of web application implementation, the IDE addresses the web application developer's unique challenges. The full web component support, execution support, debugging and monitoring tools, deployment support, and open runtime environment integration provided by the IDE are discussed in this section.
The IDE provides the following features to support the full set of web components:
The IDE supports web application execution in the following ways:
For details, see Test Running Web Modules on the Internal Tomcat 4.0.1 Server and Executing on Tomcat Servers.
A web application's data management is distributed among its components. Many of the bugs captured at compile time in standalone applications must be tracked at runtime in web applications. This situation leads to an increased focus on runtime testing during the debugging of web applications. The IDE provides source-level debugging for JSP pages, servlets, and helper classes. HTTP requests received and generated by the web server are captured. These features aid in the debugging and monitoring of data flow in your web application. For more information, see Debugging Web Applications.
The way a web application shares data among its components differs from a traditional application. Web applications use a message-based approach. They also utilize resources that cannot communicate directly, but share access to objects by setting them as attributes.
As shown in FIGURE 1-1, data moves as an HTTP request from the client browser to the web application. Information then moves back through an HTTP response. When the request enters the servlet container from the client, a response is created. Then both the request and the response are available until the request processing is complete.
An HTTP request is a message created in the client browser. Headers with user settings, including locale information, and cookies from the client browser are contained in the request. The web server routes the request to the servlet container. The request passes through the Front Controller servlet, the JSP file, and the filter. Additional information can be obtained and possibly modified in all these locations. The HTTP request finishes when the JSP file and filter processing is complete. For more information on Front Controllers, see Front Controllers.
An HTTP response is a message created in the servlet container. The message contains attributes, including cookies, headers, and output, which eventually go to the client browser. Response processing also occurs in a Front Controller servlet, in a JSP file, and in a filter. Information from the request can be accessed and possibly modified, and information can be added to the response. When the request is finished, the web server routes the response from the servlet container through the web server. Its final destination is the client browser. For details, see Servlet-Generated HTTP Responses.
Requests from a particular client can be associated with one another. This connection is achieved using an HTTP session. An HTTP session is a conversation spanning multiple requests between a client browser and a web server. The JSP file and the servlet have access to the session data as well as information in the request and response. The session data resides in the session scope. For details, see HTTP Sessions.
Servlet filters are web components that can be used to inspect or modify the HTTPRequest and HTTPResponse objects before and after the requested servlet or JSP file has been processed. For more on this use of filters, see Processing HTTP Requests and Responses.
In traditional applications, source-level debugging can be used to follow interfaces among objects. This technique is also helpful in web application development. However, a need for a debugging tool that can operate at the component interface level is indicated as well. Here HTTP messages are passed between the client and the web server to isolate the component with an error. At this point, you can typically find the error through code inspection. For details, see Common Errors in Web Applications. For details the IDE's tool for tracking HTTP requests, see Using the HTTP Monitor to Debug a Web Application.
Because web applications consist of multiple resources, the various web components must be associated and registered in a deployment descriptor. As described previously, much of the process of coordinating web application resources is automated in the IDE.
The IDE provides deployment support with the following features:
The IDE provides support for executing your web application on multiple servers. It offers deployment direct from the source within the IDE using an API-based mechanism to integrate with third-party servers. For details, see Test Running Web Modules on the Internal Tomcat 4.0.1 Server and Executing on Tomcat Servers.
All web application data is set and retrieved through String keys. Hence, errors are frequently introduced during the flow of data from one component to another. Source-level debugging is useful for following programming logic within a component of a web application. However, it does not provide a way to view data passing among components. You should not need to debug the servlet container code within the web server.
Problems arise from web components not receiving the proper data. Difficulties also occur when a request does not get the server into a particular state. Common sources of bugs in web applications include coding errors and deployment errors.
Because of the nature of web applications, JSP pages and servlets rely on the client browser and the servlet container. As users access different parts of the application, the browser and servlet container handle data. Application resources are identified through string names. User input comes in as string request parameters. Data is maintained in attributes on the request or the session. These attributes are also identified through string names. Identification of resources through string names proves to be an error-prone mechanism. For instance, typing errors not caught at compile time can cause behavior that is difficult to debug at runtime.
Coding errors usually include:
Deployment errors typically include:
To determine error sources in web applications, debugging tools should:
Debugging web applications involves identifying the components sharing the data, debugging the code, and working with the deployment process. The IDE provides the following features to facilitate your efforts:
The built-in HTTP Monitor provides a way to track current requests and saved requests. Current requests persist until the current IDE session ends. Saved requests persist across sessions of the IDE until the user explicitly deletes them.
You can use the HTTP Monitor tool to identify where in the sequence of data flow an error has recurred. Often the problem is not in processing of a JSP file but in specifying an input parameter.
The Monitor displays all messages sent between the client browser and the web server, along with relevant context information. This feature helps identify inconsistencies. It also enables you to find information that has been incorrectly passed from one component to another. For details, see Viewing Monitor Data Records.
The Monitor records both incoming and outgoing cookies on a request making it easier for you to view that information.
TABLE 1-1 summarizes the features that distinguish the IDE's support for key web development needs, as described earlier in this chapter.
| Building Web Components | 816-4337 |
|
Copyright © 2002, Sun Microsystems, Inc. All rights reserved.