The LA Fox Developer Newsletter

December 2000

“.N ET” (Con’t from page 3)

then dispatching the request to the application for further

processing. The HTTP runtime is multithreaded and processes

requests asynchronously, so it cannot be blocked by bad

application code from processing new requests. Furthermore,

the HTTP runtime assumes that failures will occur, so it is

engineered to automatically recover as best it can from access

violations, memory leaks, deadlocks, and so on. Barring

hardware failure, the runtime aims for 100 percent availability.

ASP+ uses the Microsoft .NET Framework deployment model

based on assemblies, thus gaining all its benefits such as

XCOPY deployment, side-by-side deployment of assemblies,

and XML-based configuration. Another major benefit of ASP+ is

support for live updating of applications. An administrator

doesn’t need to shut down the Web server or even the applica-

tion to update application files. Application files are never

locked, so they can be overwritten even when the application is

running. When files are updated, the system gracefully switches

over to the new version. The system detects file changes,

launches a new instance of the application using the new

application code, and begins routing incoming requests to that

application. When all outstanding requests being processed by

the existing application instance have been handled, that

instance is shut down.

Within an application, HTTP requests are routed through a

pipeline of HTTP modules, ultimately to a request handler. HTTP

modules and request handlers are simply managed classes that

implement specific interfaces defined by ASP+. The pipeline

architecture makes it very easy to add services to applications:

just supply an HTTP module. For example, security, state

management, and tracing are implemented as HTTP modules.

Higher-level programming models, such as Web Services and

Web Forms, are generally implemented as request handlers. An

application can be associated with multiple request handlers—

one per URL—but all HTTP requests are routed through the

same pipeline.

The Web is a fundamentally stateless model with no correlation

between HTTP requests. This can make writing Web applica-

tions difficult, since applications usually need to maintain state

across multiple requests. ASP+ enhances the state manage-

ment services introduced by ASP to provide three types of state

to Web applications: application, session, and user. Application

state, as in ASP, is specific to an application instance and is

not persisted. Session state is specific to a user session with

the application. Unlike ASP session state, ASP+ session state

is stored in a separate process and can even be configured to

be stored on a separate machine. This makes session state

usable when an application is deployed on a Web farm. User

state resembles session state, but generally does not time out

and is persisted. Thus user state is useful for storing user

preferences and other personalization information. All the state

management services are implemented as HTTP modules, so

they can be added or removed from an application’s pipeline

easily. If additional state management services are required

beyond those supplied by ASP+, they can be provided by a

third-party module.

ASP+ also provides caching services to improve performance.

An output cache saves completely rendered pages, and a

fragment cache stores partial pages. Classes are provided so

applications, HTTP modules, and request handlers can store

arbitrary objects in the cache as needed.

Now let’s take a quick look at the two higher-level programming

models that build on the ASP+ programming model: ASP+ Web

Forms and ASP+ Web Services.

ASP+ Web Forms

Web Forms bring the productivity benefits of Visual Basic®-

based forms to Web application development. Web Forms

support traditional ASP syntax that mixes HTML content with

script code, but it also promotes a more structured approach

that separates application code from user interface content.

Web Forms controls are being introduced to provide a mecha-

nism for encapsulating common user interface elements. These

new features enable tools to support a design-time model along

the lines of Visual Basic, enabling WYSIWYG tool support for

Web page layout.

Web Forms controls are responsible for generating the user

interface, typically in the form of HTML. ASP+ comes with a set

of Web Forms controls that mirror the typical HTML user

interface widgets (including listboxes, text boxes, and buttons),

and an additional set of Web controls that are more complex

(such as calendars and ad rotators). One important feature of

these controls is that they can be written to adapt to client-side

capabilities; the same pages can be used to target a wide range

of client platforms and form factors. In other words, Web Forms

controls can “sniff’ the client that is hitting a form and return an

appropriate user experience—maybe HTML 3.2 for a down-level

browser and Dynamic HTML for Internet Explorer 5.0.

Given the stateless communication model of the Web, one of

the more complex issues facing Web application developers is

responding to user interaction with Web-based interfaces. Web

Forms take advantage of the ASP+ infrastructure to provide a

rich set of services to help developers build interactive Web

pages. The net effect of these services is to enable a compo-

nent-based, event-driven programming model much like client-

side forms programming for application developers. The com-

plexities of state management across user interaction with a

page are hidden by ASP+ Web Forms and Web Forms con-

trols. Rich data-binding services are also supplied, making it

very easy for application developers to display data retrieved

through the data access services.

The separation of code and content enables ASP+ pages to be

dynamically compiled into managed classes for fast perfor-

mance. Each incoming HTTP request is delivered to a new page

instance so that developers do not need to be concerned about

thread safety in their code.

(Con’t, page 5)

Page 4