Java Reference
In-Depth Information
servers are configured to run a limited number of processes. If the server runs out, it will
not be able to handle the client's requests.
•
Although CGI code can be implemented in almost any language, the most common plat-
form-independent language is Perl. Perl is very powerful at processing text, but it
requires the server to start a new interpreter for every request. This takes longer than
starting compiled code and still eats up available processes and resources.
•
CGI runs in a completely separate process from the Web server. If a client submits a
request to a CGI program that terminates before responding to the Web server, the
browser has no way of knowing what happened. It just sits there waiting for a response
until it times out.
Request CGI1
Client
New CGI1 Process
Request CGI1
Client
New CGI1 Process
Request CGI1
Client
New CGI1 Process
Web Server
F
IGURE
2.2
The interaction of a CGI solution.
Proprietary APIs
Many Web servers include APIs that extend their functionality. The most common examples
include Netscape's NSAPI, Microsoft's ISAPI, and O'Reilly's Web site API called WSAPI.
The problem with these solutions is that they are proprietary. You cannot decide to change
servers without porting your code. These APIs are also developed using languages such as C or
C++ that can contain memory leaks or core dumps that can crash the Web server.
Server-Side JavaScript
Server-side JavaScript is another solution for implementing dynamic Web sites. With this solu-
tion you embed JavaScript into precompiled HTML pages. By precompiling the Web pages
you improve performance, but the only servers that implement server-side JavaScript are
Netscape's Enterprise, FastTrack Servers, and Microsoft's IIS. This again ties you to a particu-
lar vendor.
Microsoft's Active Server Pages
Microsoft has developed its own solution to the problem of dynamic Web content: Active
Server Pages (ASP). Like Server-side JavaScript, ASP is embedded into HTML pages, but it is
