Introduction

History

HTML and the HTTP protocol were originally designed as a way of presenting, and hyperlinking, static documents (resources) on the Internet. A URL (Uniform Resource Location) such as www.example.com/foo/bar.html identifies a resource /foo/bar.html on host www.example.com. When dealing with static content, the resource path almost always corresponds to a relative path on the host's file system.

However, as the Web developed, users clamoured for a more dynamic, interactive experience. Rather than simply serve static documents, Web servers would now be expected to respond to users; serve them pages personalised to their preferences, and respond to information POSTed. To handle this, the original National Centre for Supercomputing Applications httpd server introduced the Common Gateway Interface. A URL such as www.example.com/prog.cgi would point not to a static document, but to an executable program. A standard interface would allow the program to read information about the HTTP request, and provide a response, which would be sent back to the client.

The Problems

CGI defines, as its name implies, an interface between programs (usually written in Perl or C) and the web server. It does not address the problems which web development presents over traditional desktop development:

• HTTP is a stateless protocol. In its typical implementation, there is is no way to preserve state between requests; a POST cannot set variables for use by a subsequent request.
• Websites are client/server, with a high latency (and unreliable connection) between the browser and web server. All the executable code and data resides on the server. (This is not strictly true; Javascript, flash, and other technologies run on the client. However, in the real world, these are typically inappropriate to anything other than improving the user interface.)
• Users can move back through their browsing history at any time, or duplicate the page into a new window/tab, and follow a different path in each.
• Users may bookmark a web page for later viewing. This captures only the URL used to request it; any state being held by the server may be lost. These last two points effectively allow users to sprinkle code with arbitrary GOTOs and concurrency.

The Solutions

A variety of solutions exist to some or all of these problems, spanning the full range from simple CGI libraries to the colossal JEE. These Web Application Frameworks are the subject of this study.