Thu, 15 Nov 2007 18:07:39 GMT
An excellent session from another non-Microsoft presenter. Another one of these brain-the-size-of-a-planet guys who’s career seems to flit in and out of Microsoft. Rob worked at Microsoft on all versions of ASP.NET.
How the pieces fit together
ASP.NET is not just the page model we’re all used to. It’s also a complete request / response framework. You could implement php on it if you were that way inclined.
ASP.NET under IIS6 is simply a single ISAPI extension dll. This means you can use multiple versions of the .NET Framework alongside each other without conflicts; each lives in its own worker process.
Under the ASP.NET wp, it creates the HttpRuntime. The separate wp gives us true independence between apps on the same box. IIS6 has a kernel-level driver called http.sys, and creates a worker process w3wp.exe.
Http.sys introduces a concept called Kernel Mode Caching. This takes page cached items and stores and retrieves it from the IIS level, without drilling into ASP.NET, which gives us a lot more performance.
Role of HttpRuntime
- Customise and Extend ASP.NET
- Perform special authentication
- Take over .jpg extension
- Provide developrs a great way to innovate
ASP.NET runtime infrastructure
ASP.NET doesn’t care where it’s hosted; that is completely abstracted. HttpContext is created on hitting a page, and is flowed throughout the page lifetime. HttpHaners include all the various extension type: .aspx, .asph, .asmx.
HttpRuntime is the Request / Response infrastructure. It has access to everything you have access to in normal pages, without the Page model.
HttpRuntime can be hosted outside ASP.NET. This means you can process pages and their events outside IIS. Example of this is the Cassini web server. Another possible use would be in a tool that mirrors and flattens web sites to stage as HTML.
Synonymous with ISAPI filters. Can be used for request participation or termination of events etc. Interception Events can be coded with either IHttpModule components or global.asax. You can specify the order of precedence is .config. ISVs writing pluggable components would use Modules. A single project would probably use global.asax. Both provide the same functionality, but Modules are pluggable.
It’s good to get a canonical list of events in the right order. So here they are:
- Target Handler Extension (e.g. Page /.aspx)
Turn it off if you don’t need it
Set it to read-only if you can
Only set it to read-write where you’ll be updating it
A tool to help you create different Handlers for different request types.
Enables processing of Urls. Similar to ISAPI filters.
Encapsulates all request information. One instance created for each request, flowed throughout request lifetime. Developers can extend HttpContext.
For completeness, here is the canonical list of events that fire in the lifetime of a page.
- Target Control Events
- Load Complete
The presentation was excellent. Some detailed info, some just old hat. The Handler and Module stuff, while not new techniques, are traditionally the domain of the more hardcore ASP.NET developers. The question is why this detail, and why now? Well, my take on this is that there is a feature uplift coming: modularised ASP.NET in IIS7. This will create a whole new space for developers to play and write Modules and Handlers as first class citizens of the IIS pipeline. Microsoft wants us to play in that space, so that means getting folks used to the existing concepts now.