1. There is an extra layer between the user and the actual databases
2. You have a separate processor for database operations
3. The web server interacts with everyone, only some users get involved enough with your site to interact with the databases

While there are many other advantages, hopefully these give you some indication of the value of such a configuration.

Now we need to get into some other fundamental issues that I will unfortunately have to treat rather summarily.

Who Should Do The Processing?  This diagram can be used to help pose some questions such as the following  

1. Which computer should do what processing?
2. What assumptions can be made about the processing capabilities of each of the machines involved in the interaction?
3. What sort of processing should be done?

For an example think about when you visit this course webpage.  You send a request to the faculty server through your browser.  The faculty server sends HTML to your browser and the browser interprets it to give you the image on your screen.  You do not really maintain an active connection with the server.  The faculty server doesn't really even identify you or remember you visited, at least I haven't written in any code so that my pages will do this.  This is called a stateless interaction.  The page is cached on your computer/client, so that if you move away from it and come back in a pretty short amount of time you don't actually send another request to see the page to the server, you look at your cached copy.  If I have updated the page in between your visits you would need to reload/refresh the page to get the most recent version from the server.

Now, think about when you visit a site like comedycentral.com.  You send a request to their server through your browser.  The comedycentral server is also likely to send almost purely HTML to your browser and largely forget that you just made the request.  You do not really maintain an active connection.  They might have some extra code written so that they write something to your cookies for their future reference.  Using cookies allows comedycentral to maintain some persistent information about you.  They are more likely to write it to your cookies because they don't want to be storing that much information and they definitely don't want to be storing information on their server for all of their hits.  They have also written some small animations, maybe packaged as GIF images or Flash, for you to process on your computer.  This definitely increases the download duration, though it gives more life to their page.  This sort of trade off is important to remember.

Now consider the homepage for barnesandnoble.com.  It has a bit more opportunity for interaction.  There are some simple animations, but nothing too complex.  They don't want you to get frustrated downloading their page and go elsewhere.  But you will notice that they also have a little textbox and drop down combo box to help you find things like books and DVDs on their site.  If you fill in the textbox and submit your request they make use of a database on their server to give you feedback on the products they have that are relevant to your request.  This sort of processing is not something that could be done on your computer.  By the same token, they are not going to tie up the network, their server and your machine to download their entire database so that you can do the searching on your own machine.  You are definitely making use of databases on this site if you do any sort of searching or purchasing.

These are some common and realistic examples that will involve client-side and server-side web processing.  Some things are more likely to be done by the client, others by the server.

The server-side strategy involves requiring more computing power in the remote/host server or server farm.  It is assumed that these servers should be relied upon to do most of the computing when it is required.  Obviously some things are still done by the local server and user's machine.  But rather than worry about dealing with the large variety of platforms that exist for every little issue this strategy tends to expect things to be done centrally on the remote/host server to make them accessible to other platforms.

The client-side strategy is more distributed in nature.  It puts much more reliance on the local server and the user's machine.  The focus is on ensuring that the software can be run on as many different types of local servers and user machines as exist.  In a large sense, the scripts are loaded from the remote server to the local server where some of the computing is done.  The rest is downloaded to the user's machine where most of the processing is usually done. A major goal is to distribute as much of the processing to the user's machine as possible.

Some Different Views of Client/Server Web Interactions.  We could spend a whole semester just talking about these issues!  Since this course will focus on developing relatively high volume stores we are going to assume that our database processing will be done with some variant of SQL on a database server.  This is a relatively universal assumption, whether you are using SQL Server, MySQL, OracleSQL or some other variant.  We will keep to what is called the ANSI standard as much as possible in order to implement SQL that would work in any of these processing environments.

Since everyone surfing the web must have some sort of browser, usually some version of Netscape or Internet Explorer, we will assume that much of the web interface will be done in HTML.  The HTML itself is stored on the host server, but it is downloaded to the client's browser which does all of this processing.  While there is much more that can be said about this, we will focus on using relatively universal standards for HTML to ensure client browser compatibility.

Obviously, much more processing can be done on the client using languages such as Java and JavaScript.  But, in this class we are going to take a more server side approach to developing an e-commerce store.  This strategy is very common and has a lot of advantages.  

We are going to make use of some sort of middleware.  What is meant by middleware?  Good question!  Most high volume webs are using some sort of "application server" or "middleware engine" as the basis for their interactions between the database system and the client.  They also use the middleware to do things like 

1. redirect users appropriately
2. collect information from HTML forms
3. generate persistent information on the user
4. implement business logic associated with user's interaction

and a huge number of other possibilities.

The following table contains a listing of some of the major application servers.

Each of these has their advantages and disadvantages, but for a quick summary.

• ColdFusion has the advantage of working both client-side and server-side.  It has very nice pre-built features. From what I can gather from others, it is the slowest, and generally considered too slow for higher volume sites.  It's customizability can be quite difficult or impossible to implement.
• JSP and Java probably win hands down for things like portability and working on both the client and server side.  Unfortunately, speaking from experience, this portability and cross strategy capability are not necessarily all that easy to achieve.  While it seems to be the fastest and give you the most range of development capability, it seems to be the most difficult to learn and require the longest development times.
• PHP is something that other's recommend highly when dealing with Apache Server.  I have real development experience with it.
• ASPs give a pretty damn strong capacity for realistic customization with quite a large variety of built-in classes to ease development.  They can be developed in a variety of languages and many people are quite comfortable with using VBScript as a subset of the Visual Basic they have already learned elsewhere.

Active Server Pages.  As we've discussed, web interactions can be brought about by client side scripting or by server side scripting, though often times not both.  In this course we are going to focus on server side scripting using ASPs for our middleware.

Active Server Pages contain two parts:

1. Programmatic code
2. Embedded HTML

The programmatic code can be written in a number of scripting languages.  The most common are VBScript, JavaScript, PerlScript and Python.  The names of all of these except Python give away their source language.  While I am certain many of you have great interest in mastering the wily ways of the Python, particularly those of the one eyed kind, that's not what we will do in this course.  Since this is probably the most universal, we are developing in the Microsoft realm using VBScript as our ASP scripting language.

While there are several ways to implement ASPs, we will start with the following.  Lines that are included between an

<%

and a

%>

are treated as script that should be compiled and executed by the host server.  The results of this are then placed into HTML so that user can see or interact with the resulting page.

The scripting language that should be used is determined by the very first line in the file.

<%@ Language=VBScript %>

signals the server to start looking for VBScript source code.

The Process for ASP Enactment.  The following diagram represents the major steps in enacting and ASP.

• Request - The user sends a message via the browser to the host server for a particular page
• Preprocessing - The ASP.dll file does some initial processing
• Execution - The scripting engine executes the script
• Translation - The ASP.dll translates the results of the execution into HTML
• Display - The HTML is sent back to the user via the browser whcih processes the HTML tags and displays the page.

It is important to remember that this ASP enactment process is completed when the page is sent back to the user.  Other enactments may be requested, but this is the nature of server-side processing.

We will now work with some ASPs when doing a survey of some SQL.