The comparison of a web application to a non-web application would be the same as comparing a magazine to a desktop computer. With the magazine, all you can do is read one page after another. The only interaction that is available is the required turning of the pages as you advance through the magazine. On the other hand, your desktop computer offers you an interactive interface. Your computer remembers your system settings from day-to-day, and even keeps track of documents for you. Never will you sit down to your computer and say "Why is my font color green?", unless of course the setting was changed by someone at your computer. On the other hand, how many times have you gone to a web site and said "Why did they use that font?".

On your desktop computer, you are able to change the color back to your favourite shade of grey. On the horid web site, you are visiting, the only option you have is to change your default browser fonts to accomodate this one site.

If a friend buys the same magazine as you, you both have the opportunity to see the same information. On the other hand, if you both buy the same application software, each of you may never see the same information since you are able to create your own view of information through the software; whether it is word-processing, graphics, or even your favourite web browser.

Static pages are pages that do not change, and though they've had there place in web history we are now seeing more and more interactive (dynamic) web sites coming online. Sites that allow us to retrieve our email, schedule events, and even define a user interface (font, color, size) for our next return trip.

In order to create a web application, we require some sort of server processing. Arguably we can achieve dynamic web content with Java applets and DHTML, but not at the same level that is offered to us by implementing a web application server.

What should I expect from a web application server?

This question is one that can have any multitude of responses. In fact a web application server (or similar mechanism for delivery of dynamic content) should be able to address issues that define what is required by whatever application you are trying to setup. If the application is a shopping cart, you can get away with any number of prewritten components that have been made available on the web. If your requirements will change in the future, you will want to have a system in place that can change and grow in the future with little to no changes required (scalable).

There are many web applications systems available on the market. Several are complete programming languages such as PERL and Java. These full fledged programming languages give us the ability (as developers) to do almost anything with the server resources available to us. If we know how to code, we are ready to go, and can easily create web application software.

Other systems take a more generalized approach to web application. This approach includes taking into consideration that not everyone is, or wants to be a developer.

Okay, so we're now past 'the why', next step is 'the how'.

No matter what system you decide is the one for you, the implementation is based on the same model. Take a peek at the graphic showing the general overview of a web application server, and how it integrates with a basic web server.

Essentially, everything is based upon the file extension of the file that is being accessed by the client (usually a web browser). It is the file extension that determines how the processing will proceed within the web server.

After the web server generates all of the CGI variables, it then proceeds to determine if the file extension has a corresponding component associated with it. If there is a component registered to handle the file extension, the server is informed that the component will manage the response. If there is no registered component, the web server defaults to retrieving the requested (static) file from the file system.

With a registered component and file extension, the information is passed to the web application server. The web appication server retrieves the requested script from the file system, and parses the contained information. As the script is parsed, resources may be contacted to fill gaps in the page that were left ot be filled with dynamic content. Such dynamci content may be the retrieval of information from a database, or mail server.

These things alone, however, do not define a web application server. A web application server needs to also be able to determine that a user is a user that has made access on the server previously. This is usually done by implementing cookies or some other method to maintain information about a user between page accesses and ultimately visits.

A web application server will offer session management based on a model as described above. With this session management and dynamic page generation, it is now possible to offer true applications that are totally web based, and accessible through a standard web browser.

• Electronic shopping cart
• Electronic mail system
• Personal information managment
• Document storage and retrieval
• Mailing list system
• Community web site with ability to edit your own ads
• Any site with user selected preferences

Certainly there are others. The above list serves as a short list of possible web applications.