Servlets vs. CGI scripts

As most developers realize, the advantages of CGI technology are many. Not only has it been around forever and is tried and true, but scads of good CGI scripts exist online for the plucking. Most every Web server speaks some dialect of CGI, and almost all ISPs offer some level of CGI user support. So why should you even consider forsaking CGI for Java servlets?

The following chart compares and contrasts Java servlets with CGI scripts. Scores in each category range from very low to very high. Note that the picture this chart paints is, to some extent, subjective, since there are no hard-and-fast scoring rules in most categories. With that grain of salt:

	Java servlets	CGI scripts
Ease of creation	Medium	Medium
Ease of creation	Depending on their degree of functionality, Java servlets, like Java applets and applications, can be quite challenging to code. However, the basic model for servlets (as discussed on the next two pages) is a refreshingly simple and straightforward one. Tons of excellent Java IDEs exist, making your job as servlet creator potentially much easier.	Again, bare-bones CGI scripts are really quite simple to code, but the difficulty increases exponentially with higher functionality. Since CGI is a specification (for data exchange) rather than a language, you can leverage your existing programming skills by coding CGI scripts in your language of choice: Perl, C/C++, Tcl, Visual Basic, and, yes, even Java.
Execution efficiency	High	Low
Execution efficiency	A servlet runs in a single process (within the server process). Thus, unlike CGI scripts, a new process does not have to be spawned for each new request for the servlet. This makes for low execution overhead and high efficiency. It also enables a servlet to handle multiple concurrent requests with ease and elegance. Moreover, since there is only a single instance of the servlet in existence (all concurrently running instances are actually threads of the main instance), server memory drain is minimized, and data persistence is enabled.	A CGI script often spawns a new process every time it is invoked, thus causing a noticeable lag in transfer speed and potentially consuming great gobs of server processing time and resources. I say "often" because there are CGI technologies, such as FastCGI, that minimize script-invocation overhead. But even the best of these does not provide as effective of a solution as the one deployed by Java servlets.
Server support	Medium	High
Server support	Servlets can be supported on a large number of popular Web servers, but not all ISPs offer this support.	CGI scripts can be, and are, supported by the great majority of existing Web servers. Harder to come by are ISPs that will allow users to upload their own custom CGI scripts (for obvious security reasons, since CGI scripts, like Java servlets, have the power to wreak system havoc).
Platform independence	Very high	Medium
Platform independence	After all, we are talking about Java here: "Write once, run anywhere."	Perl, when coded correctly, is almost completely platform independent. However, many other CGI-capable languages (such as Visual Basic) are not.
Availability	Medium	High
Availability	Online servlet repositories exist, but their number and breadth/depth of offerings do not rival those of CGI script repositories.	Online CGI script repositories abound. From these, you can acquire custom CGI scripts to upload to your server. Or, if your server won't let you install custom scripts, you can take advantage of the many remotely hosted CGI scripts out there.
Security	High	Low
Security	The strict Java servlet security model (Security Manager) and servlet sandbox safeguard your system from both intentional and accidental malicious servlet behavior. The mechanism of trusted (digitally signed) servlets allows for increased servlet capabilities.	Since CGI scripts are not subject to the same degree/granularity of security sandboxing as Java servlets, they are significantly less secure.

Trouble deciding?
If you're comfortable programming in Java and your Web server supports servlets, go with servlets instead of CGI scripts, particularly if your application will be getting a large number of concurrent hits. Also, since servlets can avail themselves of all the standard Java API goodies, they are better than CGI scripts for large-scale server-side applications. And finally, if security is critical, stick with servlets.

If, on the other hand, Java is not your cup of tea, your Web server is servlet-shy, or you've found the perfect Perl script to tweak a bit and upload, go with the CGI.

There are of course other server-side technologies in use today: JSP (Java Server Pages, which extend servlets), ASP (Active Server Pages, on Microsoft servers), SSI (server-side includes), PHP, Python, server-side JavaScript, and more. JSP and ASP are competing behemoths and beyond the scope of this article, while the other languages are either significantly less powerful (SSI) or not as widely used (server-side JavaScript) as Java servlets and CGI scripts.

This information is from CNET. All rights acknowledged.

Rick Scott has been a programmer, tester, layout artist, instructor, multimedia developer, Web site designer, technical writer, and frequent contributor to ZDNet Developer. He thanks colleague and friend Jeff Sonstein for server-side Java expertise.