2.1. SharePoint Architecture
In WSS 2.0, SharePoint was integrated into ASP.NET 1.1 via an ISAPI filter (see Figure 2-1). This ISAPI filter was needed because ASP.NET 1.1 had no mechanism that enabled applications to reroute how the source of a file was retrieved: ASP.NET 1.1 always assumed the files lived on the file system. This ISAPI filter presented many challenges in WSS 2.0, specifically in the areas of performance and extensibility. It was not easy to do things such as add custom HTTP handlers or modules, leverage custom user controls (ASCXs), or plug custom code into the ASP.NET page life cycle, changing the execution process.
Thankfully, Microsoft dramatically changed the fundamental architecture of WSS 3.0 from the previous release (WSS 2.0). This is largely due to the fact that the ASP.NET 2.0 team added functionality and certain hooks that enable third-party developers to customize the ASP.NET 2.0 infrastructure. The most significant addition to ASP.NET 2.0 is the virtual path provider, which abstracts the location of the requested files from ASP.NET. ASP.NET 2.0 utilizes a built-in virtual path provider that retrieves files from the file system by default, but the virtual path provider enables developers to plug in custom providers to customize the source of the requested files.
For more information on the virtual path provider, refer to the ...