Background: Content Entities in Windows SharePoint Services

  • Article

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This topic describes the hierarchy of content entities in Windows SharePoint Services 3.0. These entities are modeled by the higher level classes in the The Content Hierarchy of the Windows SharePoint Services object model. For background information about the physical and service entities in a Windows SharePoint Services deployment, see Background: Physical Objects in Windows SharePoint Services and Background: Service Entities in Windows SharePoint Services.

Overview

Windows SharePoint Services creates a new, abstract Web world in which lists and list items, instead of pages, are the primary entities in the population. But, to a browser, the World Wide Web (or an intranet) is a world of pages with links between them; and these pages exist as server-hosted files at particular URL addresses. So, while a Windows SharePoint Services site must present itself to users (and even to certain kinds of site administrators) as a world of lists, it must be implemented on top of an older world that dates to the early 1990s—a world of browser-rendered pages.

Because Windows SharePoint Services must be built on a world of pages, a Windows SharePoint Services Web site, which is represented by the SPWeb class, is a set of files—especially .aspx files—and associated data, users, and permission policies (although it is much more than just a set of files). The Web site may have subsites. (Subsites are also represented by the SPWeb class.) In addition, every Windows SharePoint Services deployment groups its Web sites into one or more site collections, which are represented in the object model by the SPSite class. Moreover, the site collections themselves are grouped into one or more sets that are called content databases, represented by the SPContentDatabase class. These are the children of one or more Web applications in Windows SharePoint Services. A Web application is represented by the SPWebApplication class.

Note

A site collection was called simply a "site" in the original version of Windows SharePoint Services—Microsoft SharePoint Team Services—which is why the class that represents a site collection is named SPSite. Similarly, what is called a "Web site" (or occasionally just a "site") in Windows SharePoint Services 3.0 was originally called a "Web". Therefore, the class that represents it is called SPWeb. Although an SPSite object represents a collection of things, the SPSite class is not a collection in the sense of a class that implements ICollection. An SPSiteCollection class implements the latter interface. It represents a collection of SPSite objects.

So, in Windows SharePoint Services a Web site, a site collection, a content database, and a Web application are all, in a sense, partitions of the content in a Windows SharePoint Services deployment.

Windows SharePoint Services Web Sites

A Windows SharePoint Services Web site, represented by the SPWeb class, is an ASP.NET Web site optimized for content management and collaboration. It differs from other ASP.NET applications mainly in these ways:

  • It deemphasizes pages and emphasizes lists and list items instead. For example, the Quick Launch of a Windows SharePoint Services site (of the STS type) presents a hierarchy of sites, subsites, and lists (including lists of lists), instead of pages as such. If you add a page to such a site, the new page appears in the Quick Launch as a new item in a list of shared documents, not as a child node under the home page or some other page.

  • It gives administrative powers to users. How much power any given user has is determined by the permissions granted him or her. End users commonly are able to create whole new Web sites (as subsites to an existing Web site) as well as add and edit content on existing Web sites.

  • It is one of four levels at which a Windows SharePoint Services Feature can be activated. The other levels are site collection, Web application, and farm. (For more information on the role of the farm in the Windows SharePoint Services object model, see The Physical Objects Hierarchy of Windows SharePoint Services.)

The fact that a Web site is a subset of the content of a site collection does not imply that the content of two Web sites in a given collection is mutually exclusive: a given list, for example, can appear on more than one Web site.

A hierarchy of Web sites in a site collection always has exactly one top-level Web site. You can learn more about the top-level Web site in the section Windows SharePoint Services Site Collections later in this article.

Windows SharePoint Services Web Applications

A Windows SharePoint Services Web application, represented by the SPWebApplication class, is foundationally a set of content databases, each of which contains site collections; and the site collections themselves are sets of Web sites, which in turn are sets of files.

But a Windows SharePoint Services Web application is more than just the highest-level grouping of Web sites. It is also the layer at which a Windows SharePoint Services deployment is visible to IIS. Each Windows SharePoint Services Web application is exposed through an IIS Web site and appears in the Web Site tree of IIS Manager. (See Figure 1.) So all of the site collections and Web sites (and subsites) in a Windows SharePoint Services Web application are just one big Web site to IIS.

Note

Terminology can be confusing here: what Windows SharePoint Services calls a "Web application" is served through one or more IIS "Web sites".

Figure 1. IIS Manager immediately after installation of Windows SharePoint Services 3.0 on a single server

