SharePoint 2010 Architecture Overview

Services on a SharePoint farm can be usefully divided into four groups:

• Windows Services
• Web Services
• IIS Web Services
• Configuration Services

For details and examples of each of these four kinds of services, see Background: Service Entities in Microsoft SharePoint Foundation.
Services in the latter two categories can be created to conform to the Service Application Framework. Many of the services built-in to SharePoint Foundation and SharePoint Server implement the framework. Moreover, the framework lets developers build scalable middle-tier shared services that are hosted in SharePoint Foundation.
A service that conforms to the framework can be split into multiple configured farm-scoped instantiations (CFSIs). Each of these provides the functionality of the service, but each has its own individual permission and provisioning settings. A CFSI is not an actual running process on a particular server. The same CFSI can be running on multiple servers, but it is not the same as the entirely abstract service itself either. Each of the servers on which the CFSI runs has its own actual instance (a running process) of the CFSI. Moreover, more than one CFSI of a given service can be running on the same server or servers. Thus, the framework provides a means for different versions of the same basic service to be available simultaneously. A consuming application on a front-end web server can target a specific CFSI.
Figure 8 shows the services and service instances on a hypothetical 10-server farm. This figure is repeated, with a more detailed explanation of its contents, in Background: Service Entities in Microsoft SharePoint Foundation. For this article, note only that the light translucent rectangles represent services, the darker translucent rectangles represent CFSIs (also known as service applications), and the smaller solid rectangles represent instances of services. The CFSIs are present only for the services that implement the Service Application Framework, which in this example are the Usage Service, the Application Discovery and Load Balancer Service, the Security Token Service, and the BDC Service.


Figure 8. Services and service instances on a typical 10-server farm

Applications that need to consume a particular CFSI of a service do so through proxies. The front-end web server that hosts the application has a proxy to represent the service itself and a second proxy to represent the CFSI that is being targeted. The proxies are not depicted in Figure 8, but Figure 9 shows a single-server SharePoint Foundation farm immediately after installation. Note also the following:

• Web services that implement the Service Application Framework are represented with a dot-bordered box. At initial installation, each has a single CFSI, sometimes called a "service application".
• The service proxies belong to the farm, but each CFSI proxy (also known as a service application proxy) belongs to a web application. The content publishing web application and the Central Administration web application each have their own proxy for the Business Data Catalog CFSI, and they each have their own for the Usage and Health Data CFSI. Neither has a proxy for the Subscription or Application Discovery and Load Balancer CFSIs at initial installation.

Figure 9. Services, CFSIs, service instances, and web applications in a new single server deployment

For more information about services in SharePoint and the Service Application Framework architecture, see Background: Service Entities in Microsoft SharePoint Foundation, Service Application Framework Architecture, and SharePoint Service Application Topologies.

Figure 1 shows how SharePoint Foundation is built on Microsoft .NET Framework 3.5, ASP.NET, and Internet Information Services (IIS). SharePoint is also built on SQL Server, but you can install SQL Server on a dedicated server that does not have SharePoint installed, which is typical in a production farm. All of these platforms must be running on a 64-bit installation of Windows Server 2008 on the server computers. SharePoint Server, in turn, is built on SharePoint Foundation. There are two editions of SharePoint Server: Standard and Enterprise.

Figure 1. The platform stack for SharePoint development

 Perhaps the most noteworthy aspect of the figure is that IIS and ASP.NET are shown as a single platform. This is because SharePoint requires that IIS operate in integrated mode with ASP.NET. Hence, from a SharePoint point of view, they are effectively a single web-hosting application. For more information about this, see the next section, SharePoint as an ASP.NET-IIS Application.

In Figure 1, the smaller boxes that have no fill represent some selected subparts of the platform that contains them, or on which they depend. The two thin, downward-pointing arrows indicate some specific dependencies that are shown only as examples. Many other specific dependencies are not shown in the figure. The thick, left-pointing arrows indicate that the entity on the right side accesses the entity to which the arrow points. For example, BCS accesses external databases.

