2.1. Architectural Overview of SharePoint

SharePoint is a three-tiered application (see Figure 2-1). The presentation layer lives in the file system as an ASP.NET application, the logic lives in .NET assemblies, and the data resides in a SQL Server database. On the surface, Windows SharePoint Services is a web application platform that provides a collection of services accessed through SharePoint web pages, XML web services, and a .NET application programming interface (API). SharePoint's core functionality is provided by an infrastructure of .NET assemblies and Windows Services. SharePoint stores all content and configuration in SQL Server databases. These databases contain stored procedures and other potential points of interaction, but they should never be directly accessed or modified. Microsoft Office SharePoint Server (MOSS) augments WSS with features for portals (Chapter 8), search (Chapter 9), content management (Chapters 10 though 11), business processes (Chapter 14 and 15), and business intelligence (Chapter 16).

Upon installation, SharePoint requires a SQL database server and an IIS web server. The first database created is the configuration database. SharePoint is installed into a subtree popularly called the "12 hive" which defaults to the following location:

C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12

The 12 hive contains SharePoint's utilities, assemblies, resources, and the web services and web applications that compose its interface. SharePoint's next requirement is an IIS Virtual Server, also called a web site or web application. The first is the SharePoint Central Administration (SCA) site, which is created automatically on a random port of the server. You can think of this web application as an interface for the configuration database. Once SharePoint is configured, you can create sites.

Installing SharePoint to a web application is known as extending the web application. This modifies the web.config to include the SharePoint HTTPHandler, and to mark SharePoint objects as safe. For each SharePoint web application a content database is created, though it is also possible to connect a new web site to an existing content database in order to share data between front-end sites.

2.1.1. SharePoint's Scopes of Configuration

The scopes important to SharePoint for the configuration of the platform and its features are: the farm, the web application, the site (a.k.a. the site collection), and the web (formerly called the site in previous versions of SharePoint).

The farm is the server or set of servers that host SharePoint. Upon installation, roles are assigned to each server in the farm, and services are bound to servers based on roles and expected traffic patterns. The farm is also defined by its connectivity with external services, including Active Directory and Exchange Server. There is one configuration database per farm, and it is administered by any instance of the SharePoint Central Administration web application within the farm.

The web application is the IIS entity where an application pool context is set for SharePoint, and an address (URL) is defined by IP address, port, and/or host header so that each instance of SharePoint can be located with a web browser or mapped to a DNS common name. The web application has a physical web.config file to configure authentication and to mark components as safe, and virtual folders mapped to physical folders that contain ASP.NET files. These physical files are shared among all SharePoint web applications hosted in the farm. Web applications are discussed further in Chapter 13.

A SharePoint site (SPSite) is an object which contains webs (SPWeb). Developers refer to SPSites as "site collections." SPWebs are often referred to as "sites," especially within SharePoint's user interface (e.g., "Create Sites and Workspaces"). The top-level web, or RootWeb of an SPSite is usually positioned at the first folder in a SharePoint path (e.g., /personal or /sites), with the web application's root being an exceptional case of SPSite. Each SPSite contains resources available to all of the SPWebs it contains, including SharePoint features and special document libraries called galleries. Galleries exist to hold content types, site columns, Site Templates, List Templates, Web Parts, workflows, and master pages. Each of these is discussed in detail in Chapter 3.

An SPWeb is a web within a site collection, and each web may contain its own set of child webs. The RootWeb of a site collection provides an interface to manage the resources (e.g., the galleries) of the site collection. As noted previously, the nomenclature is falling back to the "old ways" of calling an SPWeb either a "site" or a "web site," and these terms are still used in the Site Settings and Create pages. Once a Feature is installed in a site collection, it is available to activate (or deactivate) in a web. Similarly, once a content type is installed in a site collection, it is available for assigning to libraries or publishing sites within individual webs.

Figure 2-2 depicts a MOSS site and two child webs that form one site collection, and a top-level site with two more webs that form another site collection.

2.1.2. SharePoint Farm Server Roles

Several server roles combine to make up the SharePoint small, medium, and large farm configurations. The three principal roles in a MOSS Farm are: Web Front-End, Application Server, and Database. A collection of servers assigned to a single role may be referred to as a node.

2.1.2.1. Web Front-End (WFE)

The web front-end node hosts the presentation layer of a SharePoint deployment. The WFE is either a single server or a set of network load balanced (NLB) servers that host SharePoint web sites and the Central Administration web site.

2.1.2.2. Application (App) or Shared Services Provider (SSP)

