Dynamic web servers are HTTP server softwares that generates HTML pages dynamically. The pages of the website are defined
as executable codes, not just as pure HTML static tags. These codes are executed by the time the page is requested, generating thus the page dynamically. Here we'll explain three approaches for generating dynamic HTML content: CGI, Server APIs and Server Pages.
CGI – Common Gateway Interface In CGI, for each HTTP
request the web server receives it generates a new sub-
process in the underlying operating system. This sub-process then executes an external program, according to the request, that will generate the appropriate output, for example rendering an HTML table based on information from the application database. The server then receives this output and forwards it to the user. After all, the early mentioned sub-process dies.
CGI was one of the earliest techniques to appear and is still used by some websites nowadays. It has as an advantage the fact that it can be used any language to write the CGI program, besides being fairly easy to use. However there is performance problems, as each request causes that a new process rises in the operating system. Another problem is redundancy, since processes repeat operations that could be shared among requests, such as connections to the database.
Server APIs In this technique, the web server loads a module (.dll files on Windows and .so on Linux) that will be responsible for serving its addressed HTTP requests. Each request corresponds to a simple function call, not generating thus a new process as in CGI. That function produces then the dynamic content that will be returned to the user, all this in the same process.
The Server APIs have appeared getting around the CGI problems, since each HTTP request corresponds to native code execution in the same process the web server resides. Further, there is no redundancy as it happens in CGI , because being everything in the same system process, there is a memory space the server provides for storing state and data shared among requests. Therefore, costly processings are avoided to be repeated, e.g. when running complex queries in the database, whose results can now be cached and shared among requests.
However there's some disadvantages. First, it's necessary to work with low level languages such as C/C++ to write the modules, leading to complexity regarding extending the web server. Besides it's dangerous as by just one code error, not only the related application can be affected but also the whole server. It can even cause a server crash.
Further, the Server APIs cannot be shared among servers as each of them has its own API. For example, a dynamic website built with the Apache's server API won't run under IIS. As a general role, for each web server that will be used it's necessary to learn about a new Server API.
Server Pages Server Pages are most recent and widely adopted nowadays. In this approach each HTTP request is forwarded to a server module as in Server APIs, but instead of serving directly the request this module delegates this task to a dynamic HTML page, or Server Page. Now modules are only script processors and the guidelines about how the dynamic content must be generated are now in dynamic HTML pages, that is, HTML pages with embedded scripts that are executed in the server by the module for generating the HTTP response to the user.
Server Pages in general use script languages which are simpler and less dangerous, beyond not generating new processes in the operational system. However they are not as faster as the Server APIs, beyond sometimes being specific to some servers (e.g. Microsoft ASP - as an exception we can note PHP).
Server Pages also have the problem of stimulating a bad programming pratice that is to embed the script's business logic into the page layout. In the Server APIs and CGI it's possible to plates for dlayout, but using Server Pages it's a little more complicated since they are, by nature , a blend of layout and code.
Java platform for instance, as an alternative for this, allows to create a structure where the JSP pages are used only for layout, keeping the business logic in pure Java classes separate from the rest of the system, and being supported by web frameworks such as Struts, WebWork and Mentawai.
To finish, it is proper to still mention another approach of Server Pages which replaces the embedded scripts wrote in programming language by special tags, becoming more friendly for design professionals to comprehend the Server Page. These professionals are more used to tags than to codes. As an example we can mention JSTL which is part of Java platform, and CodeFusion from Macromedia.