SharePoint as an ASP.NET-IIS Application

The highest level of organization in a SharePoint deployment, other than the farm itself, is the web application. A web application in SharePoint terminology is closely related to what is called a website in IIS terminology. An IIS website monitors for incoming requests through a particular port, and it checks for a particular host header or IP address, or both. Every SharePoint Foundation web application is hosted in an IIS website that has the same name as the web application. It can be helpful, especially when you are trying to see the relation between SharePoint and IIS from a high and broad perspective, to think of the SharePoint web application and its corresponding IIS website as a single entity.

Nevertheless, the SharePoint web application and the IIS website are not quite the same thing (and they are represented by different classes in the SharePoint object model: the SPWebApplication class and the SPIisWebSite class). For one thing, although there is usually a one-to-one relation between SharePoint web applications and IIS websites, this is not always the case. It is possible to extend a SharePoint web application to multiple IIS websites, although that is not a common design.

Figure 2 shows the IIS websites and application pools on a SharePoint Foundation front-end web server.

Just as in any application that is built on the ASP.NET-IIS integrated pipeline, when a front-end web server receives a request from a client for a page or other resource in a SharePoint site, the request is passed through a pipeline of units that process the request. This processing includes authenticating the user, verifying the user’s authorization, building the response, sending the response, and finally, logging the request. For more information about the integrated pipeline, see ASP.NET Integration with IIS 7.

The response to any request is produced by an HTTP handler object. Requests are assigned to one or another HTTP handler object (or to a handler factory class that creates HTTP handler objects) depending on the resource requested and the HTTP verb in the request. The assignment is determined by a stack of configuration files named applicationhost.config, machine.config, and web.config.

The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the life cycle of the request. They are often used to preprocess requests or postprocess the response. The result of a module’s preprocessing is stored in the HttpContext object. For example, the value of the User property is produced by an authentication module.

The processing of a request by HTTP modules and an HTTP handler is governed by an HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in the root of each web application (IIS website) that identifies SPHttpApplication as the class from which an HTTP application object is created.

SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changes to the default applicationhost.config file. For detailed information about SharePoint and the integrated pipeline, see Microsoft SharePoint Foundation as an ASP.NET Application.

Figure 3 shows the relations among the classes that handle HTTP requests for a SharePoint front-end web server.

