Windows SharePoint Services 3.0 provisioning starts at the level of the IIS Web site. Before you can create your first Windows SharePoint Services site, someone must run an administrative procedure to extend 3.0 functionality onto one or more IIS Web sites. In Windows Share- Point Services 2.0, the term virtual server was used to describe an IIS Web site that had been extended with Windows SharePoint Services functionality. To avoid confusion with another Microsoft product of the same name, the Windows SharePoint Services 3.0 documentation now refers to an IIS Web site extended with Windows SharePoint Services functionality as a Web application.


        Windows SharePoint Services 2.0 was integrated with IIS 6.0 and ASP.NET 1.1 using an ISAPI
        filter DLL. This integration technique results in IIS routing requests to Windows SharePoint
        Services before ASP.NET. This routing has proven to be problematic in certain situations
        because Windows SharePoint Services takes control of an incoming HTTP request before it
        has a chance to be properly initialized with ASP.NET context.


        The way in which Windows SharePoint Services 3.0 integrates with ASP.NET has been completely
        redesigned. First of all, Windows SharePoint Services 3.0 is built upon ASP.NET 2.0,
        which provides significant enhancements over ASP.NET 1.1. Furthermore, the integration
        between Windows SharePoint Services 3.0 and ASP.NET 2.0 was changed to route incoming
        requests through the ASP.NET runtime before Windows SharePoint Services. The Windows
        SharePoint Services team achieved these improvements to the routing infrastructure by
        removing the ISAPI filter and adding an HttpModule and an HttpHandler that are registered
        with ASP.NET using standard Web.config entries. This means incoming HTTP requests
        always enter the ASP.NET run-time environment and are fully initialized with ASP.NET context
        before they are forwarded to the code written by the Windows SharePoint Services team
        to carry out Windows SharePoint Services–specific processing.

        Also note that when you extend an IIS Web site to become a Windows SharePoint Services
        Web application, Windows SharePoint Services 3.0 adds a wildcard application map to the IIS
        metabase. This wildcard application map serves to route all incoming HTTP requests to the
        ASP.NET runtime regardless of their extension. This wildcard application map is necessary to
        forward a request for any type of file (for example, .pdf, .doc, .docx) to ASP.NET, which then
        forwards the request to Windows SharePoint Services for processing.

        Another relevant issue of the new architecture has to do with how .aspx pages are parsed and
        compiled. The .aspx page parser used by ASP.NET 1.1 works only with .aspx pages that reside
        on the local file system. However, Windows SharePoint Services architecture relies on storing
        .aspx pages inside a SQL Server database. Since Windows SharePoint Services 2.0 relies on
        ASP.NET 1.1, the Windows SharePoint Services team had to create their own .aspx page
        parser. Unfortunately, the .aspx parser of Windows SharePoint Services 2.0 does not support
        many of the richer features offered by the ASP.NET .aspx page parser.

        ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider.
        A developer can write a custom component that retrieves .aspx pages for any location including
        a database such as SQL Server. Once a custom virtual path provider retrieves an .aspx
        page, it can then hand it off to ASP.NET to conduct the required parsing and compilation.
        ASP.NET also gives the virtual path provider a good deal of control as to how .aspx pages are
        parsed and whether they are compiled or run in a non-compile mode.

        The Windows SharePoint Services 3.0 team has created their own virtual path provider
        named SPVirtualPathProvider, which is shown in Figure 1-1 on the next page. As you can see,
        the SPVirtualPathProvider is able to retrieve .aspx pages from SQL Server and then hand them
        off to the .aspx page parser supplied by ASP.NET 2.0. That means the Windows SharePoint
        Services 3.0 team was not required to evolve their .aspx page parser from the previous version.
        It also means that Windows SharePoint Services 3.0 does not suffer from a reduced feature
        set with respect to page parsing as it does with Windows SharePoint Services 2.0.

        If you’re familiar with the architecture of Windows SharePoint Services 2.0, you’ve probably
        heard the terms “ghosting” and “unghosting” used in conjunction with the .aspx pages of a
        Windows SharePoint Services 2.0 site. Page ghosting is a Windows SharePoint Services feature
        that allows a front-end Web server to store an .aspx page template on its local file system
        and to share that page template across many different sites. Page ghosting offers performance
        benefits because Windows SharePoint Services can serve up pages for thousands of sites
        using a page template stored on the local file system and loaded into memory a single time.Windows SharePoint Services 2.0 supports user modifications to the page template using
        tools such as Microsoft Office FrontPage 2003. Once a user modifies a page template and
        saves the changes, a customized version of the page is stored on SQL Server for that particular
        site. In Windows SharePoint Services 2.0, this is often referred to as unghosting a page.

        Windows SharePoint Services 3.0 still supports page templates that live on the Web server as
        well as customized versions of those page templates that are stored on SQL Server. However,
        the Windows SharePoint Services team and their documentation have stopped using the
        terms ghosting and unghosting because they do not translate well into other spoken languages.
        In Windows SharePoint Services 3.0, the term “uncustomized page” refers to a page
        template used directly from the local file system of the Web server, and the term “customized
        page” refers to a modified version of the page template that has been written to the content
        database for a particular site.

        Another change to be aware of is that Microsoft Office FrontPage 2003 has been renamed in
        its new release as Microsoft Office SharePoint Designer 2007. Like the previous versions of
        FrontPage, Office SharePoint Designer 2007 is targeted more toward users than developers.
        However, it’s nonetheless a handy tool to have in your bag of tricks as a Windows SharePoint
        Services developer.

        Office SharePoint Designer 2007 provides a code editor and WYSIWYG designer for customizing
        .aspx pages within Windows SharePoint Services 3.0 sites. You can also create new
        pages within a Windows SharePoint Services site that have no corresponding page template
        on the Web server. Office SharePoint Designer 2007 supports creating lists and document libraries and even supplies a new wizard for creating custom workflows on a Windows Share-
        Point Services site. Workflows in Windows SharePoint Services 3.0 will be discussed in more
        depth later in this chapter.