IIS automatically gives each IIS Web site its own application pool when the site is created and each application pool has its own process. Thus, every Windows SharePoint Services Web application runs in its own process. If one of those processes crashes, the others continue to run. This is the most important way that a Windows SharePoint Services Web application differs from the lower layers in the object model hierarchy. Content databases and site collections do not have process isolation from each other, but Web applications do.

Note

Strictly speaking, the one-to-one relation of IIS Web sites to application pools does not have to be maintained. Within IIS Manager, Web sites can be moved from one application pool to another. Hence, multiple Windows SharePoint Services Web applications could be moved into the same pool and therefore share the same process. In some cases, the performance enhancement that comes from this kind of process sharing justifies the loss of crash protection. Nevertheless, process sharing is not frequently done. Therefore, this article assumes that each Windows SharePoint Services Web application has its own process.

Some other critical differences between Windows SharePoint Services Web applications and Windows SharePoint Services site collections:

  • Each Web application has one or more of its own child content databases, but each site collection belongs to just one parent content database (which it may share with other site collections that are enclosed in same Web application).

  • Security policies, such as authentication and enabling anonymous users, are set at the level of Windows SharePoint Services Web applications.

Figure 1 shows IIS Manager (for ISS 6.0) immediately after Windows SharePoint Services 3.0 is installed on a single server. Notice that the installation created two IIS Web sites and each site has its own application pool (and process). One of the IIS Web sites is for a main Windows SharePoint Services Web application that provides content to end users and is named "SharePoint - 80". (The "80" is the number of the server port through which requests for Windows SharePoint Services pages come.) The other is named "SharePoint Central Administration v3" and is used by IT professionals for high-level administration tasks. You can probably guess why this was made a separate Windows SharePoint Services Web application instead of just a site collection, or even just a Web site, within "SharePoint – 80". Process isolation of the two Windows SharePoint Services Web applications enables network administrators to access Central Administration even when errant code on some Web site within "SharePoint – 80" causes the latter Web application to crash soon after each restart. Moreover, making the administration application a separate Web application enables administrators to give it distinct policies regarding authentication and anonymous users.

If Windows SharePoint Services 3.0 is installed on a farm of more than one server and the configuration distinguishes between front-end servers and back-end servers (called application servers in Windows SharePoint Services), "SharePoint – 80" runs on only the front-end servers. "SharePoint Central Administration v3" runs on one, and only one, of the application servers. You can read more about farms and the different types of servers and their roles in The Physical Objects Hierarchy of Windows SharePoint Services and The Services Hierarchy of Windows SharePoint Services.

Windows SharePoint Services Web applications other than the "SharePoint Central Administration v3" application are called content-publishing Web applications.

When the initial "SharePoint - 80" Web application is created, and whenever any content-publishing Web application is created, a new content database is created for the Web application. In turn, a site collection is created for the database and a top-level Web site is created for the site collection.

More Than One Content-Publishing Web Application

At many small and medium-sized institutions, the two Windows SharePoint Services Web applications that are installed by default are the only ones that are ever created. This may be true even if use of the "SharePoint – 80" Web application is intensive enough to require a farm of servers to host it. But there are situations in which additional content-publishing Windows SharePoint Services Web applications are needed and, for each, an IIS Web site and corresponding application pool. Here are examples of some of those situations. (There is never more than one "Central Administration" Windows SharePoint Services Web application for a given farm.)

  • When an institution is gradually shifting from Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0, both may be deployed on the same server. In that case, each version has a separate Windows SharePoint Services Web application (or separate set of Web applications).

  • If a new Windows SharePoint Services solution is under development on a server (or set of front-end servers) that is also hosting a production Windows SharePoint Services deployment, it can be implemented in a separate Windows SharePoint Services Web application until after it has been thoroughly tested. This practice ensures that if the new solution crashes, production Windows SharePoint Services Web applications are not brought down. Additionally, the content database of the untested Web application is kept separate from the database of the production Web application. Finally, the untested Web application can be given a port number other than 80. This reduces the chance that any unauthorized person can access the application because, except for Web sites that use port 80, port numbers must be included in any Web URL; otherwise IIS cannot find the requested page.

  • Companies that provide Windows SharePoint Services hosting services to small customers typically give each customer its own Windows SharePoint Services Web application. This practice ensures that the customer's Web sites are not brought down by errant code in another customer's Windows SharePoint Services Web application. It also ensures that the customer's database cannot be accessed by other customers. Finally, it enables each customer to have distinct policies regarding authentication and anonymous users.

  • Web applications perform better when all the sites within them have similar structures. For example, a collection of "My Sites" would have many small sites; but a collection of team sites would typically have a smaller number of larger sites. Housing the team site collection in a separate Web application improves performance of both collections.

  • Any given Web application can have five separate sets of security policies—one for each of the five possible zones from which requests can come: the Internet, Intranet, Extranet, Default, and Custom zones. If more sets of policies are needed, additional Web applications can be created (possibly with content that is identical to an existing Web application), each with its own five sets of policies.

  • If enhanced collaboration server software, such as Microsoft Office SharePoint Server 2007, is installed in addition to Windows SharePoint Services 3.0, that software could allow logical grouping of Web applications. For example, it might do this to provide common services across the group or to administratively isolate the group from other Web applications. In such cases, the software may require creating a special Web application to serve as a logical parent or container of the group. This logical parent is called a Shared Services Provider (SSP). (However, such a logical grouping is not known to IIS 6.0 and is not modeled in the Windows SharePoint Services 3.0 object model. To IIS, the SSP is just one more Web site, and to Windows SharePoint Services 3.0 it is just one more Web application.)

