In the early years of the Internet, most web sites were constructed entirely of HTML pages. HTML pages are called static web pages, since they have all of their content embedded within them and they cannot be modified at execution time. As web technology became more sophisticated, web sites started to incorporate various techniques to create or modify the pages at the time of the user’s visit to the site, often in response to the user’s input. These are called dynamic pages. Today, web sites come in all kinds of styles, and most of them offer at least some type of dynamic features on their pages.
The web technologies used to create these dynamic pages include plug-in web components, such as Java Applets or Microsoft ActiveX Controls; programs to build dynamic web pages, such as CGI programs or ASP pages; and n-tier web/distributed systems based on Java Servlets and JavaServer Pages.
3.1 WHAT IS A WEB APPLICATION?
An obvious but still accurate definition of a web application is that it is an application that is accessible from the Web! A common example of a web application is a web site that provides free e-mail service. It offers all the features of an e-mail client such as Outlook Express, but is completely web based. A key benefit of web applications is the ease with which the users can access the applications. All a user needs is a web browser; there is nothing else to be installed on the user’s machine. This increases the reach of the applications tremendously while alleviating versioning and upgrading issues.
A web application is built of web components that perform specific tasks and are able to expose their services over the Web. For example, the HelloWorldServlet that we developed in chapter 1 is a web component. Since it is complete in itself, it is also a web application. In real life, however, a web application consists of multiple servlets, JSP pages, HTML files, image files, and so forth. All of these components coordinate with one another and provide a complete set of services to users.
3.1.1 Active and passive resources
One way of categorizing web resources is that they are either passive or active. A resource is passive when it does not have any processing of its own; active objects have their own processing capabilities.
For example, when a browser sends a request for www.myserver.com/ myfile.html, the web server at myserver.com looks for the myfile.html file, a passive resource, and returns it to the browser. Similarly, when a browser sends a request for www.myserver.com/reportServlet, the web server at myserver.com forwards the request to reportServlet, an active resource. The servlet generates the HTML text on the fly and gives it to the web server. The web server, in turn, forwards it to the browser. A passive resource is also called a static resource, since its contents do not change with requests.
A web application is usually a mixture of active and passive resources, but it is the presence of the active resources that make a web application nearly as interactive as normal applications. Active resources in a web application typically provide dynamic content to users and enable them to execute business logic via their browsers.
3.1.2 Web applications and the web application server
A web application resides in a web application server (or application server). The application
server provides the web application with easy and managed access to the resources of the system. It also provides low-level services, such as the HTTP protocol implementation and database connection management. A servlet container is just a part of an application server. In addition to the servlet container, an application server may provide other J2EE components, such as an EJB container, a JNDI server, and a JMS server. You can find detailed information about J2EE and application servers at http://java.sun.com/j2ee. Examples of J2EE application servers include BEA Systems’ WebLogic, IBM’s WebSphere, and Sun’s Java System Application Server.
A web application is described using a deployment descriptor. A deployment descriptor is an XML document named web.xml, and it contains the description of all the dynamic components of the web application. For example, this file has an entry for every servlet used in the web application. It also declares the security aspects of the application. An application server uses the deployment descriptor to initialize the components of the web application and to make them available to the clients.
3.2 UNDERSTANDING THE HTTP PROTOCOL
Simply put, the Hypertext Transfer Protocol is a request-response–based stateless protocol. A client sends an HTTP request for a resource and the server returns an HTTP response with the desired resource, as shown in figure 3.1. A client opens a connection to the server and sends an HTTP request message. The client receives an HTTP response message sent by the server and closes the connection. It is stateless because once the server sends the response it forgets about the client.
In other words, the response to a request does not depend on any previous requests that the client might have made. From the server’s point of view, any request is the first request from the client.
In the case of the Internet, the web browser is an HTTP client, the web server is an HTTP server, and the resources are HTML files, image files, servlets, and so forth. Each resource is identified by a unique Uniform Resource Identifier (URI). You will frequently hear three terms used interchangeably: URI, URL, and URN. Although they are similar, they have subtle differences:
• Uniform Resource Identifier—A URI is a string that identifies any resource.
Identifying the resource may not necessarily mean that we can retrieve it. URI is
a superset of URL and URN.
• Uniform Resource Locator—URIs that specify common Internet protocols such
as HTTP, FTP, and mailto are also called URLs. URL is an informal term and is
not used in technical specifications.
• Uniform Resource Name—A URN is an identifier that uniquely identifies a
resource but does not specify how to access the resource. URNs are standardized
by official institutions to maintain the uniqueness of a resource.
3.2.1 HTTP basics
An HTTP message is any request from a client to a server, or any response from a server
to a client. The formats of the request and response messages are similar and are in plain
English. Table 3.1 lists the parts of an HTTP message.
Table 3.1 The parts of an HTTP message
Message part Description
The initial line Specifies the purpose of the request or response message
The header section Specifies the meta-information, such as size, type, and encoding, about
the content of the message
A blank line
An optional message body The main content of the request or response message
All the lines end with CRLF—that is, ASCII values 13 (Carriage Return) and 10 (Line Feed).
Let’s now look at the individual structures of the request and response messages.
3.2.2 The structure of an HTTP request
An HTTP message sent by a client to a server is called an HTTP request. The initial line for an HTTP request has three parts, separated by spaces:
• A method name
• The local path of the requested resource (URI)
• The version of HTTP being used
A typical request line is
GET /reports/sales/index.html HTTP/1.1
Here, GET is the method name, /report/sales/index.html is the resource URI, and HTTP/1.1 is the HTTP version of the request.
The method name specifies the action that the client is requesting the server to perform. HTTP 1.1 requests can have only one of the following three methods: GET, HEAD, or POST. HTTP 1.1 adds five more: PUT, OPTIONS, DELETE, TRACE, and CONNECT.
GET
The HTTP GET method is used to retrieve a resource. It means “get the resource identified by this URI.” The resource is usually a passive resource. A GET request may be used for an active resource if there are few or no parameters to be passed. If parameters are required, they are passed by appending a query string to the URI. For example, figure 3.2 illustrates the initial request line for passing john as a userid.
The part after the question mark is called a query string. It consists of parameter namevalue
pairs separated by an ampersand (&), as in name1=value1&name2=value2&…&nameM=valueM
HEAD
An HTTP HEAD request is used to retrieve the meta-information about a resource. Therefore, the response for a HEAD request contains only the header. The structure of a HEAD request is exactly the same as that of a GET request.
HEAD is commonly used to check the time when the resource was last modified on the server before sending it to the client. A HEAD request can save a lot of bandwidth, especially if the resource is very big, since the actual resource would not have to be sent if the client already had the latest version.
POST
A POST request is used to send data to the server in order to be processed. It means “post the data to the active resource identified by this URI.” The block of data is sent in the message body. Usually, to describe this message body, extra lines are present in the header, such as Content-Type and Content-Length.
HTML pages use POST to submit HTML FORM data. Figure 3.3 shows an example of an HTTP POST request generated by a typical form submission. The value of Content-Type is application/x-www-form-urlencoded, and the value of Content-Length is the length of the URL-encoded form data.
A PUT request is used to add a resource to the server. It means, “put the data sent in the message body and associate it with the given Request-URI.” For example, when we PUT a local file named sample.html to the server myhome.com using the URI http://www.myhome.com/files/example.html, the file becomes a resource on that server and is associated with the URI http://www.myhome.com/files/ example.html. The name of the file (sample.html) on the client machine is irrelevant on the server. This request is mainly used to publish files on the server.
NOTE: There is a subtle difference between a POST and a PUT request. POST means we are sending some data to a resource for processing. On the other hand, a PUT request means we are sending some data that we want to be associated with a URI.
If you want to learn more about HTTP, read the specification at www.w3.org/Protocols/rfc2616/rfc2616.
3.2.3 The structure of an HTTP response
An HTTP message sent by a server to a client is called an HTTP response. The initial line of an HTTP response is called the status line. It has three parts, separated by spaces: the HTTP version, a response status code that tells the result of the request, and an English phrase describing the status code. HTTP defines many status codes; common ones that you may have noticed are 404 and 500. Here are two examples of a status line that could be sent in the response:
HTTP/1.1 404 Not Found
HTTP/1.1 500 Internal Error
When the browser receives a status code that implies a problem, it displays an appropriate message to the user. If some data is associated with the response, headers like Content-Type and Content-Length that describe the data may also be present.
A typical HTTP response looks like this:
HTTP/1.1 200 OK
Date: Tue, 01 Sep 2004 23:59:59 GMT
Content-Type: text/html
Content-Length: 52