The ASP Chain

What is (are?) Active Server Pages? Well, to put it simply, they are HTML pages with an .asp extension! Perhaps that's a bit too simple. Active Server Pages (ASP) are indeed HTML pages with an .asp extension, but they are actually a good bit more than that. ASP pages can contain server-side scripts that generate HTML dynamically.

What do I mean by "server-side?" Well, you're probably familiar with using JavaScript functions in your pages for things like special effects, form validation, etc. These scripts are called client-side scripts, because they are downloaded with the rest of the page and executed in the browser (the client). A server-side script is executed on the server machine, and is not downloaded by the browser. ASP does not behave like regular HTML pages, because HTML pages are simply downloaded from the server.

ASP pages go through a whole different "chain" of events, and the browser never actually sees the files themselves. What the browser sees is HTML that is dynamically generated by the server. The browser is unaware of this, because it receives the HTML in the exact same fashion as a regular HTML file. How is this possible? Well, when you think of a file, you probably think of it as a complete object. but you must remember that the method used to send a file to the browser is called "streaming."

The file is read by the server and sent, one character at a time, to the browser, as a stream of characters, kind of like a long line of characters. The browser interprets the characters as they come in, and formats them to look like a web page. Because of this, a server could simply stream the appropriate characters to the browser to create a web page, and the browser would not be aware that it wasn't receiving a file. In fact, it does assemble a file from the stream it receives.

With regular HTML, the server simply reads the file and streams it to the browser. but with ASP, the server does something completely different. How does the server know to do this? Because the file has an .asp extension (remember my opening line?)!

The following is a simplified illustration of this process:

Here's the long version: The browser requests an ASP page from the server, either by URL (typed in, or hyperlink), or form input. the server sees the .asp extension, and sends the ASP page to the ASP engine on the server. The ASP engine reads the file, which usually contains a mixture of server-side scripting and HTML, although it doesn't have to have server-side scripting or HTML (it can have one or the other alone).

As the ASP engine reads the file, whenever it comes to a server-side script, it executes it. Whenever it comes to HTML, it outputs it (back to the server). The process can involve a good bit of alternating back and forth between the server-side scripting and HTML in the page, and, of course, you have those loops that contain a mixture of scripting and HTML. Any HTML inside the loop gets output every time the loop is executed.

Now here's what makes ASP so cool: ASP scripts can call (invoke instances) of COM (Component Object Model) objects stored on the server. Now, what the heck are COM objects? Well, to put it simply, they are DLLs (Dynamic Link Libraries). They are sort of pre-packaged programming that is bundled up into neat little packets which can be executed from within another program. MS developed the Component Object model, and it has become a software industry standard, because these "objects" can be used by any application, regardless of the language it was written in. Think of a COM object as a tool, of sorts. The application grabs the tool whenever it needs it, then puts it back on the shelf, where it can be used again, by any application that needs it.

There are all sorts of COM objects. Some are built right into the web server. Others can be installed on the web server. And what makes them so convenient is that the programming code to use them is built right into the object, in its' object model. If you're not familiar with Object-oriented programming, let's just say that most of the functionality (or coding) is hidden from the application calling the object. In other words, let's compare a COM object to a car. the car has an engine, an electrical system, and a whole host of other parts that make it go. But you don't have to know how the engine works to drive the car. All you have to know is how to start and stop the engine, make it go forwards and backwards, use the steering wheel and brakes, and a few other things. The rest of it is unimportant to you, the driver.

All you have to know about a COM object is basically the same. You "start the engine" by invoking an instance of the object. In other words, you make a copy of it to work with. You do this simply by knowing the object model and using the "Server.CreateObject" command (or "method" - an object oriented term for a command or function that is inherent to an object). For example, to create an ADO RecordSet, you simply type "Set <RecordSetName> = Server.CreateObject("ADODB.RecordSet")" This grabs the ADODB COM object and tells it you want to invoke an instance of its' RecordSet object. The ADODB COM object (also referred to as the "ADO" (ActiveX Data Objects) technology) has all the necessary functions built into it to communicate with ODBC-compliant databases, without you having to know what's going on under the surface.

Now that you have the object, all you have to know is its' object model (how to use the steering wheel, the gas pedal, brakes, etc.). Using the elements of the object model, you command the object, and, like a car, it will go anywhere it's designed to go, and do anything it's designed to do.

So, getting back to the ASP Chain, the server-side scripts in the ASP page can often call these COM objects, and the COM objects will do their thing, sometimes returning HTML to the ASP Engine, to be output to the server, and sometimes doing other things that are basically invisible to the browser.

As the HTML is output by the ASP engine to the server, the server outputs the HTML in a stream to the browser. The result is the "page" seen by the browser. Because this "page" can look entirely different, depending on the results of the server-side scripting, it is called a "dynamically generated page."

I hope all of this "object-oriented" stuff hasn't been too difficult to understand. I could go into that, but I'm afraid it would entail another whole article! In any case, I hope that this has been helpful in understanding the basics of ASP a bit better.