Understanding SharePoint Architecture

  Source:

1. http://media.techtarget.com/searchSAP/downloads/05_Jamison_ch04.pdf
2. http://msdn.microsoft.com/en-us/library/bb892189(v=office.12).aspx 

Operating System
MOSS 2007 is built on top of WSS 3.0, which, in turn, is built on top of the technologies and services provided by Microsoft Windows Server 2003.  The core platform services use the Microsoft .NET 2.0 Framework. This combination of Windows and .NET provides SharePoint the following technologies:

• Internet Information Services 6.0 (for hosting Web applications)
• ASP.NET 2.x and above master pages, content pages (Web part pages), Web parts, personalization, membership, and navigation
• Windows Workflow Foundation (part of .NET 3.0)

Database Services
Microsoft SQL Server (either SQL 2000 SP4 or SQL 2005) is the relational database used for storing all content, data, and configuration information used by Office SharePoint Server 2007. Yes, that means that all content (including large documents) is stored in the database and not as files in the file system. Other relational databases, such as Oracle or MySQL, do not work and are not supported. If a separate database is not specified during installation, a specialized version of SQL Server 2005 Express is installed locally. The SharePoint-specific version of SQL Server 2005 Express has a database limit of 4GB and cannot be managed directly by SQL Enterprise Manager. For this reason, most organizations install MOSS in a farm configuration and specify a separate SQL Server machine for the database server.


Windows SharePoint Services
Windows SharePoint Services 3.0 builds on the operating system and database services to add additional features, such as team sites and collaboration features. Specifically, WSS 3.0 provides the following platform
capabilities:

• Storage. Through content databases, which are literally SQL databases managed by SharePoint to accommodate the pages, data, and documents stored in the various portals, team sites, and workspaces
• Management. Administration pages with deep configuration options
• Deployment. Web farms, physical servers, and roles
• Site Model. Web application, site collection, and sites
• Extensibility. Features, Web parts, and templates

    
WSS provides more than just these core technology services. Microsoft decided to make WSS a powerful application out-of-the-box and thus provides the core collaboration features for MOSS:

• Document collaboration—check-in/out and versions
• Wikis and blogs
• RSS support
• Project task management (lightweight functionality, which should not be confused with Office Project Server 2007, also built on WSS 3.0)
• Contacts, calendars, and tasks
• E-mail integration
• Integration with Office client applications

Basically, Windows SharePoint Services is the solution that enables you to create Web sites for information sharing and document collaboration.




Office SharePoint Server 2007: Applications and Services

Office SharePoint Server is built on top of WSS to provide a few additional capabilities such as: 

• Portal. Templates, people, audience targeting
• Search. Search center, cross-site search
• Content management. Authoring, publishing, records management
• Business process. Forms server, line of business (LOB) integration
• Business intelligence. Excel services, Key Performance Indicator (KPI) lists, Report Center (not to be confused with Business Scorecard Manager and Office PerformancePoint Server 2007, which both provide additional BI capabilities)

Shared Services


Shared services provide the features that are used by multiple applications in MOSS 2007. What does that mean? Let’s use an example—user profiles.  You might want to use the user profile feature, which provides an out-ofthe-
box employee directory, including basic information (name and phone number, for example), along with some custom properties and a photograph.  You might also want to create several different portals within your
organization—for example, an Internet presence, an employee intranet site, and a collaboration portal for self-service team site use. You wouldn’t want to create and manage three separate profile databases. In this case,
the user profile service can be shared across the various portals—hence a shared service. Specifically, the following features are provided by shared services in MOSS 2007:

• User profile store
• Audiences
• Search services
• Usage reporting
• Excel services
• Business Data Catalog (BDC)
• Notification service for generating alerts
• Single sign-on services

So what exactly do shared services support? They support the fundamental element of SharePoint: sites. Some of a site’s services are site-specific, while others are shared and provided by a Shared Services Provider (SSP)

Sites and Site Collections

At the highest level, you have a physical server running Internet Information Server (IIS). Within IIS, you have a Web application, which maps to a URL (such as http://myportal), a port (such as 80), and an IP address (such as

192.168.1.4). Once a Web application is extended with SharePoint functionality, one or more top-level sites can be created. Each top-level site can contain one or more child sites. The collection of sites that includes a toplevel

