Microsoft Windows SharePoint Services 2.0 Architecture

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The architecture for from Microsoft is improved and enhanced for Microsoft . In , site settings and information, along with all site content such as all list data, all documents in document libraries, and other page content is now stored in the Microsoft SQL Server computer or Microsoft SQL Server 2000 Desktop Engine (Windows) (WMSDE 20) database. It is no longer split between the file system and the database. This change was made primarily for the following reasons:

  • To enable to perform well in much larger installations. Data in the database can be managed transactionally, so that the Web site does not need to be locked whenever a file is saved.

  • To improve server availability. If you have multiple stateless Web servers in a server farm, when one fails, another can take over without losing access to any content.

  • To improve the integrity of the stored data. The possibility of conflicts between database and file system information is removed, and the database can be easily backed up.

Furthermore, because the new architecture greatly reduces the dependency on the Microsoft Windows registry and the Internet Information Services (IIS) metabase for each server that runs , you can now create a server farm system with multiple servers and host many more Web sites than you can with .

Configurations

You can choose between two configurations for : stand-alone server or server farm. If you anticipate only light usage of your Web sites, you can use the stand-alone server configuration. If you are supporting Web sites in a large organization or as an Internet service provider (ISP), and anticipate heavy usage and a lot of data, you will most likely want to use the server farm configuration.

Stand-alone Server Configuration

A stand-alone server configuration has the following characteristics:

  • There is a single server running .

  • Multiple sites and subsites are grouped in site collections on each virtual server in IIS that is extended with . An Internet Server Application Programming Interface (ISAPI) filter maps incoming Uniform Resource Locator (URL) to specific sites on that virtual server.

  • Scaling is achieved by adding site collections to an existing virtual server, or by adding subsites to an existing site collection.

  • Each virtual server has its own set of content database in SQL Server or WMSDE. The configuration database directs each virtual server to the appropriate content database for a given Web site. The content for the top-level Web site and any subsites within a site collection is stored in the same content database.

The following diagram illustrates the architecture for the stand-alone server configuration.

Cc767367.ZA010196521033(en-us,TechNet.10).gif

This diagram shows a similar architecture to the one used for , with the exception that all data is now in the SQL Server database rather than split between the database and the file system.

Server Farm Configuration

A server farm configuration has the following characteristics:

  • There are multiple separate servers running and SQL Server.

  • Multiple sites and subsites are grouped in site collections on each virtual server in IIS that is extended with . An ISAPI filter maps incoming URLs to specific sites on that virtual server.

  • Each virtual server has its own set of content databases in SQL Server. The configuration database for the server farm directs each server to the appropriate content database for a given Web site. The content for the top-level Web site and any subsites within a site collection is stored in the same content database.

  • Performance and capacity are increased by adding additional servers running and SQL Server.

  • Scaling is achieved by adding more front-end Web servers (to increase throughput for the existing content), and by adding top-level Web sites and subsites (to support more content).

  • Load balancing is achieved by using switching and routing hardware, or by using software such as Windows Network Load Balancing Service.

The following diagram illustrates the architecture for the in a server farm configuration.

Cc767367.ZA010196531033(en-us,TechNet.10).gif

In this diagram, you can see the larger effects of the architecture change. Because site information is stored in the content databases, you can distribute the load among several front-end Web servers running , and they can all communicate with the appropriate database. So, a request coming from the client can go to any of the front-end Web servers and still be able to connect to the correct Web site data.

In a server farm, each front-end Web server running can have multiple virtual servers. Each virtual server, in turn, can have multiple site collections, which can have one top-level Web site and multiple subsites. The following diagram illustrates this hierarchy.

Cc767367.ZA060503411033(en-us,TechNet.10).gif

About Virtual Servers

A virtual server is a way of breaking up the Web server structure, giving you finer control over settings for particular groups of Web sites. So, rather than configuring a setting for an entire server, you can configure it for just a virtual server. You can also configure authentication on a virtual server basis, so that different virtual servers can use different authentication methods. If you have some sites that are internal to an organization, and some that are accessible from the Internet, you can host them on separate virtual servers and use the appropriate authentication method for each environment.

Note: Virtual servers are called Web sites in Internet Information Services (IIS).

Using virtual servers can also allow you to isolate Web sites from one another. You can specify different application pools for each virtual server, and be sure that changes made to a site on one virtual server will not accidentally be transferred to another site on a different virtual server. For more information about application pools and processes, see Windows SharePoint Services Security Model or IIS 6.0 Help.

supported approximately 1000 virtual servers per server. supports many fewer virtual servers per front-end Web server (approximately 10). This difference is a result of the use of ASP.NET, which creates a separate set of compiled DLLs for each virtual server. Because uses several large DLLs, it is not practical to have them all in memory at the same time. (When you extend a virtual server, approximately 50 MB of memory is taken up by the base working set of processes, including ASP.NET.) However, because you can host multiple site collections on each virtual server, you should not need to create as many separate virtual servers in as were needed in .

Structuring the URL Namespace

