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 Sun ONE Studio 5 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 a web server. When the web server receives the request, it passes the request to a web application that is running inside a servlet container. The JSPs and servlets that are in the web application process the request and generate a response. The server sends the response back to the browser.
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 sample web application. This sample application uses a front controller. Front controllers are explained in Chapter 3.
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. Chapter 2 provides more detailed explanations of the components in this illustration.
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 instead of having to perform upgrades on all the clients.
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 and Executing on External 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 that a web application shares data among its components differs from a traditional application. A web application's components (JSPs, servlets, and so forth) cannot communicate directly with each other. Instead, a component shares data with other components through attributes (name/value pairs) that are stored with the ServletContext, ServletRequest, HTTPSession, and PageContext objects.
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. In the case of the sample web application shown in FIGURE 1-1, the request passes through the filter, a front controller servlet, the JSP file, and the filter again. 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. Each session has its own set of session data. 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. That is, a component can access a session's data only if the component is processing a request that is associated with the session. 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 on the IDE's tool for tracking HTTP requests, see Starting the HTTP Monitor.
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 and Executing on External Servers.
With web applications, 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.
The following are common coding errors:
The following are common deployment errors:
Web application data must be set through attributes (name/value pairs) that are stored with the ServletContext, ServletRequest, HTTPSession, and PageContext objects. 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. For example, one component might set the value for a "title" attribute and another component might try to get the value for a "Title" attribute. This type of error is not exposed at compile time.
If a bug causes a runtime exception, then you can easily determine where you need to set a breakpoint to see what is going wrong. However, if your problem is a blank page or missing data, identifying which component is causing the problem is not always easy. The problem might be that the front controller did not receive the data or the problem might be that the front controller is not passing the data correctly. Another reason might be that the session is not supplying some necessary data. Unless you can determine which component is the source of the problem, source-level debugging becomes a hit and miss approach. Tracking requests and looking at session attributes can help pinpoint the origin of the bug.
To determine error sources in web applications, you can use the IDE's debugging tools to do the following actions:
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 view current requests and to record these requests for later playback. Current requests persist until the current IDE session ends. Saved requests persist across sessions of the IDE until you explicitly delete 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.
Copyright © 2003, Sun Microsystems, Inc. All rights reserved.