Figure 3. SharePoint customizations of the HTTP request pipeline

 
In addition to its use of the integrated pipeline, SharePoint uses some other features of IIS and technologies from ASP.NET. Among them are the following:
·         Active pages (aspx files): SharePoint pages are ASP.NET pages. SharePoint controls are referenced in the page markup with a registered "SharePoint" prefix. (For more information about the ASP.NET page parsing and compiling system, see Understanding ASP.NET Dynamic Compilation. Note that the standard page parser of ASP.NET compiles a page the first time it is requested unless the page is explicitly set not to be compiled. However, SharePoint pages that have been customized by a SharePoint website owner are stored in the SharePoint content database and are not compiled when they are accessed. SharePoint uses a custom virtual path provider, an internal class named SPVirtualPathProvider that is derived from VirtualPathProvider, to locate a requested page from either the file system or the content database and load it.
·         The master page/content page distinction: A SharePoint page is a merger of a master page and a content page. For more information, see ASP.NET Master Pages and Master Pages. (For some SharePoint Server pages, a third foundational page is involved in the merger, a page layout.)
·         Web Parts: Web Parts actually originated in an early version of SharePoint. The idea was adopted by ASP.NET. In most SharePoint Web Part development situations, we recommend that you use the ASP.NET version, but in some situations the original SharePoint incarnation is a better choice. The SharePoint UI for mobile devices also uses the ASP.NET concept of registered Web Part adapters. For more information about Web Parts in SharePoint, see Building Block: Web Parts and Building Block: Mobile Pages, Controls, and Adapters.
·         User controls (.ascx files): Many SharePoint web controls and Web Parts are built with ASP.NET user controls.
·         Web services (.asmx files): Some, but not all, SharePoint web services are implemented as ASP.NET ASMX services. For more information about ASP.NET web services in SharePoint, see ASP.NET Web Services.
·         Virtual directories: SharePoint maps several virtual directories in each IIS website to physical folders in the SharePoint root, which is the folder %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\. When you as a developer need to provision SharePoint web applications with images, resource files, and other important files, they are deployed to the appropriate physical folder on the front-end web servers. This process is handled automatically by the solution deployment mechanism of SharePoint. For example, user controls are deployed to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ControlTemplates (or a subfolder), which is mapped to the virtual directory _controltemplates.

ASP.NET development experience can be an advantage for a SharePoint developer, but the SharePoint development experience is different from the ASP.NET experience in many ways. Some examples of the differences are as follows:
·         SharePoint has its own installation and deployment model. For more information, see SharePoint Deployment Models later in this article.
·         SharePoint makes a distinction, unknown in ASP.NET, between application pages and site pages. For more information, see Pages, Parsing, and Safe Mode later in this article.
·         SharePoint has its own systems for modifying web.config files. For more information, see Working with Web.config Files.
·         The ASP.NET worker process model is modified in SharePoint. See Process and Execution Trust Model later in this article.

For more information about how SharePoint development differs from ASP.NET development, see ASP.NET vs. SharePoint: How Development Differs.

SharePoint Configuration Stack

SharePoint configuration settings exist at several levels. As in all ASP.NET applications that use the integrated pipeline, some fundamental settings are in the machine.config file, the global web.config file, and the applicationhost.config file, which is the IIS configuration store. SharePoint makes no changes in the default versions of the first two files. It does make some changes in the IIS configuration store. For more information about the changes, see Microsoft SharePoint Foundation as an ASP.NET Application.

Each IIS website and, therefore, each SharePoint web application, can have a web.config file in its root folder. This file is substantially customized by SharePoint whenever a SharePoint web application is created. For more information about the changes, see Microsoft SharePoint Foundation as an ASP.NET Application. SharePoint also takes advantage of the fact that web.config files can be applied to specific virtual or physical folders within a web application. For example, SharePoint puts a web.config file in the virtual directory _layouts\mobile (which is mapped to the physical directory %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Among other things, the web.config file registers a series of filters that control how a page is rendered, based on the capabilities of the mobile device that has requested the page.

All of the configuration files discussed so far must be identical across all front-end web servers. The SharePoint deployment model and its system for programmatically modifying web.config files helps ensure conformity to this rule. For more information, see Building Block: Solutions and Working with Web.config Files.

Farm-wide configuration settings are stored in the SharePoint configuration database on the computer that is running SQL Server in the farm. Configuration for specific types of websites is contained in various kinds of XML files, such as the Onet.xml file, and configuration for specific instances of websites is contained in the content database. In addition, several classes in the SharePoint object model have property bags that can be used to store custom configuration information for specific objects, such as objects that represent websites, Features, alerts, and files.

Finally, context information for specific HTTP requests is contained in the ASP.NET HttpContext object of the request. The SharePoint object model adds an SPContext class that does not inherit HttpContext; however, it gets many of its property values from the current HttpContext object and adds other properties to represent SharePoint-specific context information, such as the current website, list, and list item.

Data Model, Data Management, and Query System

The primary data structure in SharePoint Foundation is the list. Every list belongs to a list type. Similarly, every column in a list has a field type, and every list item has a content type. External data—that is, data from outside the SharePoint content databases—can also be shown and managed in SharePoint.

Lists

Data in SharePoint Foundation is primarily stored as tables much as it is in a relational database, except that the tables are called "lists" in SharePoint lingo. Indeed, the back-end storage of content data for a SharePoint Foundation web application is in one or more SQL Server databases. These are called content databases. (There is also a special configuration database on the computer that is running SQL Server that holds farm configuration data, and a special BDC database that supports Microsoft Business Connectivity Services (BCS). For more information about BCS, see External Lists and the Business Connectivity Service later in this article.) However, there are some differences between relational database tables and SharePoint Foundation lists:

·         Data is not queried by SQL. Instead, data is queried in server-side code either by LINQ or by queries formulated in CAML. For more information about server-side data querying, see Building Block: Queries and Views and the topic Querying from Server-side Code, along with its child topics. You can programmatically write data to the lists using either the server object model or the LINQ to SharePoint provider. For more information, see Managing Data with LINQ to SharePoint. From client-side code, data is queried by using either the client object model or WCF Data Services (formerly ADO.NET Data Services). For more information about client-side data querying, see Querying from Client-side Code.

BCS runtime and deployment components

Services and the Service Application Framework

Site Definitions and Web Templates

What makes it possible for ordinary business users to create their SharePoint websites without the intervention of IT professionals is the fact that types of websites in SharePoint are given detailed, stored definitions. Using the SharePoint UI, users can then instantiate a particular website from any of the defined types. There are actually two kinds of definitions of site types: site definition configurations and web templates. A site definition is stored on the file system of the front-end web servers, in a subfolder of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates, as a set of XML configuration files and possibly also page files and other supporting files. A web template is stored in a SharePoint Solution Package (.wsp file) in the content database, specifically in the Solution Gallery of a site collection. Either kind of type definition specifies such things as a default home page, various aspects of the default look-and-feel and layout of the site's pages, the types of lists available in sites of the specified type, and other configuration details of the site type.

SharePoint Security

The SharePoint security system protects deployments from both errant users and errant code.

User Security

SharePoint Foundation supports security for user access at the website, list, folder, and item levels. Security management is role-based at all levels. The authorization process assumes that the user has already been authenticated, which refers to the process by which the current user is identified. SharePoint Foundation does not implement its own system for authentication or identity management, but instead relies solely on external systems, whether Windows authentication or non-Windows authentication.

Authentication

SharePoint supports several forms of authentication. The default is Windows claims-based authentication. The claims-based identity model for SharePoint is built upon Windows Identity Foundation (WIF). Under this model, the user presents an identity to your SharePoint farm as a set of claims. One claim could be the user's name, another might be an email address. An external identity system is configured to give SharePoint all the information that it needs about the user with each request, along with cryptographic assurance that the identity data comes from a trusted source. Other types of supported authentication include Windows classic authentication and ASP.NET forms-based authentication. For more information about authentication and SharePoint, see the Getting Started with Security and Claims-Based Identity Model and SharePoint Claims-Based Identity nodes of the SharePoint Foundation SDK.

Authorization

Access to websites, lists, folders, and list items is controlled through a role-based membership system by which users, and groups of users, are assigned to roles that authorize their access to SharePoint objects. By default, permissions are inherited in the sense that a user who has certain permissions for an object, such as a list, will have the same permissions for its child objects, such as folders and list items. However, it is possible to break inheritance and assign to users and groups a different set of permissions to a child object. A role definition is a set of rights, such as rights to read, create, or delete. A role assignment associates a user or group with a role definition.
SharePoint supports two kinds of groups: domain groups and SharePoint groups. Domain groups remain outside SharePoint control; users cannot use SharePoint to define, browse, or modify domain group membership. SharePoint groups are scoped to the site-collection level, and they can be used only within the site collection. Domain groups can be used anywhere within the scope of the Active Directory service.
For more information, see Authorization, Users, and Groups.

Code Security

Much of the code security story for SharePoint was already described in earlier sections. In this section, different parts of the story are very briefly pulled together, and some gaps in the story are filled.
Every web application runs in an IIS application pool that processes HTTP requests. The pool itself runs in a user account known as the application pool identity. In a multiserver farm, this is usually a domain user. The application pool identity is the user identity for code that runs in an IIS worker process. However, access to various SharePoint objects is determined by the permissions of the user who has made the request that is being processed. The isolation of web applications into separate application pools ensures that if one of them crashes, the others are not affected.
The IIS worker process calls assemblies that may operate under their own additional restrictions. If the assembly is loaded out of the global assembly cache, it operates in full trust. However, if the assembly is loaded out of the web application's \bin directory, it is subject to the trust limitations that are defined by a CAS policy.
If the request is for a sandboxed solution, the SharePoint execution manager that runs in the IIS worker process spawns a sandboxed worker process. The latter process runs within a highly restrictive CAS policy, is limited to a subset of the SharePoint server object model, and can only access resources within the site collection to which the solution was deployed.
If the request is for a customized site page, all Web Parts on the page must be registered as safe controls and, by default, the page is not returned at all if it contains inline code blocks.

Server Object Model in SharePoint

The server object model in SharePoint is large, and only some of the truly critical classes can be described in this article. These classes can be usefully divided into three hierarchies: the Physical Objects Hierarchy, the Content Hierarchy, and the Services Hierarchy. Each is described briefly in the following subsections with links to more extended discussions. For a synoptic overview of the major classes from all three hierarchies, see Server and Site Architecture: Object Model Overview.

Physical Objects Hierarchy

The Physical Objects Hierarchy includes classes that represent physical entities, such as servers and farms—the two most important.
A SharePoint Foundation farm, and its configuration database, is represented by the SPFarm class. A server farm consists of one or more physical servers. These may include one or more front-end web servers, zero or more application servers, and a computer running SQL Server that may be hosted on a dedicated database server or on one of the other servers in the farm. (If it is a dedicated server, SharePoint is not actually installed on it, although it is still seen as a member of the farm in the farm management UI of the Central Administration application.) A farm may consist of just a single server. If the farm has multiple front-end web servers, they are usually load-balanced. You can use any hardware or software load-balancing solution, including the built-in NLB (Network Load Balancing) in Windows Server 2008. SharePoint does not itself supply the load-balancing.
SPFarm inherits from SPPersistedObject, which means that the object (there is only one) that instantiates the class persists in the configuration database. The three most important child classes of SPFarm are SPServer, SPService, and SPSolution.
A physical server in a SharePoint Foundation farm is represented by the SPServer class. In addition to many inherited members, it has an Address property that holds the IP address of the server and a Role property that identifies the server's role in the farm. It also has a ServerInstances property that holds references to all the instances of Windows services and web services that are running on the server. SPServer also inherits from SPPersistedObject, so server objects are persisted in the configuration database.
For more information about the Physical Objects Hierarchy in the object model, see Physical Objects Hierarchy of Microsoft SharePoint Foundation and Background: Physical Objects in Microsoft SharePoint Foundation.

Content Hierarchy

The Content Hierarchy includes classes that represent publishable items of data, such as list items. There are also classes that represent nested containers of data, such as lists, content databases, websites, site collections, and web applications.

High Level Object Model

Beneath the farm, the broadest content container is the web application, which is represented by the SPWebApplication class. An SPWebApplication object represents a content-publishing web application in SharePoint Foundation. It contains one or more content databases, which hold the data of one or more site collections. Each such web application is served by at least one (and usually only one) IIS website and typically has its own application pool in IIS. Also, each web application has its own security and authentication settings. The SharePoint Foundation object model provides some hooks into the web application's other life as an IIS object through the IisSettings and ApplicationPool properties. For more information about the relation between SharePoint web applications and IIS, see SharePoint as an ASP.NET-IIS Application earlier in this article.
The SPWebApplication class has a ContentDatabases property that holds all its child content database objects.
Every web application contains one or more content databases. Each of these is represented by the SPContentDatabase class. A content database is a SQL Server database that contains all the data (lists, list items, blog posts and comments, wiki pages, and documents in document libraries) and the customized page files that constitute the site collections that belong to the database. Objects that represent each child site collection are in the Sites property.
Both SPWebApplication and SPContentDatabase inherit from SPPersistedObject, so these objects persist in the farm's configuration database.
For more detailed discussions of web applications, content databases, and their classes, see Content Hierarchy of SharePoint Foundation and Background: Content Entities in Microsoft SharePoint Foundation.

Middle Level Object Model

At the middle level of the content hierarchy are site collections and their subsites. An SPWeb object represents a single website. An SPSite object represents a collection of websites within a SharePoint web application that are grouped together for mainly administrative reasons. (The SPSite class is not a collection in the sense of a class that implements ICollection.)
The SPSite class has a RootWeb property that holds its child top-level website. (Top-level websites were called "root webs" in the first version of SharePoint Foundation, Microsoft SharePoint Team Services.) In turn, the SPWeb object that represents the top-level website has a Webs property that holds all its immediate child subsites (but not the subsites of those subsites). (The AllWebs property returns all the descendent sites and the top-level website.)
Among the SharePoint elements that can be scoped to the site collection level are master pages, Web Parts, themes, lists, content types, and Features. A site collection can also be a unit of backup and restoration. It is also the level at which groups of users are created and assigned default permissions. Site collections are the largest possible scope for a search in SharePoint Foundation, although broader search scopes are possible in SharePoint Server 2010.
The content of a site collection is always included within a single content database.
Websites can be children of other websites, and all websites belong to a site collection. The SPWeb class has dozens of properties and methods for programmatic handling of every aspect of the website, including users, lists, fields, content types, Features, alerts, and much more.
For much more information about site collections and websites, see Building Block: Websites and Site Collections, Content Hierarchy of SharePoint Foundation, and Background: Content Entities in Microsoft SharePoint Foundation.

Client Object Models in SharePoint

There are three client object models in SharePoint Foundation: one each for Microsoft Silverlight applications, Microsoft .NET Framework applications, and JavaScript. They are almost the same in the APIs that they expose. The *.js files that contain the JavaScript client object model, like all *.js files, are downloaded automatically to the user's computer when a page that references the object model is accessed. (The standard built-in master page for SharePoint references these files.)
The assemblies that contain the Silverlight object model can be downloaded in the .xap file, but another alternative is to download at run time the file %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\ClientBin\Microsoft.SharePoint.Client.xap, which encases the Microsoft Silverlight assemblies.
The .NET Framework object model can be called only if the assemblies that contain the object model have been installed to the client computer. You must use the official redistribution package, SharePoint Foundation 2010 Client Object Model Redistributable.
These object models provide a subset of the classes in the server-side microsoft.sharepoint.dll assembly, although many of the class names have been slightly changed (usually by dropping the "SP" at the beginning of the class name). The client object models are implemented as a WCF service (.../_vti_bin/client.svc), but they use web bindings to implement efficient request batching. Commands are serialized into XML and sent to the server in a single HTTP request. For every command, a corresponding server object model call is made, and the server returns a response to the client in compacted JavaScript Object Notation (JSON) format, which the proxy parses. The client APIs provide a familiar, object-oriented interface to the WCF service, so developers are shielded from the details of the service. In particular, the client-side runtime handles all communication between the clients and server.
Microsoft.SharePoint.Client is the core namespace used for the Microsoft .NET Framework managed and Silverlight object models, and SP is the core namespace for the JavaScript object model. Client objects inherit from the ClientObject class (JavaScript: ClientObject).
SharePoint code on a client begins by retrieving a client context object that represents the current request context, and through this context, you can obtain access to client objects at the site-collection level or lower in the SharePoint Foundation hierarchy. Client objects inherit from the ClientObject class (JavaScript: ClientObject), and you can use them to retrieve properties for a specific SharePoint object, to retrieve child objects and their properties, or to retrieve child items from a collection.
After a client object is obtained, a query is defined and loaded. This is followed by a call of the ExecuteQuery method or the ExecuteQueryAsync method (JavaScript: executeQueryAsync) to send the query to the server. The query commands are packaged as XML and processed on the server by the WCF service, Client.svc, which runs the batched commands by calls to the server-side object model. Returned data is sent back to the client by the service as JSON data.
Figure 11 shows the major components and events of the client's interaction with the server when the client object models are used.


Figure 11. Client and server interaction with the client object models

FOR MORE INFORMATION YOU CAN REFER TO MICROSOFT'S TECHNET  SITE.