The application node hosts the logical layer of a SharePoint deployment, and contains more Shared Service Providers. A SSP provides a central point for MOSS services, including: the Index Service, the Query Service, profile import and management, audience management, content management logic, the Business Data Catalog, Excel Services, Forms Services, job scheduling, and usage reporting. Each SharePoint web application can have its own SSP (but not more than one), and multiple SharePoint Applications can share the same SSP.

2.1.2.3. Index

An Index server is configured to scan the content of SharePoint sites, external web sites, and Business Data Catalog data stores, capturing information used to build indices that facilitate high-speed searching from within SharePoint applications. This scanning process is called "content crawling." When there is more than one WFE, the Index role should either be installed on its own server (the SSP) or on the database server. The Index role creates one index per SSP and may provide this service for several SSPs though their indices can not be aggregated. Since the Index role manages just one index per SSP, a separate Index server can exist for each SSP.

The index is propagated to all Query servers unless the Query and Index Services reside on the same physical machine. Therefore, in a farm it is best for the WFE and Query roles to be paired on a machine, for a single machine to host shared services, including Search and Index, or for Index Services to be hosted on its own server in what might be called a shared services farm. However, the Index role cannot be made redundant; it cannot be clustered. If an Index server goes down, each Query server may continue to use a propagated index until the role is restored.

2.1.2.4. Query/Search

The Search server returns search results to the WFE or web service that calls it. Search may be installed on the same machine as the WFE role, the same machine as the Index role, or on its own server. It should not be installed to two servers where one is a WFE and the other is an Index server. In this scenario the index would not propagate from the Query/Index server to the Query/WFE service because (as described earlier) the index is not propagated if it resides on the same machine as the Query Service. WFE and Search roles are often combined for performance; in effect, the index is cached on the WFE and the separate Index server does not affect WFE performance.

2.1.2.5. WSS 3.0 Search and Index

If MOSS is not installed, Search and Index must reside on the same server.

2.1.2.6. Excel Calculation Server

Excel Server is responsible for rendering Excel and business intelligence (BI) data inside MOSS sites. It can be made redundant by assigning the role to all WFE servers, or to all Application servers. It is often paired with the WFE role for performance, even before the Query role is paired with WFEs. Excel Server requires MOSS Enterprise Edition.

2.1.2.7. Forms Server

Forms Server is responsible for rendering InfoPath forms published for web use. It can be made redundant by assigning the role to all WFE machines, or to all Application servers. Forms Server requires MOSS Enterprise Edition.

2.1.2.8. Database Server (SQL)

The database server stores SharePoint configuration, site content, personalization, and user profiles. Either SQL Server 2000 or 2005 will work, though MOSS is optimized for SQL 2005. Different editions of SQL Server 2005 allow different configurations. Express Edition may only be used in a SharePoint standalone configuration. Standard, Developer, or Enterprise Edition may be used for small and medium farms. Either Developer or Enterprise Edition is required to cluster the SQL Server role in a medium or large farm. Developer Edition may be used in development and testing environments, but Standard or Enterprise licenses must be obtained for each live production environment. The following table indicates which SQL Server Editions may be used in each environment:

SQL Version	Single SQL Server	SQL Cluster	Dev	Test	Production
WMSDE	Yes		Yes
SQL Express	Yes		Yes
SQL Developer	Yes	Yes	Yes	Yes
SQL Standard	Yes		Yes	Yes	Yes
SQL Enterprise	Yes	Yes	Yes	Yes	Yes

2.1.3. SharePoint Farm Configurations

Depending upon the number of servers available and your need for performance or redundancy, there are several recommended configurations from which to choose. SharePoint roles and components are modular, with the intent that when the performance of any single machine is overwhelmed by traffic, the extra load can be handled by intelligent expansion of the farm.

2.1.3.1. Stand-Alone: One Server

All SharePoint and database server roles are installed to a single server. See Figure 2-3.

2.1.3.2. Small Farm: Two Servers

All SharePoint roles are provided by one server, and the Database role is provided by another. See Figure 2-4.

2.1.3.3. Medium Farm: Three to Five Servers

In a medium farm, the WFE and APP roles are hosted on separate servers. The WFE role may be filled by two or more load-balanced servers, and the Database role may be filled by two or more clustered SQL servers. Note that if you have six or more servers you can technically build a medium farm (e.g., 3 WFE/1 App/2 SQL), but a large farm is likely to be a preferable configuration (2/2/2).

