| Home | ASP Main |
|---|
Microsoft's Active Server Pages (ASP) technology is a powerful tool for building Web sites that incorporate dynamic content, like pages built from databases. It will be particularly beneficial to developers already comfortable with Microsoft's Visual Basic. Microsoft presents ASP as the server half of an overall Active Platform; the other half-Active Desktop-represents the client side. Both server and desktop use similar technologies:
In implementation, however, the active server is entirely independent of Active Desktop-it is a set of technologies that runs on an NT server running Internet Information Server (IIS) or Windows 95 with Personal Web Server. The Active Platform appears to be more of a "vision thing" or marketing concept than a development concern. For example, you do not have to use ActiveX controls in the pages that ASP serves up.
The Active Server Model
Active Server Pages is a 32-bit, multithreaded service that runs under Windows NT 4.0 in the same address space as IIS. Both ASP and IIS 3.0 can be downloaded free of charge from Microsoft's Web site. ASP exploits Microsoft's Internet Server Application Programming Interface (ISAPI), which contributes to its performance. Fundamentally, building ASP applications involves creating .asp files that typically contain a combination of HTML and scripting code (VBScript by default). When a browser requests an .asp file, IIS will pass the request to the ASP dynamic-link library (DLL) for processing. The resulting HTML is passed back to IIS, which returns it to the browser.
The ASP application-development framework includes a number of objects-the
request, the response, the application object, the session object, and the
server object-that have properties, events and methods through which you
programmatically control the application. Let's look briefly at these four
objects; they are each described in more detail in the following sections.
The request object is used primarily to manage data relating to HTTP requests.
The response object is used to control the HTML output, which is returned to
the user. The session object is used to manage session-level data for
individual users. The application object is used to manage a multiuser
Web-based application. The server object is a bit different. It enables you
to instantiate ActiveX server components. In typical ASP applications,
server-side ActiveX components provide a lot of the functionality.
Microsoft provides several ActiveX server components that can be used in ASP
applications. The database-access component, the browser-capabilities
component, and the file-access component are of the greatest utilitarian
value. Microsoft also provides a content-linking component (that helps
manage user navigation through a Web application) and an ad-rotator
component (which enables you to alternate the display of images, typically
used for advertisements, according to your specifications), though you may
find them somewhat less useful. There is also a flourishing market for
third-party components. And of course, you can create your own components
as well, though this is a job for seasoned VB and C++ developers.
The ASP object model employs Microsoft's concept of classes, collections,
and properties-familiar turf to VB programmers and perhaps a little confusing
to others. Collections hierarchically organize groups of variables or
properties associated with a class. Multiple collections may be associated
with each class of object. You can create neither your own classes nor
collections in VBScript.
The request object provides any information passed through an HTTP request and is primarily used for reading information such as CGI variables, parameters passed through the GET and POST methods, cookies, and client certificates.
An application is a group of related files stored in an IIS virtual directory and shared by all application users. It is instantiated when the first user requests an ASP file in the application's directory structure after the Web server has been started. Applications end when the server shuts down. You can write code to respond to application start and end events, and also attach your own variables to the application object, making them accessible to all application users. Query results, for example, can be stored at a global level that any user can access. An application can use global.asa, an active-server application file read whenever an application or session starts. Global.asa is stored in the root directory of the application, which also includes scripts that respond to start and end events for application and session objects. Global.asa can also be used to instantiate objects that require an application- or session-level scope.
The session object is similar to the application object, but belongs to a single user. It is instantiated for each application user when either: a user who doesn't already have a session requests an ASP file, an ASP program stores a value in the session object, or a user requests a page containing an object scoped at the session level. Sessions end when the user doesn't read or refresh a page in an application for a specified amount of time. (The 20-minute default can be changed in the SessionTimeout registry entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ASP\Parameters or altered on the fly by setting the Session.Timeout property to a number of minutes.) Sessions can also be explicitly terminated with the Session.Abandon method. Like the application object, the session object is very powerful. It enables you to maintain the state of the application as a user moves throughout the application's pages. The session is maintained by a unique SessionID, stored in the user's browser. Unfortunately, the session object relies on cookies, and can't be used with browsers that don't support them. That leaves you instead with URL query strings, hidden form fields, database records, and other kludges.
Unlike the session, application, response, and request objects, ActiveX server components (which act like objects) must be explicitly instantiated in your ASP programs. The syntax for instantiating other objects is: <% Set MyObject=Server.CreateObject
Microsoft's ActiveX Data Object (ADO) provides access to ODBC databases. This is the most significant server component for typical Web-based database applications. To use a database in your ASP application, you must first create an ODBC data source for the database on your Web server. It should be created as a System Data Source Name (use the System DSN section in your ODBC). The underlying complexity and robustness of the ADO model makes using databases in ASP quite complex. As employed in ASP, this model provides one distinctly nice feature: the ability to store commonly used data in the application or session objects. This means that if your application needs to reference the same set of data on a variety of pages, you needn't rerun the same query on each; instead, run the query once and associate the result set with either the session or application object.
ASP also includes components that enable you to: Read files from and write files to the server file system. Rotate ads (GIFs) at user-defined frequencies. Determine browser capabilities. Specify URLs used for navigational purposes in a separate text file. These components provide examples from which you can learn more about programming ASP apps. The tutorials and samples use these ActiveX objects extensively and informatively. Conspicuously absent is a mechanism for producing email. ASP itself contains nothing that would allow you, for example, to send email to a selected group of people stored in a database, but several third-party tools exist for this purpose.
Microsoft's Active Server Pages provides a robust framework for developing complex applications, but it is not yet the awesome, killer app touted by Microsoft evangelists, for two main reasons. First, it is very complex and the learning curve is a lot steeper than those of many competing products. Second, it's missing a few important features: email, support for debugging, and simplified field-validation mechanisms. The solutions involve writing your own server components, which doesn't exactly enhance productivity. Which leads me to a more fundamental problem with ASP: In its first version, at least, you have to write a lot of code to get anything done. The SQL insert in that took five lines of VBScript code can be accomplished with one simple tag in Cold Fusion, for example. Nevertheless, the application-development framework provides an excellent foundation for Microsoft to build upon. The session and application objects are innovative, and if Microsoft can make ASP a bit easier to learn and use, the tool will enhance developer productivity.