What is the Active Server Pages Object Model?

In this chapter, we have looked at how a physical object can be represented by a programmatic object. This programmatic object has all of the interfaces of the physical object, and it can be used as an interface between an application and the physical object itself. But what about objects that don't have a physical counterpart?

In the Active Server Pages programming model, there is a wide range of functionality that is accessible to the programmer. ASP helps us to track the state of a user, dynamically generate HTML output, and take data from forms to be inserted into a database. All of this functionality makes ASP a rather complex beast. Microsoft was tasked with finding the best compromise between offering a simple programming model and providing access to all of the power that ASP provides. To do this, the functionality was grouped into a set of objects. These objects were then related together into what is known as an object model.

An object model is a representation of a set of objects and their relationships to one another. These relationships can take the form of containment, where one object is embedded inside of another. Or, they can take the form of a parent�child relationship, where one object has a set of child objects associated with it.

We will not be examining the various methods for grouping objects together in this book. What is important to us is what the objects that make up Active Server Pages are, and how they are related to each other.

Object Model Structure

Seven objects make up the core of Active Server Pages. These are known as the built-in objects.� The objects are:

q Server object

q Application object

q Session object

q Request object

q Response object

q ObjectContext object

q ASPError object

Each of these objects interacts with a different part of the ASP system. This chart shows how they are related to each other, and how they are related to the client and to the server.

The following chapters in the book will go into each of these objects in greater detail. They will also provide a series of basic examples that will quickly show you how to use these objects to create ASP scripts. But for now, we will just take a quick look at what each object is for.

The Server Object

The Server object is an object that provides a home to a miscellaneous ragbag of properties and methods that can be used in almost every Active Server Page. While seemingly unrelated, these methods and properties are in fact abstractions of the properties and methods provided by the web server itself. This object will allow you to do things such as:

q Set the amount of time a script can run before an error occurs

q Take a user-supplied string and encode it into HTML format

q Convert a virtual path to a physical path on the server

q Take a user-supplied string and encode it into the proper format for a Uniform Resource Locator (URL) string

q Create an instance of an ActiveX component. You saw this earlier in the chapter with the CreateObject method of the Server object.

q Change the course of execution by jumping to another page using the Transfer and Execute properties.

These methods and properties are provided as utility functions for you to use in your pages. They are not directly used to affect the display of the page, but they still provide valuable support in creating Active Server Pages. Chapter 11 will cover this object in greater detail.

Application Level Objects

As the web is moving from just serving up pages to providing access to dynamic information from a wide range of systems, the sites that a user may access are beginning to look more like a traditional desktop application. We touched in Chapter 2 on the idea of a web application, and that all dynamically generated web sites are in fact web applications. The application object represents your site and all of its visitors.

The Application Object

Since these pages are functioning together as an application, naturally the developer would want some control over the application as a whole. This is the responsibility of the Application object. This object will be covered in detail in Chapter 8, but let's just introduce a few things that it can do.

With this object, you can:

q Be notified when an application is first started, so that you can perform some startup processing.

q Be notified when an application is ending, so that you have the opportunity to perform functions to enable the application to close down cleanly.

q Store information that can be accessed by all clients accessing the application.

There is one instance of the Application object for each web application running on the web server. There may be many clients accessing the same application. They each can get a reference to the same Application object. Next, we will look at an object that is unique to each client of an application.

The Session Object

There is one Application object for each application on the web server. Every client accessing that application can get a reference to it. Each of these clients opens a Session, therefore, each of them has a reference to a unique Session object. This object will be covered in Chapter 8, but here is a little of what it can do. The Session object will allow you to:

q Be notified when a user session begins, so that you can take appropriate actions for a new client.

q Be notified when a client has ended their session. This can either be caused by a timeout or an explicit method called Abandon.

q Store information that can only be accessed by that particular client throughout the session.

The Session object is the most powerful object for continuity when using an application in Active Server Pages. One of the problems that have existed in creating web-based applications is that the connection between the client and the server is stateless. The web server itself has no mechanism for tying a request for a page by a client back to a previous request for a page by the same client. This means that each request that one client makes of a web server is treated independently from the rest. While this allows for a very efficient and fast web server, it makes writing applications nearly impossible.

Think of it this way. If you are writing an application using a standard web server, then every request to the server must carry along with it everything that you have done related to the application up to this point. Since the web server has no way of storing and retrieving that information, it is up to you to provide it every time you make a request of the server. Sounds pretty cumbersome? Well, with the Session object, Active Server Pages allows you to store and retrieve information about the client accessing your application. Nevertheless, this is just to whet your appetite. Stay tuned for Chapter 8 when the Session object will be explored in detail.