Two medium server farms are shown in Figures 2-5 and 2-6. The key similarities are that the WFE and APP roles are on separate servers, and APP remains on a single server. Although the APP server may be hosting MOSS Enterprise features as well (e.g., BDC, Forms Server, Excel Server), these are not detailed in the diagram.

2.1.3.4. Large Farm: Four or More Servers

A large farm has the WFE and database characteristics of a medium farm (with a three-machine minimum), and the services provided by the APP node are divided among several machines. For example, the APP layer may include one or more redundant Query servers, one or more Index servers (one per SSP), an Excel server, and a Forms server. Given the trend towards modular applications, it would be conceivable to host other non-SharePoint services in this layer, including Project Server, third-party applications, or an in-house application. Note that if you have four or five servers, a medium farm is more likely the preferable configuration.

A large farm is depicted in Figure 2-7. In this case, one WFE includes Search and two do not. This might be optimal if the load-balancing and routing hardware sets the affinity for a particular SharePoint URL to a single machine (perhaps with its own SSP), while requests to other SharePoint web sites are served by the remaining machines (perhaps configured with another SSP). Since the Index role remains separate from the Search role, this will work. In this case, the two Application and Index servers are likely each configured for a particular SSP as well. In addition, one (and optionally more) servers are each allocated to Excel Calculation and Forms.

2.1.4. SharePoint Composition

While understanding how to compose an intranet or extranet is not the focus of this book, it is useful to see how a well-structured MOSS site is arranged. The top-level intranet, public web site, extranet, and Team Sites in Figure 2-8 would each be created in distinct web sites (registered in DNS), each with its own content database. Personal My Site sites are a feature of the SSP and are optionally stored in a separate content database.

In SPS 2003 terms, the intranet corresponds to portal areas, Team Sites stay roughly the same, the public web site could be a Microsoft CMS web site in the DMZ, and the extranet would be hosted on a separate SharePoint deployment in the DMZ.

Note that the major Intranet site headings in Figure 2-8 (Products, News, Document Repository, Search Center, Report Center, etc.) for this business unit are not named according to organization chart boundaries (e.g., Sales and Marketing). The goal of an intranet is the same as for a web site: Everything is available within three clicks, and headings make it obvious what lies beneath. If you build an intranet site for each and every department, send a photographer around to take smiling pictures of teams in funny poses, and post "why we're the best department at Floobar" teasers, no one will visit any of these. Each site will be outdated in one month, and stagnant in two. Instead, build Team Sites and get individuals involved within their teams. Organizational charts and groupings of cross-department teams (e.g., committees, projects, or management) drive the hierarchy of Team Sites. Discovery of information drives the design of intranet portal sites.

2.1.5. SharePoint and ASP.NET

As you learned in the first chapter, SharePoint is composed of logical services. People do not directly use services. People need interfaces that provide pleasant and efficient user experiences. ASP.NET provides the human interface layer—or presentation layer—for SharePoint. ASP.NET web pages are a combination of static HTML (e.g., text and images) and dynamic controls whose contents or "rendering" are determined at runtime. For example, controls exist to display lists of data (e.g., the ListView control), tables of data (e.g., DataGrid and GridView controls), and form elements (e.g., DropDownList and Button controls).

