The ASP Object Model:

-------------------------
ASP encapsulates the properties and methods of the following six built-in object
s:
Request
Response
Session
Application
Server
These objects are part of the ASP.DLL and are always available to the ASP applic
ations.

The Application object represents the ASP application itself. This object is uni
versal to all users attached to an application, and there is only one Applicatio
n object for all users. The Application object has two events, Application_OnSta
rt and Application_OnEnd, that fire when the first user requests a page from the
application and when the administrator explicitly unloads the application using
the Microsoft Management Console, respectively. The OnStart event can be used t
o initialize information needed for every aspect of the application. The OnEnd e
vent can be used to do any custom cleanup work after the end of the application.
We can store any variable type with application-level scope. These variables ho
ld the same value for every user of the site.
An ASP application is a group of scripts and HTML content files that together fo
rm some function. The ObjectContext object is actually part of the Microsoft Tra
nsaction Server and is only interfaced through ASP. The ObjectContext object all
ows us to create transactional Active Server Pages. The functions in these pages
that support transactions will succeed as a single unit or fail completely. If
the application requires the use of functions that do not natively support trans
actions (notably file access), we must write custom code to handle success or fa
ilure of these functions.
The Request object represents the way we interact with the client s HTTP request.
This is one of the most important objects in the ASP object model. It is through
the use of the Request object that we access both HTML form-based data and para
meters sent over the address line. In addition, we can use the Request object to
receive HTTP cookie information and client certificate information from the use
rs. Finally, the ServerVariables collection of the Request object gives we acces
s to all the information in the HTTP request header. This information contains (
in addition to the cookie information) other relevant data describing the client
machine, its connection, and its actual requests. The ServerVariables collectio
n is equivalent to environment variables in traditional CGI applications.
The Response object represents the access/control over the HTTP response sent ba
ck to the user. Through the Response object, we can send cookies to the client a
nd set if and when content should expire. In addition to this, the Response obje
ct is the route to completely controlling how data is sent to the client. Is it
buffered before sending? Is it sent as it is constructed? Finally, the Response
object allows us to seamlessly redirect the user from one URL to another.
The Server object gives us access to the web server itself. This object contains
many utility features that we use in almost every application. Through the Serv
er object, we can set the timeout variable for the scripts (how long the web ser
ver will attempt to serve a script before serving an error note instead). We als
o can use the Server object to map a virtual path to a physical path or encode i
nformation for sending over the address line. The most important method of the S
erver object, however, is its CreateObject method, which enables us to create in
stances of server-side components. We will use this method any time we require f
unctionality outside that provided by the built-in objects. Database access, for
example, is handled by various ActiveX Data Objects that must be instantiated o
n the server before being used.
Finally, the Session object holds information that is unique to a specific user s
current session on the web server. Each user session is identifiable through the
use of a unique cookie that is sent to the user every time the user makes a req
uest. The web server starts a session for every new user that requests a page fr
om the web application. This session stays active by default until 20 minutes af
ter the user s last request or until the session is explicitly abandoned through c
ode.