can be used in a variety of environments, from the small, departmental server to a large server farm at an ISP. To suit these environments, running on an IIS 6.0 platform allows you to set up your URL namespace in several configurations, each of which is based on the type of site you want to create. supports the following types of sites:

  • Domain-named sites

    You can create multiple site collections with a network domain name as the URL, for example, https://mysite or https://mysite.mycorp.com. Use domain-named sites to allow users to create short, simple URLs.

  • Subfolder-named sites

    You can also create multiple site collections that are named as subfolders of a domain URL, for example, https://myserver/sites/mysite or https://www.mycorp.com/myOffice/MyGroup/mysite. Use subfolder-named sites to show the hierarchy of sites in your organization.

You can choose between these types of sites depending on your organization's needs. After you decide which basic site types you will support, you can choose from the following namespace configurations:

  • One domain-named site per virtual server

    For example, Server1 contains https://site1, https://site2, and so on. Each top-level Web site is a separate virtual server and has its own database. This scenario allows each site to be isolated for billing or security purposes.

  • Multiple subfolder-named sites per virtual server

    For example, Server1 contains the sites https://server1/portal1, https://server1/portal2, https://server1/webapp, and so on. Each virtual server can host multiple sites based on , and the same virtual server can also host Web applications. All of the sites for that virtual server can share the same content database. This allows team Web sites to coexist with portals and other Web applications.

  • One domain-named site and multiple subfolder-named sites per virtual server

    For example, Server1 contains the sites https://portal/teams/site1, https://portal/teams/site2, https://portal/webapp, and so on. The virtual server contains a top-level Web site based on . Subfolders of that site can be Web sites based on , or be used for Web applications. All of the sites based on for the virtual server share the same database.

  • Two virtual servers hosting the same content (extranet scenario)

    For example, Server1 hosts https://portal and Server2 hosts https://portal.company.com. Both of the virtual servers (and they can be on separate server computers) share the same content database, and provide the same site content to create an intranet and extranet. The two servers can have different security settings in IIS (for example, requiring SSL access on the external site, and anonymous access for internal), but share content. Note that the Recalculate hyperlinks feature cannot work in this scenario, because fixing the links for one URL path would break the links for the other.

  • Multiple domain-named sites per virtual server (large-scale hosting scenario)

    For example, Server1 hosts https://user1.company.com, https://user2.company.com, https://user3.company.com, and so on. Each of these sites is a top-level Web site on the same virtual server, but they are mapped to different URLs. There can be one or many content databases, depending on the scale.

Communication Between the Client and Server

The client communicates with using HTTP, the same protocol Web browsers and Web servers use to communicate. FrontPage implements a remote procedure call mechanism on top of the HTTP POST request, so that the FrontPage client can request documents, update the Tasks list, add new users, and so on.

The Web server sees POST requests addressed to the Internet Server Applications Program Interface (ISAPI) filter for and directs those requests accordingly. FrontPage correctly communicates between client and server through proxy servers (firewall).

Note: FrontPage does not use the HTTP PUT request. As described in the HTTP specification, PUT sends a document to a Web server; however, few Web servers implement PUT. Therefore, the FrontPage client uses the universally implemented HTTP POST request for all communication with .

does not follow the "create and then publish" model you may be accustomed to with other Web sites. The moment you create a Web site based on it is live on the server; you do not need to publish the Web site to another server. You can still edit the Web site in a compatible Web page editor, such as , or add pages and documents to the site, but you do not need to publish your changes they take effect immediately when you save the files.

Mapping URLs to Physical Paths

handles the mapping of incoming URLs to the site content in the databases. When using the server farm configuration, multiple sites are stored in each content database. A configuration database keeps track of which sites are mapped to which content database. The content databases themselves store all site content and provide the appropriate content when the front-end Web servers request it. In , because site content was stored both in the file system and in the IIS metabase, IIS was responsible for URL mapping.

Because the mapping between a site and the content database is based on the site's URL, two URLs cannot point to the same site. For example, you cannot use both https://www. server_name .com/site1 and https://www. server_name .com/site2 to point to the same content in the database. You can, however, achieve the same effect by setting up https://www. server_name1 .com/site1 to redirect to https://www. server_name2 .com/site1. The exception to this rule is an intranet/extranet scenario, where you can have two virtual servers map to the same site content with URLs such as https:// server_name /sites/ site_name and https://extranet. company_name .com/sites/ site_name . For more information about setting up this type of scenario, see Configuring Two Virtual Servers to Host the Same Content .

Handling ASP.NET Pages (ASPX Pages)

uses ASP.NET pages (Active Server Pages (ASP pages) or ASPX pages) for forms and lists. These pages can be customized, and you can add additional ASP.NET pages to run custom solutions on top of .

ASP.NET pages in the _layouts directory for a SharePoint site run in direct mode, which means they are allowed to run directly. The _layouts directory contains fixed application pages for , such as the Create List, Create Field, and Site Settings pages. This directory is considered outside of the Web site, and these pages are supplied directly by IIS as requested.

ASP.NET pages inside a Web site run in safe mode. In safe mode, the ASP.NET page does not get compiled into a DLL and only a specific set of controls (identified previously as "safe") are allowed to run. You can edit the list of "safe" controls allowed to run in Web sites on a specific virtual server by editing the web.config file for a virtual server. For more information about customizing or adding ASP.NET pages in , see the .