While designing SharePoint 2007 (and that's what it really was before any decisions were made to make this feature part of the WSS 3.0 base or that feature part of MOSS Standard or MOSS Enterprise), the ASP.NET team was working on "Whidbey," which became ASP.NET 2.0 and Visual Studio 2005. Someone came up with the great idea to turn products like SharePoint and Content Management Server (CMS is a popular ASP.NET platform for building and publishing public web sites) into pure service platforms, and to move their presentation layer features into ASP.NET.

With this decision, ASP.NET 2.0 gained features like master pages (from CMS) and Web Parts (from SharePoint), as well as features that can be used as standards across platforms, including: form fields, the Authentication Provider model, and Site Maps. For example, the Authentication Provider model describes a consistent interface for credential stores (e.g., Active Directory, user names and passwords kept in a database, or MS Live, formerly Passport). When the interface is consistent, standard ASP.NET 2.0 controls for logging in, signing out, and changing passwords can be reused no matter which provider is present. WSS publishes Site Maps as an XML web service which ASP.NET Breadcrumb and Tree View controls consume to provide navigation on SharePoint pages.

Now that these elements are part of ASP.NET, a developer who understands the ASP.NET providers and related controls already understands most of what it takes to create a SharePoint page.

2.1.5.1. Elements of a SharePoint Page

A SharePoint page is a web page (*.aspx) which refers to a master page (*.master), and a style sheet (*.CSS). A master page often contains a standard page header with a company logo, a footer with links to copyright and privacy policies, plus asp:ContentPlaceHolder controls that determine where content will go. Each page that uses a particular master will contain asp:Content tags matched to the placeholders of the master. Unlike a standard ASP.NET page, a master page file and CSS file specified through the WSS user interface (specifically the Site Settings Menu) can override those set within the physical .aspx file stored on disk. Figure 2-9 provides a visual description of WSS page structure.

The processes and elements for building custom pages and master pages are described in Chapter 3.

2.1.5.2. Elements of a MOSS Publishing Page

The Publishing site is a Site Definition available in MOSS designed expressly for creating and deploying web content. It differs from other SharePoint web pages in that instead of creating a physical file and describing content (and Web Part zones) within asp:Content tags, this information is stored in the database as a Page Layout. Figure 2-10 depicts the composition of a Publishing Page.

Before creating a Publishing Page, a content type must be created in the site collection. This content type describes the fields that will contain the content on the page, typically text and images. A Page Layout is then created in the SharePoint Designer in which the fields of the content type are dragged into the layout. More than one Page Layout can be created for a content type. This too is published to the site collection. When a Publishing Page is created, the Page Layout is selected. Since the layout is by design bound to the content type, all the creator needs to do next is fill in the content fields for the new page. Like all SharePoint content, versioning and workflows are available, and beyond this a publishing schedule can be defined or assigned.

Web content management is further described in Chapter 13.

2.1.5.3. Site Templates and Site Definitions

When you extend a SharePoint server you select a Site Template. Templates exist for publishing sites, news sites, Team Sites, Meeting Workspaces, blog sites, Wiki sites and more. You can also save the sites you create as templates so that you can reuse formats over and over again. The default out-of-box templates are stored in the 12TEMPLATESiteTemplates path, and each template has its own subfolder. Developers call these templates Site Definitions. Each Site Definition contains ASP.NET page files (e.g., default.aspx and default.master), and the ONET.XML file that describes the navigation bars, features enabled, lists available for users to create, and document templates available to create new libraries. The Configurations section of ONET.XML allows the site definition to specify several configurations, each with specific features, lists, and Web Parts as well as their positions in the Web Part zones. For example, the STS Site Definition defines configurations not only for the Team Site, but also for the Blank Site and Document Workspaces.

When you select Save as template from the Site Settings menu, you are not saving a new site definition into the file system. Instead your template is saved in the content database and will then appear in the site collection's site template gallery. To be reused in another server's site collection, the Site Definition from which the Site Template was created must be present on the target server as well. The Site Template actually describes the deltas, or changes, which were applied to the Site Definition in order to arrive at the Site Template.

When you create a new SharePoint site based on a Site Definition, part of the configuration process is to note which definition was used, and this cannot be subsequently changed. In a similar manner, the configuration of each "live" site is also a collection of deltas applied by a site administrator. If personalization is enabled, then this second set of deltas is applied per user as well (where they exist).

One Site Definition that is new to SharePoint 2007 deserves mention: the Global template. This template is always provisioned before any other template and contains base lists, definitions for the galleries (the Site Template, List Template, master page, and Web Part galleries), and default master page.

To learn more about ONET.XML, custom Site Definitions and Custom List Definitions, refer to Chapter 4.

2.1.5.4. The SharePoint Page Request Lifecycle

To recap: When you create a site, you select a Site Template. What is described as a Site Template in the UI might actually be either a pure Site Definition or a template stored in the Site Template gallery that is based on a Site Definition. Wherever it comes from, the template includes pages like default.aspx, default.master, and a CSS file, although these physical files are not copied from the file system into the content database. Rather, their original location is noted in the database along with the location URL of the new site.

For example, when you create a new site with the Team Site template called MyTeamSite at the URL http://moss/myteamsite/, no physical site is created, but document entries are created in the content database based on the names of ASPX files found in the template. When http://moss/myteamsite/default.aspx is requested, IIS will hand control to the SharePoint HTTPHandler. SharePoint does a lookup in the content database, discovers that MyTeamSite is based on the Team Site Definition, and commences loading the default.aspx page from that base template. Any reconfiguration of the site is reapplied, then per-user personalization. When it comes time to render the MyTeamSite-specific content, this content is also rendered by SharePoint. Finally, the page is served by IIS in fulfillment of the request.