Application servers did not always play a prominent role in web site architectures.
The earliest web sites were focused almost exclusively on delivering content to their users, in the form of static web pages. The content of the web site was structured as a series of predefined web pages, stored in files. A web server accepted requests from user browsers (in the form of HTTP messages), located the particular page(s) requested, and sent them back to the browser for display, again using HTTP. The web page contents were expressed in HTML, the HyperText Markup Language. The HTML for a given page contained the text and graphics to be displayed on the page, and the links that supported navigation from this page to others.
It didn’t take long before the demands for information to be delivered via the World Wide Web outstripped the static capabilities of predefined web pages. Companies began to use web sites to communicate with their customers, and needed to support basic capabilities like searching for specific products or accepting a customer order. The first step toward providing actual processing capability in conjunction with display of a web page was provided by the web servers themselves, as shown in Figure 22-1. Instead of accepting only requests for static web pages, web servers also accepted requests to execute a script: a series of instructions that determined which information to display.
Web server scripts were often written in specialized scripting languages, such as Perl. In its simplest form, a script might perform a very simple computation (such as retrieving the current date and time from the operating system) and output the result as part of a web page. In a slightly more complex form, the script might accept input typed by a user into a forms-oriented web page, perform a database query based on the input, and display the results. Because the output of the script could vary from one execution to the next, the resulting web page became dynamic: its contents could change from one viewing to the next, depending on the results of the script execution each time.
Scripting languages provided the earliest links between web sites and SQL databases. A script might, for example, submit a SQL query to a DBMS through a variation on the interactive SQL interface, and accept the results of the query for display on the web page. But there were many problems with scripting solutions for web site processing. Most of the script languages are interpreted, and executing a complex script can consume a lot of CPU cycles. Scripting facilities ran as separate processes on UNIX-based or Windows-based servers—a high-overhead structure if dozens or hundreds of scripts must be executed every second. These and other limitations of scripting solutions set the stage for an alternative approach and the emergence of application servers as a part of the web site architecture.
Source: Liang Y. Daniel (2013), Introduction to programming with SQL, Pearson; 3rd edition.