Note

In Windows SharePoint Services 3.0, new Web applications are created on the Application Management tab of Central Administration, not in IIS.

Windows SharePoint Services Content Databases

Every Windows SharePoint Services Web application has at least one content database (represented by the SPContentDatabase class) that is automatically created when the Web application is created. More content databases can be added to a Web application as needed. A content database contains all the data (lists, list items, blog posts and comments, wiki pages, and documents in document libraries) and most of the page files that constitute the site collections that belong to the database.

Some of the files that belong to a site collection are stored in the file system of the front-end servers of the Windows SharePoint Services deployment. At first glance, this fact might seem to spoil the neat picture of site collections being subsets of content databases. However, even the files that are not stored in the content database are represented by rows in the database. The table row that represents such a file functions as a kind of alias for the file.

Windows SharePoint Services Site Collections

Site collections, represented by the SPSite class, exist as an administrative convenience to site owners, server administrators, and businesses that sell Windows SharePoint Services hosting services. Here are some of the most important characteristics of Windows SharePoint Services site collections:

  • Windows SharePoint Services site collections enable more fine-grained administration of Windows SharePoint Services deployments than is provided by Windows SharePoint Services Web applications, although administration of particular Web sites themselves still belongs to the site owners, who are usually not IT professionals.

  • Every site collection has one and only one top-level Web site. For some kinds of administrative tasks, the site collection and its top-level Web site can best be thought of as a single entity. For example, the Site Settings page of the top-level site has a Site Collection Administration area in which the owner of the top-level Web site can activate features for the site collection and restore any of the site collection's deleted content from the Recycle Bin. Also, you can create certain custom entities, such as a custom column, in the top-level Web site. Those entities are then available to all Web sites in the site collection.

  • Site collections straddle the boundary between the administrative responsibilities of site owners, and those of site collection administrators, who are usually IT professionals. As noted in the previous item, some administrative tasks at the site-collection level are handled by the owner of the top-level Web site. But server and network administrators can use the Application Management tab of Central Administration to create and delete site collections and set size quotas for site collections.

  • A site collection (or, speaking strictly, its top-level Web site) is the highest-level object in the breadcrumb navigation. (Although users of a subsite do not necessarily have access to every Web site higher in the hierarchy, they can see those sites in the breadcrumb navigation.)

  • A site collection is the level at which pools of site collection–scoped and Web site–scoped features, content types, lists, themes, and workflows are maintained and made available to subsites.

  • A site collection is one of four levels at which a Windows SharePoint Services Feature can be activated. The other levels are Web site, Web application, and farm.

  • A site collection is the level at which groups of users are maintained and assigned default rights. (Those rights can be changed at the level of any Web site, list, or list item. You can create groups on the Site Settings page of any Web site. But regardless of where the group is created, it exists at the site-collection level and is available to all Web sites in the collection.)

  • Master pages and Web Parts can be shared within a site collection but not among site collections.

  • A site collection is the highest-level object in the hierarchy for which access can be audited. It is also the level at which the auditing database is maintained.

  • A site collection is the highest level that can be included in a search.

See Also

Reference

SPWebApplication

SPDatabase

SPSite

Concepts

Server and Site Architecture: Object Model Overview

Working with List Objects and Collections

Overview: Using the Object Model to Customize Administration

Code Sample: Using the Administration Object Model

The Content Hierarchy of Windows SharePoint Services

The Physical Objects Hierarchy of Windows SharePoint Services

Background: Physical Objects in Windows SharePoint Services

The Services Hierarchy of Windows SharePoint Services

Background: Service Entities in Windows SharePoint Services

Other Resources

Windows SharePoint Services Administration

Windows SharePoint Services Administration Development Resource Center