Microsoft Internet Information Server (IIS) 3.0 provides only minor improvements to IIS 2.0's base Internet server
functionality, but IIS 3.0 offers several important new features. The most significant new feature is its rich
server-side code scripting that uses Active Server Pages (ASP). With ASP, you can build high-powered, dynamic Web server
applications from a development environment that combines HTML, scripts, and ActiveX components on the server. (For a
brief description of IIS 3.0's other key features, see the sidebar, "What's New in IIS 3.0.") Let's take a
look at what ASP is and the role it plays in IIS 3.0.
Active Server Pages
ASP (formerly code-named Denali) integrates Web scripting and components in IIS 3.0, as Figure 1, illustrates. Just
as Internet Explorer (IE) 3.0 hosts Visual Basic Scripting Edition (VBScript) and JScript on the client, ASP hosts those
scripting languages on the server. The name Active Server Pages comes from the files: For the most part, the
pages are HTML files with embedded scripting code that executes on the server and can reference ActiveX Server
Components. An ASP file can contain both server-side scripting and, embedded in standard HTML, client-side script code.
When a client requests an ASP file, the server loads the file into memory and passes off any server-side scripting code
to the corresponding scripting engine. Everything else in the file (including any client-side script code) ends up in
the HTTP response that returns to the client.
| Meet IIS 3.0's most significant new feature |
Running script code on the server provides several important advantages. First, the code is secure: Each page can
use the access control lists (ACLs) in Windows NT's security system. Also, because the code executes on the server, the
Web client never sees the code--only the results. This feature prevents users from looking at or otherwise appropriating
your code. Furthermore, because you can tightly administer servers, you can keep unauthorized code off the server. The
second major advantage is that the server can better manage expensive resources (e.g., database connections) to support
a higher volume of client requests. ASP supports apartment model threading, which offers improved scalability and
performance on the server. (In apartment model threading, each thread gets a copy of the program and global data, and
runs in a protected area or "apartment.") Third, code on the server runs closer to the data and back-end
systems. This arrangement eliminates a lot of low-bandwidth network traffic. Finally, because the code executes on the
server, you can develop sophisticated Web applications that users can run from any browser.
Probably the only advantage to running code on the client is that the client can validate individual fields without
an expensive round-trip to the server. Of course, because users with browsers can change individual pages rendered on
their machine, you still must validate all data on the server.
The ASP architecture is a little more complicated than I've described so far. ASP can maintain state information
across multiple calls from the same user (called a session in ASP). You can also build a long-lived server
application that handles many different clients (called an application in ASP). IIS 3.0 stores each ASP
application in a separate virtual directory; a request for any file in the directory starts the application. When a
client requests new pages, NT loads them into memory, compiles (and can execute) the code, and returns the output (if
any) in the HTTP response. NT then watches the disk for any pages that have changed since loading. If NT finds an
updated file, it recompiles the code and replaces the code that was already in memory. The global.asa file defines
application startup and shutdown, and initializes global variables.
ASP Intrinsic Objects
To complement and extend the scripting code that ASP files contain, the ASP architecture handles the creation and
management of server and application-building objects. Similar to the way Microsoft makes the IE object model available
to VBScript hosted on the client, Microsoft gives developers a handful of useful intrinsic server objects to work with.
Intrinsic server objects are always available--you do not need to load a corresponding object library. ASP includes the
following five intrinsic server objects.
Application. The Application object handles globally scoped variables, which affect all
users of a given application. The Application object defines a set of application initialization and termination
subroutines and provides a method for temporarily locking an application for administrative purposes or to control
access to a global variable.
Session. Session objects store information about user sessions. They control session lifetimes,
maintain session-scoped variables, and provide initialization and termination subroutines each time a session is created
or destroyed. Sessions have unique SessionIDs, which ASP encrypts and IIS transmits to and from the client via cookies.
Request. The Request object is a meta-object for five different collections: ClientCertificate,
Cookies, Form, QueryString, ServerVariables. Request collections generally store information parsed from the HTTP
request.
Response. The Response object is the Request object's complement: It contains the information used
in the HTTP response, including the body of the response, the Cookies collection, expiration and status data, and
client-side redirection.
Server. The Server object provides a limited set of utility functions. These functions include
CreateObject, HTMLEncode, MapPath, URLEncode.
Because Microsoft built the ASP architecture on component object model (COM), you can use almost any COM-based
server objects. You can develop server objects in-house or purchase them from third-party vendors.