site and all of its descendants down to the leaf site(s) is called a site collection. This is important given that much of SharePoint administration (quotas, backup and restore, permissions, Web part access, and so on) is based on the site collection concept.

A site collection is a hierarchical set of sites that can be managed together. Sites within a site collection have common features, such as shared permissions, galleries for templates, content types, and Web parts, and they often share a common navigation. All sites in a site collection are stored together in the same SQL database. A portal site is often implemented as a site collection with the top-level Web site as the portal’s homepage.

some features do not work

 

Content Types. How common documents, forms, and other content are normalized in your organization.

Content by Query Web Part. This Web part aggregates information from across sites but does not work across site collections.

Workflow. When you deploy workflow, it is accessible only within the site collection it is deployed in.

Information Management and Retention Policies. Records management policies are set at the site collection level, forcing organizations to deploy the same policy multiple times for large enterprises.

Quotas. You should absolutely define quotas so that users are used to limited storage from day one; also configured at the site collection level, which means that you will need to configure quotas separately at each top-level site.


IIS Web Sites and Virtual Directories

Both ASP.NET and Windows SharePoint Services rely on IIS 6.0 to supply the underlying listening mechanism to process incoming HTTP requests and supply a management infrastructure for launching and running worker processes on the Web server. Your understanding of how all of the pieces fit together should start with the basic concepts of an IIS Web site and virtual directories.

An IIS Web site provides an entry point into the IIS Web server infrastructure. Each IIS Web site is configured to listen for and process incoming HTTP requests that meet certain criteria. For example, an IIS Web site can be configured to handle requests coming in over a specific IP address or port number or can be routed to the Web server by using a specific host header, such as http://extranet.litwareinc.com/.

IIS automatically creates and configures an IIS Web site named Default Web Site that listens for HTTP requests coming in over port 80 on any of the IP addresses supported on the local Web server. It is also possible to create and configure additional IIS Web sites by using the IIS Administration tools.

Each IIS Web site defines a specific URL space. For example, the standard Default Web Site defines a URL space to handle any incoming request whose URL maps to the following pattern: http://www.Litwareinc.com/*. As you can imagine, an unlimited number of URLs can be created within this URL space. IIS processes incoming requests targeted to one of these URLs by routing them to the Default Web Site.

Each IIS Web site is configured to map to a root directory, which is a physical directory on the file system of the hosting Web server. For example, standard configuration for IIS maps the Default Web Site to a root directory located at C:\Inetpub\wwwroot. In the most straightforward routing scenarios, IIS maps incoming HTTP requests to physical files inside the root directory. For example, IIS will respond to a request for http://www.Litwareinc.com/page1.htm by simply loading the contents of the file located at c:\Inetpub\wwwroot\page1.htm into memory and streaming it back to the client.

One important aspect of an IIS Web site is that it controls whether incoming requests require authentication and, if so, which authentication protocols to use. For example, the Default Web Site might be intended as a public-facing Web site for Internet users. As such, it might be configured to allow anonymous access and to support Basic Authentication. A secondary IIS Web site intended exclusively for employee use within the corporate LAN might be configured to disallow anonymous access and to support Integrated Windows Authentication instead of Basic Authentication.

In addition to IIS Web sites, IIS supports the creation and configuration of virtual directories. A virtual directory is an entity that defines a child URL space nested within the URL space of its parent IIS Web site. Like an IIS Web site, a virtual directory is configured with a root directory on the file system of the hosting Web server. IIS provides the flexibility of defining the root directory for a virtual directory at any location. For example, you could create a virtual directory within the Default Web Site with a URL space such as http://www.Litwareinc.com/Sales. When you create this virtual directory, you can configure its root directory as a file system directory such as C:\WebApps\Site1.

Notice that IIS tracks configuration information about its IIS Web sites and virtual directories in a repository known as the IIS metabase. The IIS metabase lives on the file system of each front-end Web server running IIS. For example, when you create and configure an IIS Web site using the IIS administration utility, IIS tracks these changes by writing entries to the local IIS metabase.

Search. Certain features of search are configured at the site collection level.

across site collections. This is important because a large deployment of SharePoint will dictate multiple site collections. The following features do not work across site collections: