Servlets and Alternatives

Traditional CGI (Common Gateway interface) and other proprietary technologies from Netscape (NSAPI) and Apache are some of the alternatives for extending the functions of the server into the presentation world. Servlets achieve the same basic goal as the other server extension mechanisms listed in Table 14.1, but the advantages of servlets outweigh the features of other alternatives. Some of the advantages are as follows:

• The traditional CGI process model in most Web servers (with the exception of some of them, such as iTPWebServer in Tandem platform) starts a new process for every invocation of a function. These are single-threaded processes with no caching abilities because the process is stopped once the service is finished. Servlets can be multithreaded and stay alive inside the Java Virtual Machine, thereby offering many advantages, such as data caching between requests, avoiding creation time for every request call, and more.

• Because servlets use the standard Java API defined in Sun's specification, they run on all leading Web servers that implement the specification with no change in code. In other words, servlets are highly portable.

• A well-defined and extensive API infrastructure and the Java programming language make servlets convenient and easy to use.

• The platform independence provided by the Java language, coupled with features that the specification provides, such as like session tracking, caching, and event filtering, make servlets a powerful server extension mechanism.

• Unlike traditional CGI programs, which were mostly developed as scripts, servlets have a well-defined set of security mechanisms, such as declarative and programmatic security as specified earlier.

Table 14.1 lists the alternatives, along with their disadvantages. It gives a better picture of what servlets bring to the table compared to the other options.

Table 14.1. Servlet Alternatives

Name	Disadvantages
CGI (Common Gateway Interface)	Performance limitations because it has to start a new process for every function invocation. No state maintenance. Not supported by well-defined API.
SSI (Server-Side Includes)	Simple but not powerful enough to address all dynamic content generation requirements.
ISAPI	Implementation limitations because this can be written only in C or a C language derivative. Provides powerful API, but the programmer is responsible for handling all the application's thread requirements. Security is common to all applications running inside an ISAPI application server, making it inflexible.
NSAPI	Proprietary API. Similar to ISAPI, provides powerful API but the programmer is responsible for handling all the application's thread requirements.