Web Development with JavaServer Pages

Evolution of dynamic content technologies

For the simplest web requests, a browser requests an HTML document, and the web server finds the corresponding file and returns it. If the HTML document includes any images, the browser will in turn submit requests for the image documents, as well. As described here, all of these requests are for static files. That is, the documents that are requested never change depending upon who requested them, when they were requested, or which (if any) additional parameters were included with the request. New versions of the documents might be placed on the server, but at any given time, every request for those documents returns exactly the same results. In such cases, the web server needs only to locate the file corresponding to the requested document, and respond to the web browser with the contents of that file.

Much of the data delivered over the web today, however, is dynamic in nature. Up-to-the-minute stock prices and the latest weather reports can be viewed. A user's personal email messages and appointment calendar can be managed. Consumers can add contents to that e-commerce staple, the online shopping cart, by clicking on a picture of the item they wish to buy. All of this data is transient in nature, because the information it is based on is constantly changing, or because it must be personalized for each individual viewer, or both.

Dynamic web content, then, requires that the web server do some additional processing of the corresponding request in order to generate a customized response. In addition to the URL of the request, the form of this customized response might be dependent upon additional parameter values included with the request. Alternatively, it might be based on the date and time, the location on the network from which the request was made, or on some representation of the identity of the user making the request. Indeed, the exact details of the response might depend upon a combination of some or all of these factors.

Common Gateway Interface

The earliest HTTP servers did not include any built-in mechanisms for generating responses dynamically. Instead, interfaces were provided for calling other programs to translate requests into run-time content. The first standard for dynamic web con-tent was based on the Common Gateway Interface, or CGI, which specified a mechanism for web servers to pass request information to external programs, which were then run by the web server to generate responses at runtime. The Perl language is a popular choice for writing CGI programs, but CGI codes can be written in any language that can be called as a stand-alone program by the HTTP server. For example, a CGI program could be written in any scripting language supported by the local operating system. Alternatively, it could be written in C and compiled into native object code. CGI programs could even be written as Java applications.

When Sun Microsystems first introduced Java technology to the computing community, it was in the context of small programs, referred to as applets, which could be delivered over the Internet and run within web browsers. From the beginning, Java could also be used to write stand-alone applications, but interactive pro-grams running inside the browser certainly received most of the early attention.

Nevertheless, Java-based CGI programs first appeared shortly after Java was made available to the public in 1995. It was eventually recognized that the benefits of the Java platform applied equally as well to the server as to the client, and today server-side Java plays a prominent role in the continuing evolution of the Java platform.

The traditional CGI approach to generating dynamic content has some inherent inefficiencies, which ultimately limit its applicability to large-scale deployment of web-based applications. As indicated in figure 1.1, CGI programs run outside the web server. This means that a new process must be started to execute a CGI program. There is some overhead associated with creating and communicating with this separate process, and each process requires its own share of the local machine's memory resources. Further-more, CGI programs are designed to handle only a single request, after which they return their results to the web server and exit. This means that each time a request for dynamic content is received by the web browser, it must start a new process for running the corresponding CGI program for that specific request, send it the request information, wait for results, then pass those results back in its response to the browser. These days, it is not uncommon for popular web sites to be handling thousands of simultaneous requests, so even if the inefficiencies of individual CGI program execution are fairly small, they quickly add up to significant performance penalties.

As a result, a number of vendors have introduced new systems for dynamic generation of web content. In some cases, new HTTP servers that provide built-in dynamic content capabilities have been introduced. Today, however, the HTTP server market has come to be dominated by a small number of suppliers, making such all-in-one approaches less commercially viable. Current dynamic content systems more typically take the form of add-on code modules that leverage server-specific application programming interfaces (APIs) in order to interact directly with the web server process. By plugging in as a subprocess of the web server, these systems avoid much of the overhead associated with conventional CGI programs, and offer dynamic con-tent capabilities with much better scalability than the traditional approach.

As indicated earlier, dynamic content generation requires the server to process requests at run time in order to construct an appropriate request-specific response. Instructions are required in order to perform this processing, so at one level or another it is clear that some programming is required. As a result, many of the most popular dynamic content systems, such as Allaire's ColdFusion, Microsoft's Active Server Pages, Netscape's Server-Side JavaScript, and PHP (an Open Source hyper-text preprocessor) enable dynamic content to be specified using scripting languages. The use of scripting languages is a particularly appropriate choice here because web developers are used to rapid turnaround when testing their web pages: as soon as the HTML in a static web page is modified, the results of that change can be viewed in a web browser. By relying on scripting languages that do not require a lengthy edit-compile-link cycle before any code can be run, these dynamic content tools provide the same immediate feedback web developers have grown accustomed to with HTML.

Similarly, in recognition of the page-centric nature of web development, these tools enable scripts for dynamic content generation to be embedded directly in the web pages in which the dynamic content is to appear. The static elements of the page, governing page layout and base content, can be coded in HTML in the usual manner. Appearing alongside this static HTML in the source document are the scripts for generating the dynamic content. When the document is requested by an end user, the web server will pass along the static HTML elements, which often comprise the bulk of the page, unchanged. The scripts, however, will be turned over to the dynamic content system for execution, with the results of running these scripts embedded into the document in place of the script's original source code. Because the static HTML elements provide a framework into which the dynamic content generated by the scripts will be inserted, such tools are commonly referred to as template systems.

Applet Index
(sorted alphabetically)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z #s

The Java Source
(applets w/source code)
A B C D E F G H I J K
L M N O P Q R S T U
V W X Y Z

How to Add Java Applets to Your Site

New on the Java Boutique:

New Review:

Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it's free!

New Applet:

Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.