28 Web Application Basics
Compiled modules are an efficient, suitable solution for high-volume applica-
tions. The biggest drawbacks are related to development and maintenance. These
modules usually combine business logic with HTML page construction. The modules
often contain many print lines of HTML tags and values, which can be confusing and
difficult for a programmer to read.
The other problem is that each time the module needs to be updated, or fixed, the
Web application has to be shut down and the module unloaded. For most mission-critical
applications, this is not much of a problem; the rate of change in the application
should be small. Also, it’s likely that a significant effort would have been made by the
QA/test team to ensure that the delivered application was free of bugs. For smaller,
internal intranet applications, however, the rate of change might be significant. For
example, the application might provide sets of financial or administrative reports. The
logic in these reports might change over time, or additional reports might be requested.
The other category of solutions is scripted pages. Whereas the compiled-module
solution looks like a business logic program that happens to output HTML, the
scripted-page solution looks like an HTML page that happens to process business
logic. A scripted page, a file in the Web server’s file system, contains scripts to be
interpreted by the server; the scripts interact with objects on the server and ultimately
produce HTML output. The page is centered on a standard HTML Web page but
includes special tags, or tokens, that are interpreted by an application server. Typically,
the file name’s extension tells the Web server which application server or filter should
be used to preprocess the page. Some popular vendor offerings in this category are
JavaServer Pages, Microsoft’s Active Server Pages, and PHP.
Figure 2-5 shows the relationship between components of the enabling technol-
ogy and the Web server. The database in the figure, of course, could be any server-side
resource, including external systems and other applications. This figure shows how
the compiled-module solution almost intercepts the Web page requests from the Web
server and in a sense acts as its own Web server. In reality, the compiled module must
be registered with the Web server before it can function. Nonetheless, the Web server
plays only a small role in the fulfillment of these requests.
The scripted-page solution, however, is invoked by the Web server only after it
has determined that the page does indeed have scripts to interpret. Typically, this is
indicated by the file name extension:
.aspx, .jsp, .php. When it receives a request
for one of these pages, the Web server first locates the page in the specified directory
and then hands that page over to the appropriate application server engine, or filter.
The application server preprocesses the page, interpreting any server-side scripts in
the page and interacting with server-side resources, if necessary. The results are a
properly formatted HTML page that is sent to the requesting client browser.
Even though JavaServer Pages are scripted, they get compiled and loaded as a
servlet the first time they are invoked. As long as the server page doesn’t change, the
Web server will continue to use the already compiled server page/servlet. This gives
JavaServer Pages some performance benefits over the other scripted-page offerings.