| After Marty wrote the first edition of Core Servlets and JavaServer Pages , various of his non-software-savvy friends and relations would ask him what his book was about. Marty would launch into a long, technical discussion of Java, object-oriented programming, and HTTP, only to see their eyes immediately glaze over. Finally, in exasperation, they would ask, "Oh, so your book is about how to make Web pages, right?" "Well, no," the answer would be, "They are about how to make programs that make Web pages." "Huh? Why wait until the client requests the page and then have a program build the result? Why not just build the Web page ahead of time?" Yes, many client requests can be satisfied by prebuilt documents, and the server would handle these requests without invoking servlets. In many cases, however, a static result is not sufficient, and a page needs to be generated for each request. There are a number of reasons why Web pages need to be built on-the-fly : -
The Web page is based on data sent by the client. For instance, the results page from search engines and order-confirmation pages at online stores are specific to particular user requests. You don't know what to display until you read the data that the user submits. Just remember that the user submits two kinds of data: explicit (i.e., HTML form data) and implicit (i.e., HTTP request headers). Either kind of input can be used to build the output page. In particular, it is quite common to build a user-specific page based on a cookie value. -
The Web page is derived from data that changes frequently. If the page changes for every request, then you certainly need to build the response at request time. If it changes only periodically, however, you could do it two ways: you could periodically build a new Web page on the server (independently of client requests), or you could wait and only build the page when the user requests it. The right approach depends on the situation, but sometimes it is more convenient to do the latter: wait for the user request. For example, a weather report or news headlines site might build the pages dynamically, perhaps returning a previously built page if that page is still up to date. -
The Web page uses information from corporate databases or other server-side sources. If the information is in a database, you need server-side processing even if the client is using dynamic Web content such as an applet. Imagine using an applet by itself for a search engine site: "Downloading 50 terabyte applet, please wait!" Obviously, that is silly; you need to talk to the database. Going from the client to the Web tier to the database (a three-tier approach) instead of from an applet directly to a database (a two-tier approach) provides increased flexibility and security with little or no performance penalty. After all, the database call is usually the rate-limiting step, so going through the Web server does not slow things down. In fact, a three-tier approach is often faster because the middle tier can perform caching and connection pooling. In principle, servlets are not restricted to Web or application servers that handle HTTP requests but can be used for other types of servers as well. For example, servlets could be embedded in FTP or mail servers to extend their functionality. And, a servlet API for SIP (Session Initiation Protocol) servers was recently standardized (see http://jcp.org/en/jsr/detail?id=116). In practice, however, this use of servlets has not caught on, and we'll only be discussing HTTP servlets. |
