The added value WSS brings to the ASP.NET 2.0 development platform results from its extensibility model, which facilitates provisioning and storage for pages, lists, and document libraries. The provisioning can be driven through either custom code or user actions in the browser-based UI. Behind the scenes, WSS automatically works out how and where to store the content, and it also supplies the UI elements that let users add, view, and modify content.

I’m going to concentrate on the most significant developer enhancements to version 3, and on the accompanying changes in terminology.  Keep in mind that research and code samples for this article are based on the Beta 1 release of WSS. It’s possible that some of the terms and code might change in the released version.

WSS 3.0 provisioning starts with an IIS Web site. Before you can create your first WSS site, you need to run an administrative procedure that extends the WSS functionality to one or more IIS Web sites. With WSS 2.0, the term "virtual server" was used to describe an IIS Web site extended with SharePoint functionality. To avoid confusion with another Microsoft product of the same name, the WSS 3.0 documentation now refers to an IIS Web site extended with WSS functionality as a Web application.

WSS 2.0 was integrated with IIS 6.0 and ASP.NET 1.1 using an ISAPI filter DLL, which resulted in IIS routing requests to WSS before ASP.NET. That routing could be problematic in certain situations because WSS takes control of an incoming HTTP request before it has had a chance to be properly initialized with ASP.NET context.

But WSS integration with ASP.NET has been completely redesigned in version 3. First, WSS 3.0 is built on ASP.NET 2.0, which provides significant enhancements over ASP.NET 1.1. Furthermore, the routing infrastructure was improved by removing the ISAPI filter and by adding an HttpModule and an HttpHandler that are registered with ASP.NET using standard web.config entries. This means that incoming HTTP requests always enter the ASP.NET runtime environment and are fully initialized with ASP.NET context before they are forwarded to the code that carries out WSS-specific processing.

When you extend an IIS Web site to become a Web application, WSS 3.0 adds a wildcard application map to the IIS metabase. This map routes all incoming HTTP requests to the ASP.NET runtime regardless of file type (.pdf, .doc, .docx, and so on). ASP.NET then forwards the request to WSS for processing.

The new architecture also deals with shortcomings related to how .aspx pages are parsed and compiled. The .aspx page parser used by ASP.NET 1.1 works only with pages that reside on the local file system. But WSS architecture relies on storing .aspx pages in a SQL Server database so it couldn’t take advantage of the ASP.NET 1.1 page parser. And, unfortunately, the SharePoint parser developed in its place does not support many of the cooler features offered by the ASP.NET page parser.

But ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider. The idea is that a developer can write a custom component that retrieves .aspx pages (or any other content that ASP.NET processes) from any location, including a database such as SQL Server. Once a custom virtual path provider retrieves an .aspx page, it can then hand the page off to ASP.NET to conduct the required parsing and compilation. A separate component, PageParserFilter, lets SharePoint control how pages are parsed and compiled and what executes on those pages.

WSS 3.0 includes its own virtual path provider named SPVirtualPathProvider, as illustrated in Figure 1. As you can see, SPVirtualPathProvider is able to retrieve .aspx pages from SQL Server and then hand them off to the .aspx parser that is supplied by ASP.NET 2.0. As a result, WSS 3.0 does not suffer from a reduced feature set with respect to page parsing as did the previous version of WSS.

More information can be found at: http://msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview/default.aspx  & See this for details on WSS 3.0