Novell is now a part of Micro Focus

CGI: Good for the Web, or Outdated Technology?

Articles and Tips: article

Ken Circeo
Senior Technical Wrtiter
Platform Services
kcirceo@novell.com

01 Mar 2000


Web browsers display documents written in HTML. Browsers can also display HTML forms that collect and display data entered by users. When information is collected by a browser it is sent to an http server specified in the HTML form. That server starts a program, also specified in the HTML form, which then processes the data. These programs are known as CGI programs, or scripts. While you can use several programming languages to create CGI scripts, the Perl language constitutes the major portion of CGI scripting on NetWare.

This Developer Note takes you through a simple e-commerce scenario while discussing the pros and cons of the different CGI technologies available to you.

Open for Business: "The Ultimate CD Web Page"

Ah, the Web. So open, yet still so mysterious. Like a vast netherland of mountains and valleys just waiting to be explored...

Okay, enough of that drivel. What we really want to discuss is how to use the Web to your advantage right now. Today.

Say you want to turn your static Web page into an e-commerce site that sells CDs, call it The Ultimate CD Web Page. Suddenly, instead of just providing information to the user, you need to interact with him. You need a way to collect user information such as name, address, credit card number, and CD selection. You also need to store that data and assign an order number to the user.

The classic way to build this system is to use Perl to write a CGI script. Sure, you could use compiled languages like Visual Basic, C, and C++, or another scripting language like Tool Command Language (TCL), but where Web development is concerned, Perl is the de facto CGI standard, particularly when you're writing to the UNIX platform. There are two reasons for this. First, Perl is an open-source language, making it cheaper and more accessible than privately owned languages. And second, Perl inventor Larry Wall designed his language specifically as a text processor, which means it's practically tailor-made for the Web. Given your CD Web site task, it wouldn't take long for a well-versed Perl programmer to write a script that takes the user data from an HTML form and dumps it into a text file, then grabs an order number from a simple database and generates a response.

Figure 1: Using Perl to write a CGI script to collect user data from the Web.

But while writing a traditional CGI script may be the classic way to collect user data from the Web, it is by no means the only way to do it. These days you have more choices.

The State of the "State"

Traditional CGI has a problem: it cannot maintain "state." In other words, a legacy CGI script treats every http request (each CD order placed by a user) as a new and separate request.

Say Fred Garvin is a regular customer who wants to order some CDs from your Web site. Fred signs on by entering his user ID and password in your site's HTML form. When Fred clicks the "Sign on" button, the HTML form is sent to the Web server as an http request.

The Web server authenticates Fred's membership and responds by returning your CD catalog as an HTML file to Fred's PC. Your site has a neat little interface that lets customers drag-and-drop CDs to a shopping cart icon. As Fred browses your catalog, he drags three different CDs to his shopping cart.

Your program is keeping track of the items in Fred's cart, but how? The data is certainly not being stored in the browser. Each time Fred drags a CD to his cart, an http request is sent across the wire to the Web server. The server stores this information in a database until Fred is finished shopping.

Now here's the rub.

With a legacy CGI script, each http request launches a separate process on the Web server. Because the CGI script cannot maintain state, it doesn't have the capability of recognizing that the second Fred Garvin is the same Fred Garvin that placed the first order.

Figure 2: With a traditional CGI script, each http request launches a serparate process on the Web server.

"Dogpile on the Server"

Because CGI insists on instantiating a new process for each http request, the Web server can get quite a workout, particularly on a busy Web site. When you're only dealing with one customer who makes three requests at a time, your Web server will probably run like a well-oiled Furby regardless of what technology you use.

But what happens when your Web server starts handling fifty requests at a shot. What about a hundred? A thousand? Suddenly your solid, dependable, traditional CGI scripting mechanism is running a thousand processes simultaneously and your customers are dozing off while they wait for your server to respond to their requests. Why is your server sluggish? Two reasons. As suggested, the multiple processes instantiated by your CGI program have to compete with each other for processor time. But the greater time consumer is the instantiation process itself.

Do you know anyone who powers their home PC up and down every time they want to check their e-mail? Pretty frustrating, isn't it? Especially if they check their e-mail a couple of times a day. Why don't they just leave the thing running?

That's sort of what your CGI script is doing whenever it receives an http request. With each request, it starts up a whole new process. That's frustrating because it's so time-consuming. And when you're talking about fickle customers, you can't really afford to keep them waiting too long, can you?

So unless you're planning on selling only Barry Manilow CDs, you'll probably want to at least consider some of the newer Web development technologies available to you. Read on.

Is Anyone Else out There?

While traditional CGI scripting still enjoys the reputation of being a solid, reliable vehicle for Web development, newer technologies like Java servlets, Java Server Pages (JSP), and Active Server Pages (ASP) are making inroads into the e-commerce world by offering features not found in legacy CGI technologies.

Figure 3: Using newer technologies for Web development.

A Different Way: JSPs, ASPs, and Servlets

Now assume your e-commerce solution is built as a Java Server Page (JSP) rather than as a Perl script. A JSP is an extension to the Enterprise JavaBean (EJB) standard, which is Java's back-end component strategy for reusable business logic.