Page Scoped Objects

As we traverse our way through the object model, we now move from the Session level down to the individual page level. When working with pages of the application, we need to look at the basic function of a web server.

Basically, a web server operates by receiving a request from a client and then sending a response back to it. This request could be for an HTML page, or it could be the data from a Form submission that the user has made. To make our pages dynamic in ASP, we need to take the information that has been submitted and craft a customized response to send back to the client.

Active Server Pages provides two objects that allow you to interact at the page scope. The information that is sent from the client to the server is held, or encapsulated, in the Request object. The information that the server prepares to send back to client is encapsulated in the Response object. These two objects are good examples of objects that have physical manifestations, like our telephone. They are modeled on the HTTP request and response.

The Request Object

When a web browser or other client application asks for a page from a web server, this is called making a request. Along with the actual page that the client wants, it can send a great deal of information to the server as well. The Request object is responsible for packaging up that information to make it easily accessible to the ASP application.

The client asks the server to create an html page, by requesting an .asp script. When the server sees this request, it interprets this type of page as an Active Server Page. All of the information that the client is sending along with the request is then packaged into the Request object. This information is then accessible to the actual ASP script that is used to construct the page.

The information is categorized into five sets of information. Since each set of information can include multiple individual pieces of information, each set is stored as a collection. In a collection, each piece of information is stored as a name-value pair. We talked about name-value pairs earlier when we introduced object properties.

The collections in the Request object will be explained in detail in Chapter 7, but we will quickly introduce them here. The collections hold information about:

q The values that are provided in the URL that are sent by the client. In the URL, the client can include name-value pairs of information after the file name. This information is stored in the collection called QueryString.

q If the client is sending a Form request, then the values of the form elements are stored in another collection � the Form collection.

q The web server itself has a great deal of information about the request, response and general information about the server itself. These are called the HTTP Server Variables. This information is made available as a collection as well.

q If the client is sending any cookies along with the request, these are included in their own collection.

q In addition, if the client is sending any security certificates to the server, then these are included in their own collection.

By using the information that is included with the request, along with the script code in the Active Server Pages script file, the server can dynamically generate a page for the client to display. In order for the client to display the information, the server needs a mechanism to relay the data back to the client. This is the job of the Response object.

The Response Object

The primary feature of Active Server Pages is the ability to dynamically create web pages. The basic task needed to execute this feature is the ability to tell the client what information to display. There are a number of different ways to shape what the client will be displayed. The Response object exists to provide an efficient interface to control the output to the client.

The Response object provides the ASP script with a set of interfaces that allow the script to control what information is being sent back to the client. The details of the Response object will be covered in Chapter 8. For now, we will just touch on some of the functions that the Response object provides.

With the Response object, the ASP script can:

q Insert information into the page being sent back to the client.

q Send instructions to the browser to create cookies on the client.

q Send the client to another page via a redirection.

q Control whether the page is sent as it is created, or whether it is completely built and then sent at one time.

q Control the various properties of the page, such as the HTML headers or the type of content.

These interfaces give the designer of the script the ultimate flexibility to decide how the information is presented back to the client.

The ObjectContext Object

The ObjectContext object helps you to develop applications out of components. It does this by allowing you to handle transactions from within an ASP page. A transaction is a single unit of work, that must either succeed in its entirety or if it fails, then must be undone completely returning the system to the state it was before the transaction was started.

When using applications made of out of components, its common to use transactions. If for example an action handled by a particular component fails, then you'd want details of the failure, and be able to take an alternative course of action. If a user tried to change details of their bank account and then bombed out mid-track, it would be logical to want track back to what the bank account details were previously, before trying to change the details again or continuing on alternative course.

The second type of application that uses transactions would be one that features data processing. If someone makes an alteration to a database via a web page, and somebody else makes another alteration at the same time, you need to be able to accept one alteration, while canceling, or postponing, the other. The management of these types of transactions was handled in IIS 4.0 and PWS 4.0 by a piece of software known as Microsoft Transaction Server (MTS). However, with IIS5 and Windows 2000, the functionality of MTS is now integrated directly into part of the Windows 2000 operating system known as COM +.

The ObjectContext object allows access to what is known as MTS to start or terminate a transaction. We don't want to go into how it does that now, that's a topic for later in this book, but this hopefully gives you an overview of this useful object.

The ASPError Object

The ASPError object contains details of any errors generated by an ASP script or by the asp.dll itself. Previously, there was no facility in ASP for storing details of errors that occurred. The ASPError object with help from the Server.GetLastError method, allows more complex customized handling of error messages. It directs the user to a standard error page, or to a user-created page depending on the option selected in MMC.