Section 18.3. Perspective

18.3. Perspective

To better understand the interaction with servlets, let's consider the requests that come to a Web server. Web servers serve up Web pages. At first (in the early days of the Web) that just meant simple flat HTML files, along with a few image types. A Web browser would send a request to a Web server in the form of a URL, such as http://www.dom.com/file.html, which would be sent to the Web server named www at the dom.com domain. It would look up the file named file.html in its directory and send it back to the browser.

That approach worked fine, and still does today. But this only covers static Web pages, ones whose content doesn't change. Users want to get at lots more information today, not all of which has been embodied in static Web pages. Rather than require fancier browsers with more dynamic querying or other capabilities, Web servers became smarter and were able to talk to other programs that would generate HTML on the fly and send it back as the response to an incoming request. In the Java environment, this mechanism includes the Servlet and related classes.

As for requests coming from a browser, they come in two flavorsGET and POST. The GET request is a request via a URL. Simple URLs that appear as hyperlinks on a Web page are sent as GET requests. Any additional parameters appear at the end of the URL as name=value pairs separated by "&". The parameters are separated from the URL with a "?" character:

 http://www.google.com/search?hl=en&ie=ISO-8859-1&q=java 

The example URL includes three parameters:

• hl=en

• ie=ISO-8859-1

• q=java

The POST is virtually the same, except that the name=value pairs don't appear on the URL but are sent in a less visible way. The net result is the same, and the same methods can be used in the servlet to retrieve the parameters. The POST requests typically come from HTML form elements, as when you fill in the fields of a form and press a submit button (though forms can specify that the browser use GET as the submission mechanism for a particular form). The biggest advantage to posting the form is that the parameters don't appear in the URL, which is both more aesthetically pleasing and avoids problems from accidentally revisited pages or user-altered parameters.

One further twist: URLs are not necessarily literal paths to files anymore. The Web server can interpret parts of the URL as an alias for some other program. So http://www.google.com/search may not actually refer to a directory named search on the Google site, but more likely tells the Web server to use its search program. We'll discuss this more in Chapter 19.

So servlets are given requests which have come from browsers (and other Web clients), and then they respond with output. In our examples, we'll be sending HTML back. There are lots of other choices, too. Since browsers understand other formats, a servlet might also send back plain text or even image data. Another choice gaining popularity is having the servlet generate XML and then using a conversion via stylesheets to produce HTML. This allows for the formatting to be changed (e.g., to apply a new corporate look to the pages) without changing the content or the programs that generate the content.

Since a Web server (e.g., Apache Tomcat) is typically configured to run constantly, that is, to always be around, then a servlet is also always around. (The Web server keeps a reference to the class, so the class is not garbage collectedhence its persistence.) Well, "always" here means "as long as the Web server and the operating system are up and running."

An aside: Not all servlets are for Web browsing. Sometimes servlets can be used as daemons that hang around in the background doing other tasks (e.g., background processing of some database records). The browser interface, if any, may only be for the purpose of providing an administrative interface to the daemon. The administrator would then have a Web page to which to go, in order to see how many records have been processed. This page may also have buttons to reset, restart, or shut down the process. While we typically think of servlets being for the production of dynamic Web pages, here the Web pages would only be an aside to the real purpose, that of processing database records.