JSP technology works by compiling your JSP file into a servlet, then executing that servlet. The JSP server checks for changes between the compiled servlet and the JSP page each time there is a request. True, your JSP still has to rely on CGI technology to interact with the client, but unlike a Perl script, a JSP can maintain state by shoving the data from several http requests into memory. That means your JSP will execute only one process (albeit with multiple sessions) to handle as many requests as you can throw at it, significantly reducing the burden on your Web server and speeding up response time to your customers. This makes for happy customers who in turn buy more CDs, which means more profits, and before you know it you're sitting on the beach in Fiji with an umbrella in your drink.

Figure 4: Using JSP technology.

The primary difference between a traditional Perl script and a Java Server Page is that a JSP lets you embed Java code within your HTML page and execute the code when the page is served. You can't do that in a traditional CGI script. The dynamic content in your Perl script (in this case, the data that changes from customer to customer) is maintained by separate processes on the Web server. But because the JSP lets you separate presentation logic from business logic within your HTML file, your server only has to deal with a single process. With a JSP, maintaining dynamic content is easier for both the coder and the Web page designer, and processing on the server is more efficient.

But if JSP files actually get compiled into servlets, why not just write servlets? Because with JSPs, the focus is on HTML. The JSP extensions simply make the HTML more functional. Servlets, on the other hand, let you output HTML files, but it's a royal pain to do so. In addition, JSPs make it easy to modify your HTML file and let your Web server deal with compiling it into a servlet and running it.

Client-Side Scripts

Another way to provide dynamic feedback for users is to include programs that run on the user's machine rather than on the Web server. These programs can be Java applets, Java scripts, or ActiveX controls. Where CGI is a server-side method, these technologies are known as client-side methods because the processing occurs on the machine that is running the Web browser.

You can see how Novell is taking full advantage of both client-side and server-side scripting technologies by visiting the following product pages on the Novell Developer Kit Web site at http://www.developer.novell.com/ndk.

  • Novell Controls for ActiveX (http://developer.novell.com/ndk/ocx.htm)

  • Novell Script for NetWare (http://developer.novell.com/ndk/nscript.htm)

  • Perl 5 for NetWare (http://developer.novell.com/ndk/perl5.htm)

  • Beans for Novell Services (http://developer.novell.com/ndk/bns.htm)

  • Netscape JavaScript for NetWare (http://developer.novell.com/ndk/nsjs.htm)

  • Nombas ScriptEase Web Server Edition for NetWare (http://developer.novell.com/ndk/sewse.htm)

  • Novell Servlet Gateway (http://developer.novell.com/ndk/servgate.htm)

  • IBM WebSphere Application Server for NetWare (http://developer.novell.com/ndk/ibmws.htm)

  • IBM WebSphere Studio (http://developer.novell.com/ndk/wsstudio.htm)

Also, check out Brad Nicholes' article titled "Building Web Database Applications Using Novell Script for NetWare" (http://support.novell.com/techcenter/articles/dnd19990803.html) in the August 99 issue of Developer Notes.

Morgan Adair's article, "The Novell Controls for ActiveX and Visual Basic: Reading Field Values" (http://support.novell.com/techcenter/articles/dnd19990901.html) published in September, is also worth reading.

Don't Hammer the Nails in the CGI Coffin Just Yet

So if newer technologies are easier to code and run more efficiently, why hasn't traditional CGI programming just gone away? Primarily because of the reasons mentioned at the outset of this chapter: it's simple and stable. If you use CGI to create an interactive script, you can rest assured that just about anyone can use it.

While server-side technologies like Java Server Pages (JSP) and Active Server Pages (ASP) can streamline processing and increase processor efficiency, it's a little early to grant them "holy grail" status.

Trouble in Paradise

JSP technology may be built on a good idea, but remember that it's still very much a new concept, even in Internet terms. As of this writing (Nov 99), the JSP spec has not yet stabalized and is thus still dealing with growing pains like version mismatches and industry standardization. In addition, compared to CGI scripting, JSP coding can be quite sophisticated. You may find the JSP learning curve steeper than you thought, particularly if you're new to Java. And while JSP's popularity is steadily increasing, reliable reference material to help flatten that learning curve is still rather limited.

ASPs, on the other hand, are coded similarly to older Windows languages such as Visual Basic, and should be relatively easy to learn. But ASPs live in a Windows-only world. While JSPs follow the Java mantra of "write once, run anywhere," ASPs can only run on Windows and are only compatible with an IIS Web server. Only 23% of all Web servers today are IIS servers. That leaves a lot of room for the likes of Apache, Netscape, and WebSphere, and may limit ASP's hopes for market domination.

Unripe Client-Side Technologies

On the client side, Java, JavaScript, and ActiveX can all be turned off within the browser, and many browsers just do not support them. Also, some network administrators consider executables that run on their company's client machines security risks and may block such programs at the firewall. Because CGI scripts run on the server, they are not limited by browser restrictions.

So while traditional CGI tools may not be as flashy or dynamic as some of the newer technologies, don't look for Perl to die away just yet. In fact, the word among Perl devotees is that Perl is going through an update as an open-source standard that will include some of the capabilities of the newer technologies. And, believe it or don't, for the first time ever, the new Perl spec will offer a (shudder) GUI. Stay tuned...

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates