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 application 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 applications difficult, since applications usually need to maintain state across multiple requests. ASP+ enhances the state management 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 mechanism 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 component-based, event-driven programming model much like client- side forms programming for application developers. The complexities of state management across user interaction with a page are hidden by ASP+ Web Forms and Web Forms controls. 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 performance. 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