Share via

Background: Content Entities in Microsoft SharePoint Foundation

  • Article

Applies to: SharePoint Foundation 2010

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

Overview

SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation must be built on a world of pages, a SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation. A Web application is represented by the SPWebApplication class.

Note

A site collection was called simply a "site" in the original version of SharePoint Foundation—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 SharePoint Foundation 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 SharePoint Foundation a Web site, a site collection, a content database, and a Web application are all, in a sense, partitions of the content in a SharePoint Foundation deployment.

SharePoint Foundation Web Sites

A SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation object model, see Physical Objects Hierarchy of Microsoft SharePoint Foundation.)

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 SharePoint Foundation Site Collections later in this article.

SharePoint Foundation Web Applications

A SharePoint Foundation 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 SharePoint Foundation Web application is more than just the highest-level grouping of Web sites. It is also the layer at which a SharePoint Foundation deployment is visible to IIS. Each SharePoint Foundation 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 SharePoint Foundation Web application are just one big Web site to IIS.

Note

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

Figure 1. IIS Manager on a SharePoint Foundation front-end web server showing the application pools and the IIS web sites

IIS showing websites and application pools

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 SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation Web application has its own process.

Some other critical differences between SharePoint Foundation Web applications and SharePoint Foundation 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 SharePoint Foundation Web applications.

Figure 1 shows IIS Manager (for ISS 6.0) immediately after SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation Web application instead of just a site collection, or even just a Web site, within "SharePoint – 80". Process isolation of the two SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation), "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 Physical Objects Hierarchy of Microsoft SharePoint Foundation and Services Hierarchy of Microsoft SharePoint Foundation.

SharePoint Foundation 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 SharePoint Foundation 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 SharePoint Foundation 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" SharePoint Foundation Web application for a given farm.)

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

  • If a new SharePoint Foundation solution is under development on a server (or set of front-end servers) that is also hosting a production SharePoint Foundation deployment, it can be implemented in a separate SharePoint Foundation Web application until after it has been thoroughly tested. This practice ensures that if the new solution crashes, production SharePoint Foundation 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 SharePoint Foundation hosting services to small customers typically give each customer its own SharePoint Foundation Web application. This practice ensures that the customer's Web sites are not brought down by errant code in another customer's SharePoint Foundation 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 SharePoint Foundation, 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 SharePoint Foundation object model. To IIS, the SSP is just one more Web site, and to SharePoint Foundation it is just one more Web application.)

Note

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

SharePoint Foundation Content Databases

Every SharePoint Foundation 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 SharePoint Foundation 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.

SharePoint Foundation Site Collections

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

  • SharePoint Foundation site collections enable more fine-grained administration of SharePoint Foundation deployments than is provided by SharePoint Foundation 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 SharePoint Foundation 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

Content Hierarchy of SharePoint Foundation

Physical Objects Hierarchy of Microsoft SharePoint Foundation

Background: Physical Objects in Microsoft SharePoint Foundation

Services Hierarchy of Microsoft SharePoint Foundation

Background: Service Entities in Microsoft SharePoint Foundation

Other Resources

SharePoint Foundation Administration

Windows SharePoint Services Administration Development Resource Center