Share Point 2010 Architecture 01

SharePoint Server Architecture

1 | P a g eAbad Net | P.O. Box100898 | Riyadh 11645 | Saudi Arabia | www.Abadnet.com.saT: +96614918199 | M: +966545156659 | F: +96614918199

Published: February 2011

Summary: Learn about the architectures of Microsoft SharePoint Foundation 2010 and MicrosoftSharePoint Server 2010, including the platform stack, the Microsoft ASP.NET-IIS integrated requestpipeline, the server and client object models, and the execution process system for sandboxedsolutions and farm solutions.

Applies to: Microsoft SharePoint Foundation 2010 | Microsoft SharePoint Server 2010

Provided by: Ricky Kirkham, Microsoft Corporation

Contents

Overview of SharePoint Foundation and SharePoint Server Architectures What Is SharePoint? SharePoint Development Platform Stack SharePoint as an ASP.NET-IIS Application SharePoint Configuration Stack SharePoint Deployment Models Process and Execution Trust Model Pages, Parsing, and Safe Mode Data Model, Data Management, and Query System Services and the Service Application Framework Site Definitions and Web Templates SharePoint Security Server Object Model in SharePoint Client Object Models in SharePoint Workflows in SharePoint Conclusion



Overview of SharePoint Foundation andSharePoint Server ArchitecturesThis article provides an overview of the architectures of Microsoft SharePoint Foundation and SharePointServer, including the platform stack, the Microsoft ASP.NET-IIS integrated request pipeline, the server andclient object models, the execution process system for sandboxed solutions and farm solutions, and more.

What Is SharePoint?The use of the plural term "architectures" in the title is not a mistake. SharePoint has many architectures,partly because "architecture" has many meanings in the context of software development, but alsobecause SharePoint itself is many things—things that in the past would have been distinct applications orplatforms.

The following is a selection of some of the most important things that SharePoint is:

A portal server with delegated administration. SharePoint enables information workers (IW) whohave no knowledge of website design or website administration to create, almost instantly,attractive and functioning websites. This relieves information technology (IT) departments from theburden of creating and administering the sites, and it empowers the IWs to create their own sitesfor teams, blogs, wikis, and other purposes.

A groupware application kit. SharePoint provides a platform on which IWs can createcollaboration solutions that include document libraries and workspaces, workflows, wikis, blogs,and team-oriented lists, such as Events, Announcements, and Tasks. Microsoft SharePointWorkspace (formerly Microsoft Office Groove 2007) provides an offline experience for thesecollaboration solutions.

A workflow host. Business processes can be systematized and modeled with workflows that aretriggered by associated events; for example, the addition of a document to a document library.

A content management application. SharePoint Server Enterprise Content Management (ECM)features include document management, records management, and web content management.

A Business Intelligence (BI) application kit. The Microsoft Business Connectivity Services (BCS)features of SharePoint enable data from non-SharePoint sources, such as a SAP installation orOracle database, to be accessed (read/write) just as if it were an ordinary SharePoint list.

The operating system of an intranet. SharePoint can provide for an intranet many of thefunctions that an operating system provides for a computer, including storing and copying files,hosting services, starting applications, and securing data. (This is not to imply that SharePoint canonly be used on an intranet. SharePoint can also host extranet and Internet-facing solutions.)

A host for services. SharePoint deployments make data available through a client object model,the REST-based Windows Communication Foundation (WCF) Data Services (formerly ADO.NET



Data Services), and many out-of-the-box ASMX web services. In addition, the SharePoint ServiceApplication Framework provides a platform that enables developers to build scalable middle-tierservices that can provide data or processing resources to other SharePoint features.

A data store. SharePoint stores data as multicolumn lists in a Microsoft SQL Server database. Youcan query the data by using LINQ and also using Collaborative Application Markup Language(CAML). The data can be mirrored, backed up, restored, and, depending on the edition of SQLServer being used, you may be able to take snapshots of the data store.

A data and processing layer for multiple user interfaces (UIs). Besides its native UI of webpages(including special versions for mobile devices), which can contain ECMAScript (JavaScript, JScript),SharePoint also supports access from Microsoft Silverlight applications and the MicrosoftSharePoint Workspace client application. With the SharePoint client object model, you can accessSharePoint using Windows Presentation Foundation (WPF), Windows Forms, or any other managedcode application.

This article discusses the architectures of SharePoint 2010 (with many links to more detailed information)in several senses, including the platform stack on which SharePoint runs, the configuration layers, theclient and server object models, the services framework, the HTTP request pipeline, and the workerprocess system.

SharePoint Development Platform StackFigure 1 shows how SharePoint Foundation is built on Microsoft .NET Framework 3.5, ASP.NET, andInternet Information Services (IIS). SharePoint is also built on SQL Server, but you can install SQL Server ona dedicated server that does not have SharePoint installed, which is typical in a production farm. All ofthese platforms must be running on a 64-bit installation of Windows Server 2008 on the servercomputers. SharePoint Server, in turn, is built on SharePoint Foundation. There are two editions ofSharePoint 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 aSharePoint point of view, they are effectively a single web-hosting application. For more informationabout 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 thatcontains them, or on which they depend. The two thin, downward-pointing arrows indicate some specificdependencies that are shown only as examples. Many other specific dependencies are not shown in thefigure. The thick, left-pointing arrows indicate that the entity on the right side accesses the entity to whichthe arrow points. For example, BCS accesses external databases.



SharePoint as an ASP.NET-IIS ApplicationAs the High Level Object Model section later in this article shows in more detail, the highest level oforganization in a SharePoint deployment, other than the farm itself, is the web application. Awebapplication in SharePoint terminology is closely related to what is called a website in IIS terminology. AnIIS website monitors for incoming requests through a particular port, and it checks for a particular hostheader or IP address, or both. Every SharePoint Foundation web application is hosted in an IIS websitethat has the same name as the web application. It can be helpful, especially when you are trying to see therelation between SharePoint and IIS from a high and broad perspective, to think of the SharePoint webapplication 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 theyare represented by different classes in the SharePoint object model: theSPWebApplication class andthe SPIisWebSite class). For one thing, although there is usually a one-to-one relation between SharePointweb applications and IIS websites, this is not always the case. It is possible to extend a SharePoint webapplication 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.

Figure 2. IIS Manager 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 serverreceives a request from a client for a page or other resource in a SharePoint site, the request is passedthrough 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 therequest. 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 oranother HTTP handler object (or to a handler factory class that creates HTTP handler objects) dependingon the resource requested and the HTTP verb in the request. The assignment is determined by a stack ofconfiguration files named applicationhost.config, machine.config, and web.config.

The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one ormore event handlers or define new events that other modules can handle. An HTTP module can registerfor one or more events in the life cycle of the request. They are often used to preprocess requests orpostprocess the response. The result of a module’s preprocessing is stored in the HttpContext object. Forexample, 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 byan HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in theroot of each web application (IIS website) that identifies SPHttpApplication as the class from which anHTTP application object is created.

SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changesto the default applicationhost.config file. For detailed information about SharePoint and the integratedpipeline, 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 webserver.

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 andtechnologies from ASP.NET. Among them are the following:

Active pages (aspx files): SharePoint pages are ASP.NET pages. SharePoint controls arereferenced in the page markup with a registered "SharePoint" prefix. (For more information aboutthe ASP.NET page parsing and compiling system, see Understanding ASP.NET DynamicCompilation. Note that the standard page parser of ASP.NET compiles a page the first time it isrequested unless the page is explicitly set not to be compiled. However, SharePoint pages thathave been customized by a SharePoint website owner are stored in the SharePoint contentdatabase and are not compiled when they are accessed. SharePoint uses a custom virtual pathprovider, 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 anda content page. For more information, see ASP.NET Master Pages and Master Pages. (For someSharePoint 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 adoptedby ASP.NET. In most SharePoint Web Part development situations, we recommend that you use theASP.NET version, but in some situations the original SharePoint incarnation is a better choice. TheSharePoint 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 BuildingBlock: Mobile Pages, Controls, and Adapters.

User controls (.ascx files): Many SharePoint web controls and Web Parts are built with ASP.NETuser controls.

Web services (.asmx files): Some, but not all, SharePoint web services are implemented asASP.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 physicalfolders in the SharePoint root, which is the folder %ProgramFiles%\Common Files\MicrosoftShared\web server extensions\14\. When you as a developer need to provision SharePoint webapplications with images, resource files, and other important files, they are deployed to theappropriate physical folder on the front-end web servers. This process is handled automatically bythe solution deployment mechanism of SharePoint. For example, user controls are deployed to%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ControlTemplates (ora subfolder), which is mapped to the virtual directory _controltemplates.

ASP.NET development experience can be an advantage for a SharePoint developer, but the SharePointdevelopment experience is different from the ASP.NET experience in many ways. Some examples of thedifferences are as follows:

SharePoint has its own installation and deployment model. For more information, see SharePointDeployment 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 Workingwith Web.config Files.

The ASP.NET worker process model is modified in SharePoint. See Process and Execution TrustModel 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 StackSharePoint configuration settings exist at several levels. As in all ASP.NET applications that use theintegrated 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 inthe default versions of the first two files. It does make some changes in the IIS configuration store. Formore 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 rootfolder. This file is substantially customized by SharePoint whenever a SharePoint web application iscreated. For more information about the changes, see Microsoft SharePoint Foundation as an ASP.NETApplication. SharePoint also takes advantage of the fact that web.config files can be applied to specificvirtual or physical folders within a web application. For example, SharePoint puts a web.config file in thevirtual directory _layouts\mobile (which is mapped to the physical directory %ProgramFiles%\CommonFiles\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Among other things, theweb.config file registers a series of filters that control how a page is rendered, based on the capabilities ofthe mobile device that has requested the page.

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

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

Finally, context information for specific HTTP requests is contained in the ASP.NET HttpContext object ofthe 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 otherproperties to represent SharePoint-specific context information, such as the current website, list, and listitem.



SharePoint Deployment ModelsSharePoint solutions are generally not installed by using MSI or ClickOnce technology. (Some exceptionsare noted later.) SharePoint has its own installation system. Instead of MSI files, the solutions arepackaged in SharePoint solution package files. These are CAB files that have a special extension: .wsp.SharePoint solution package files can contain several kinds of elements, including assemblies, usercontrols, custom ASP.NET pages, XML configuration files, resource files, images, list definitions, Web Parts,Features, and others. JavaScript files and Silverlight .xap files can also be deployed to the servers by usingSharePoint Solution Packages.

There are two kinds of solutions in SharePoint: farm solutions and sandboxed solutions. The differencesbetween them are discussed in this section and in Worker Processes, Farm Solutions, and SandboxedSolutions later in this article.

Note :The terms "solution" and "feature" are familiar in software development. The first thing to note about theSharePoint deployment model is that these terms are names of formal components of SharePoint that are defined inthis section. By convention, "Feature" is capitalized when it refers to the SharePoint component of that name.Throughout this article, I will follow the additional convention of italicizing "farm solution," "sandboxed solution,"and "solution" when the SharePoint component is being referenced. When either "solution" or "feature" is lowercaseand not italic, it is being used in its ordinary sense.

Installation of a SharePoint solution package is a multi-step process:

1. Adding: A solution package file is added to one of two stores.

Farm solutions are deployed by farm administrators to the farm's solution store, which is inthe farm's configuration database. This is done by using either the SharePointManagement Shell or the object model.

Sandboxed solutions are deployed to a specific site collection's Solution Gallery by a sitecollection administrator. The gallery is a special SharePoint list, so it is in the contentdatabase. Solution deployment to the gallery is done through the Site Actions UI of thesite collection or by using SharePoint Management Shell. For information about thedifference between site collections and websites, see Middle Level Object Model later inthis article.

Thus, SharePoint Solution Package files are never installed to the file system of any server,although elements of a farm solution may be installed to the file system when the solution isdeployed.

2. Deploying: The solution package is unpacked and its elements are deployed to their appropriateplaces.

For a farm solution, this step also requires a farm administrator and can be done by usingeither Central Administration or SharePoint Management Shell, or the object model. Someexamples of how elements are deployed: user control files (.ascx) are copied to%ProgramFiles%\Common Files\Microsoft Shared\web serverextensions\14\TEMPLATE\ControlTemplates and assemblies are deployed to the global



assembly cache or to a web application's \bin folder. If there are SharePoint Features(defined later) in the farm solution, they are in this step copied to a subfolder of%ProgramFiles%\Common Files\Microsoft Shared\web serverextensions\14\TEMPLATE\FEATURES.

For sandboxed solutions, the deployment step is taken by a site collection administrator.There are limits on what kinds of elements can be in sandboxed solutions and where theycan be deployed. For example, nothing can be deployed to the file system of the serversfrom a sandboxed solution. Features in sandboxed solutions are deployed to the contentdatabase.

It is also in this second step that any Features in the solution are installed in the FeatureGallery of the farm, web application, site collection, or website, depending on the scope of theFeature. (For more information about the relations of farm, web applications, site collections, andwebsites to one another, see Content Hierarchy later in this article.)

Within a SharePoint solution package, there can be an additional level of encapsulation becausea solution can have one or more SharePoint Features. A Feature can be installed at the scope of the farm,the web application, the site collection, or the website. After it is installed, a Feature must be activated byowners of any website within the scope; so Activating becomes a third step of installation for Features.Features can contain content types, controls, custom actions, custom fields, files, workflows, list instances,list templates, event receivers, and document converters; although some of these cannot be included incertain scopes. (Features that are deployed in sandboxed solutions can be scoped only to a site collectionor website. For site collection-scoped features in sandboxed solutions, the second and third steps arecombined. The Features are activated when the solution is deployed.)

Note : SharePoint is not consistent in its terminology with regard to installation. Theterms adding, deploying, and activating are the most frequently used to refer to the three steps ofinstallation; but depending on what tool is used to complete a step and whether the solution isfarm or sandboxed, you will see a variety of terminology. The first step may becalled adding, installing, or uploading. The second step may becalled deploying, activating or installing. There is a similar inconsistency in the terms forreversing these steps; but most commonly, reversing the second step is called retracting andreversing the first step is called removing. The third step, which applies only to Features, isalways called activating, and its reversal is always calleddeactivating.

Some SharePoint solutions target one of the client object models, either exclusively or in addition totargeting the server object model: the JavaScript, Silverlight, and Microsoft .NET Framework client objectmodels. (For more information about the client object models, see Client Object Models inSharePoint later in this article.) There is nothing unusual about the installation of the client portion of suchsolutions.

The script files that define the JavaScript object model are downloaded to a client computer whena page that references them is opened.



Similarly, a Silverlight .xap executable is downloaded to the client computer when a page that ishosting it is accessed. The SharePoint assemblies that contain the Silverlight client object model areencased in the .xap file. Those assembliesare Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Cl

ient.Silverlight.Runtime.dll. (It is also possible to cache these assemblies on the front-end web server. For details, see RIA Technologies: Benefits, Tradeoffs, and Considerations.)

Stand-alone .NET Framework applications (such as a WPF application) that target the SharePointclient object model are installed just as any other client applications: using MSI files or ClickOnce.The assemblies that contain this client objectmodel, Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runt

ime.dll, must be distributed as part of the solution. The redistributable is located at SharePointFoundation 2010 Client Object Model Redistributable.

For more information about the processing of client-side logic in SharePoint, see Client ApplicationModels in SharePoint 2010.

For more information about the deployment system, see Building Block: Features, Building Block:Solutions, and Packaging and Deployment.

Process and Execution Trust ModelIn the simplest scenarios, the process model of SharePoint is the same as any other ASP.NET application;but in SharePoint, the distinction between farm solutions and sandboxed solutionsentails some morecomplex scenarios.

Worker Processes, Farm Solutions, and Sandboxed Solutions

When an HTTP request is received by a front-end web server, a special driver, HTTP.SYS, detects therequest and routes it to the application pool that is handling requests for the targeted IIS website, andthus, the targeted SharePoint web application. Every application pool has an IIS worker process(w3wp.exe) in which the request pipeline for each request is executed. (For more information about the IIS7.0 worker processes and application pools, see Introduction to IIS 7 Architecture.) On a SharePoint server,the IIS worker process runs in the application pool account, which gives the process read and writepermissions to SharePoint resources. On a multiserver farm, the application pool account is a domain userthat is not a machine administrator on any server in the farm, but is a member of the WSS_WPG,WSS_ADMIN_WPG, and IIS_USERS groups on each server. (This should be a different account from thefarm administration account. The latter is also not a local machine administrator on any farm server. Thefarm account is a member of all the same groups as the application pool account and also theWSS_RESTRICTED_WPG_V4 and Performance Monitor User groups. An exception is made for theapplication pool of the Central Administration web application: its application pool account isthe farmaccount. Also, the SharePoint 2010 Timer Service executes in the context of the farm account.) For moreinformation about the accounts needed in a SharePoint farm, see Plan for administrative and serviceaccounts (Office SharePoint Server).

Figure 4 shows how an IIS worker process that is running on a front-end web server processes an HTTPrequest.



Figure 4. Request processing model for full-trust farm solution

However, unlike a standard ASP.NET application, SharePoint makes a distinction between sandboxedsolutions and farm solutions. Farm solutions run in the IIS worker process just like any ASP.NETapplication. Sandboxed solutions run in a specially restricted execution environment. This is necessarybecause sandboxed solutions are installed on (and scoped to) SharePoint site collections without theintervention of the IT professionals that are managing the SharePoint farm. To prevent rogue or poorlyperforming code from slowing or crashing the application pool, SharePoint imposes restrictions on whatthe code in a sandboxed solution can do. As a crucial part of the implementation of this system, sandboxedsolutions must run in a special sandboxed worker process (SPUCWorkerProcess.exe).

When a request attempts to access a sandboxed solution, a SharePoint execution manager that runs in theIIS worker process finds a sandbox worker process (or starts one, if none is running) in which the code ofthe sandboxed solution will run. In principal, this sandboxed worker process can be started on any server inthe farm that is running the SharePoint 2010 User Code Host service (SPUCHostService.exe). (In the UI ofthe Central Administration application, this is known as the Microsoft SharePoint Foundation SandboxedCode Service.)

The server that is running the SharePoint 2010 User Code Host service can be, but does not have to be,the front-end web server on which the IIS worker process is running. Which server is used is configurablein the Central Administration application: Administrators can choose to have each sandboxed process runin "local mode," which means that each request for a sandboxed solution is processed on the same front-end web server on which the IIS worker process is running; or they can have the execution manager starteach sandboxed process in "remote mode," also known as "affinity mode." In affinity mode, the executionmanager looks for a server that is running the SharePoint 2010 User Code Host service and which alreadyhas created an application domain inside its SPUCWorkerProcess.exe process for the very same sandboxedsolution. (This would be the case if that same sandboxed solution was requested before, possibly byanother user on another site collection.) If there is a matching application domain, the request is sent tothat same application domain for handling. If none of the servers that are running the SharePoint 2010User Code Host service already has an application domain for the sandboxed solution, the executionmanager assigns the request to the least busy of those servers. The server then creates the neededapplication domain and processes the request for the sandboxed solution. The application domain staysalive after the request is processed and is reused if there is another request for the same sandboxedsolution.

By default, all sandboxed solutions that are handled by a given server run in the same sandbox workerprocess, but this is configurable through the object model. Each sandboxed solution gets its ownapplication domain within the common process, and this, too, is configurable through the object model.The SharePoint 2010 User Code Host service runs in an account that has the same rights as a typical



application pool account. It should be a member of the WSS_WPG, WSS_ADMIN_WPG, and IIS_USERSgroups on the server on which the service instance is running.

Code Execution and Access Constraints on Sandboxed Solutions

All code that runs in this sandbox worker process is subject to execution and access constraints. There aretwo systems of constraints: One applies to all and only calls to any assembly, exceptMicrosoft.SharePoint.dll, whether it is a SharePoint assembly or not. The other applies to all and only callsmade to the parts of the SharePoint Foundation object model that are in the assemblyMicrosoft.SharePoint.dll. The calls that this second system applies to are not just calls in customSharePoint solutions. Calls to Microsoft.SharePoint.dll from other SharePoint assemblies (that havethemselves been called by custom code) such as Microsoft.SharePoint.Linq.dll are also subject to thisconstraint.

The first system of is imposed by two mechanisms:

1. A highly restrictive code access security (CAS) policy significantly limits what code in thesandboxed worker process can do. This policy is defined in the wss_usercode.config file in%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG, and it isreferenced in the web.config file in %ProgramFiles%\Common Files\Microsoft Shared\web serverextensions\14\UserCode. Among the restrictions imposed by the CAS policy are the following:

Code in the sandbox cannot call unmanaged code.

Code in the sandbox cannot call the Microsoft .NET Framework 3.5 reflection APIs.

Code in the sandbox can call only the .NET Framework 3.5 assemblies that havethe AllowPartiallyTrustedCallersAttribute attribute. This blocks access to about two-thirdsof all the .NET Framework 3.5 APIs, including System.Printing, for example.

Note : The CAS policy makes an exception for strong-named Microsoft Office assemblies.These are granted full trust.

2. Secondly, the sandboxed worker process has a low-privileged security token.

The token denies the process the right to read from or write to the file system.

The token denies the process the right to call to the network. Therefore, only resourcesavailable on the server that is running the sandboxed worker process may be accessed. Anexternal database, for example, cannot be accessed.

The token denies the process the right to write to the registry.

The token denies the right to call to any assembly that is not in the general assemblycache, even if it has the AllowPartiallyTrustedCallersAttribute attribute and wouldotherwise be eligible to be called from the sandboxed worker process.



As noted, a second system of constraints imposes restrictions on what APIs in Microsoft.SharePoint.dll canbe directly called by code in the sandboxed worker process, and a call to any forbidden API in the objectmodel results in an exception (which is caught and reported to the user as an error). The implementationof these restrictions is accomplished by a pair of specially restricted versions ofthe Microsoft.SharePoint.dll assembly, sometimes called shim assemblies, that are located in%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies. One ofthe two assemblies is loaded by the sandboxed worker process. The other assembly is loaded in a specialproxy process (SPUCWorkerProcessProxy.exe) that runs in full trust and that is also managed by theSharePoint 2010 User Code Host. The standard Microsoft.SharePoint.dll assembly is also loadedin this proxy process.

The main job of the two shim assemblies is to filter out forbidden SharePoint classes and members. Whenthe sandboxed solution calls an approved API, the first shim assembly passes it to the second in the proxyprocess, which in turn passes it to the standard Microsoft.SharePoint.dll. Any returned results arepassed back to the original calling code. This cross-process interaction is possible through .NETFramework remoting. A sandboxed worker process and a full-trust proxy process are always startedtogether and paired with one another. If either process crashes, the other is also stopped.

The shim assemblies also have a secondary job. Some SharePoint APIs are available to sandboxedsolutions, but only with special restrictions on the parameters that are passed to them. It is the shimassemblies that enforce these input restrictions and ensure that an exception is thrown when there is aviolation. The only case of this in SharePoint Foundation 2010 are the SPSiteand SPSite constructors.These constructors can be called in sandboxed solutions, but only URLs or GUIDs that refer to the sitecollection in which the sandboxed solution is running can be passed to them.

Note : Because the second shim assembly and the standard Microsoft.SharePoint.dll run in afull-trust process, permitted APIs in the SharePoint object model can do some things that wouldotherwise be forbidden in a sandboxed solution. For example, the GetLocalizedString methodcan read .resx files even though sandboxed solutions cannot generally read from the disk.(However, a file cannot be deployed to disk in sandboxed solution, so the .resx file would haveto be previously installed as a farm solution.)

The following are some of the restrictions on the SharePoint object model that can be accessed:

The SPWebApplication class cannot be accessed. Among other things, this means thata sandboxed solution cannot access anything outside its hosting site collection.

Almost all classes in the Microsoft.SharePoint.WebControls namespace cannot be accessed, whichmeans that you are mainly restricted to ASP.NET controls in sandboxed solutions.

For a complete list of APIs in Microsoft.SharePoint.dll that are available to sandboxed solutions,see Microsoft.SharePoint.dll APIs That Are Available from Sandboxed Solutions.

Important : The deployment stage of a sandboxed solution itself runs in a sandboxed workerprocess and is subject to the same execution constraints. For example, you cannot deploy a fileto the disk when you are deploying a sandboxed solution. This is the main reason why a user



control (ASCX file) cannot be in a sandboxed solution. See SharePoint Deployment Models forinformation about the deployment stage.

Resource Usage Restrictions on Sandboxed Solutions

Sandboxed solutions are also subject to three kinds of resource usage restrictions that can be organizedbased on the kind of entity to which the restriction applies and the kind of entity on which the penalty forexceeding the restriction is imposed.

Per Request with the Request Penalized: There is a hard limit to how long a sandboxedsolution can take to finish. By default, this is 30 seconds. If a sandboxed solution exceeds the limit,the request (but not the sandboxed worker process) is terminated. (This limit is configurable, butonly through custom code against the object model. The relevant parts of the object model cannotbe accessed by sandboxed solutions, so no sandboxed solution can change the limit.)

Per Request with the Process Penalized: A set of 15 resource limits apply to requests. If a requestexceeds one of them, the process (and all the sandboxed solutions that are running in it) isterminated.

Per Day/Per Site Collection with the Site Collection Penalized: Each site collection is subject toa configurable maximum of daily resource points. These points accumulate based on an algorithmthat takes into account the use of resources in the 15 resource categories by the sandboxedsolutions that are installed in the site collection. When a site collection exceeds its maximumallowed points, all sandboxed solutions in the site collection are terminated and no more can runfor the rest of the day.

SharePoint provides a solution validator framework that can be used to developcustom solution validators, such as a validator that verifies whether a solution is signed with a specificcertificate. The validators in a site collection run when a sandboxed solution is activated (that is, deployed,in the terminology used earlier in this article). The activation of any invalid solution is blocked. If avalidator is updated or a new validator is added, each activated solution is rechecked by the validators thenext time it is executed. Invalid solutions are deactivated. For an introduction to custom validators,see Developing, Deploying, and Monitoring Sandboxed Solutions in SharePoint 2010.

For more information about the sandbox restrictions, see Sandboxed Solutions in SharePoint 2010 and itschild topics and the Microsoft patterns and practices guidelines for Sandboxed Solutions.

Figure 5 shows how an HTTP request is handled when it accesses a sandboxed solution.



Figure 5. Request processing model for sandboxed solutions

The SPUCHostService.exe, SPUCWorkerProcess.exe, and SPUCWorkerProcessProxy.exe files are located at%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode.

Note : A solution that is designed to run in the sandbox can be deployed by a farm administratoras a farm solution. It might perform better if it is, because it would run in the IIS worker processinstead of the sandboxed worker process.

Not all SharePoint execution is in an IIS worker process, a sandboxed worker process, or the proxyprocess. The following are some examples:

The SharePoint Timer Service (owstimer.exe) runs on all servers and is used to executeprescheduled timer jobs. It runs under the farm account.

The SharePoint Tracing Service (wsstracing.exe) runs under the local service account.



The SharePoint Administration Service (wssadmin.exe) runs under the local system account.

Within the category of farm solutions, a further distinction can be made when the requested resource is an.aspx page. If the requested page is what SharePoint calls an application page, the returned page is passedto the regular ASP.NET page parser; but if the requested page is what SharePoint calls a site page, thereturned page is routed through a special safe mode parser. The distinction between the two kinds ofparsing is best understood in light of the distinction between the two kinds of pages. For moreinformation about both subjects, see Pages, Parsing, and Safe Mode later in this article. (Application pagescannot be included in sandboxed solutions. All pages installed as part of a sandboxed solution use safemode parsing.)

Assembly Deployment, Execution, and Persistence

Farm solutions divide into two types depending on where their assemblies are deployed and the trustlevel of the assemblies' execution:

GAC/Full Trust: The assemblies are deployed to the global assembly cache (GAC) of every front-end web server in the farm and run with full trust. They are callable from any SharePoint webapplication on the farm.

Bin/CAS: The assemblies are deployed to the \bin folder (on every front-end web server) of aspecific SharePoint web application and their trust level is determined by a CAS policy referencedin the web application's web.config file. They have to be separately deployed to every SharePointweb application that needs to call them.

Noncompiled files for both kinds of farm solutions—including, for example, images, user controls, andstring resources—are deployed to subfolders of %ProgramFiles%\Common Files\Microsoft Shared\webserver extensions\14\.

Sandboxed solutions are deployed inside a SharePoint solution package (.wsp file) to the SolutionGallery of a specific site collection. Thus, they are deployed and persisted in the site collection's contentdatabase. As noted earlier, they do not run in full trust: Instead, they run within a highly restricted CASpolicy and can only call a restricted subset of the SharePoint object model. A sandboxed solution can beaccessed only in site collections to which it is deployed.

When a sandboxed solution is accessed for the first time, such as when a user navigates to a page thatcontains a Web Part from a sandboxed solution, any assemblies in the solution are unpacked fromthe solution package and copied to the file system of the server that is handling the sandbox request. Thedefault location isC:\ProgramData\Microsoft\SharePoint\UCCache, but this is configurable oneach server that is running the User Code Host Service. (Recall that the server that handles the sandboxrequest is not necessarily the front-end web server that is handling the initial HTTP request. The UserCode Host Service can be run on back-end application servers in the farm instead.) Because thesandboxed worker process cannot copy anything to the file system, the copying is done by the User CodeHost Service.

The assemblies do not stay in the file cache perpetually. When the user session that accessed theassemblies finishes, the assemblies stay in the cache for only a short time, and they may be reloaded fromthere if another user session accesses them. Eventually, if they are not accessed, they are removed



according to a proprietary algorithm that takes into account how busy the server is and how much timehas gone by since the assemblies were last accessed. If the sandboxed solution is used after that time, theassemblies are unpacked again and copied to the UCCache.

Note: Administrators, developers, and third-party code should not add, remove, or load anythingfrom the UCCache. It should be accessed only by the SharePoint infrastructure.

Hybrid Solution Techniques

The SharePoint solutions architecture includes a technique by which a sandboxed solution can call customoperations that run in full trust. The technique requires that a farm solution be developed that includesone or more classes that derive from SPProxyOperation. Each of these defines an operation that will run infull trust and can be called from sandboxed solutions by usingthe ExecuteRegisteredProxyOperation method. Specifically, these full-trust proxy operations execute inthe same proxy process (SPUCWorkerProcessProxy.exe) that was described earlier in Worker Processes,Farm Solutions, and Sandboxed Solutions. The proxy operations can return data to the sandboxed solution.

Like all farm solutions, the assembly with the proxy operations can be deployed only if it is from a trustedsource.

Figure 6 shows how a request that accesses a sandboxed solution is processed when the sandboxedsolution makes a call to a full-trust proxy.



Figure 6. Request processing model when a sandboxed solutions calls a full-trust proxy

The preceding description might give the impression that, with the hybrid technique, a farm solution anda sandboxed solution are always developed together by the same development team. In fact, the farmsolution may be developed specifically to provide certain operations to any and all sandboxedsolutions that need those services, including sandboxed solutions that are developed by other teams. Forexample, because a sandboxed solution cannot write to the SharePoint Unified Logging Service (ULS) logs,a farm solution that opened proxy logging operations tosandboxed solutions would be very useful.

Another hybrid technique uses client-side code to access the resources that cannot be accessed froma sandboxed solution. For example, a sandboxed solution could include a custom site page with JavaScriptthat makes calls to the SharePoint JavaScript client object model. Also, a sandboxed solution could includea Web Part that hosts a Silverlight application. The latter application can make calls to the SharePointSilverlight client object model. For more information about the client-side code in SharePoint, see ClientObject Models in SharePoint later in this article.

For more information about hybrid solution techniques, see Hybrid Approaches.

Pages, Parsing, and Safe ModeAs noted earlier in SharePoint as an ASP.NET-IIS Application, SharePoint makes extensive use of themaster page/content page distinction. But SharePoint Foundation also divides its ASPX pages along adifferent axis: It distinguishes between application pages and site pages. Both of these kinds of pages can



be mergers of master and content pages and, indeed, every ASCX page that is built into SharePoint,whether it is an application page or a site page, is a combination of a master and content page. Hereafter,in this section, there is no further mention of the master/content page distinction.

Application pages differ from site pages in the following ways:

Typical purpose: Application pages tend to be function-oriented, especially functionality that isneeded by many kinds of websites within a given web application; for example, the standard formfor creating a new list item is an application page. Site pages tend to be content-oriented; forexample, the list-of-lists page of a standard team site. However, exceptions to both tendencies arepossible. Indeed, we currently recommend that third-party developers develop custom Web Parts,which can be added to site pages, to handle their solution's functionality whenever possible, ratherthan develop custom application pages.

Customizablility: Site owners (and other users who have appropriate permissions) can customizesite pages, but not application pages. Users can also add an entirely new ASCX page to awebsite's Site Pages gallery, but only web application administrators can install a new applicationpage.

Class inheritance: Application pages are objects of the LayoutsPageBase class orthe UnsecuredLayoutsPageBase class. Site pages are objects of the WikiEditPage class ortheWebPartPage class. (All of these classes derive from the ASP.NET Page class.)

Web Part support: Application pages cannot have Web Part zones or dynamic Web Parts. Theycan have static Web Parts, but there is little point to using a static Web Part instead of an ordinarycontrol on an application page because end users cannot customize application pages anyway.Some kinds of site pages can have static Web Parts, and other kinds can have Web Part zones withdynamic Web Parts. See later in this section for more information.

Storage location: Application pages are stored on the file system of the front-end web servers inthe _layouts virtual directory of a web application (which maps to the %ProgramFiles%\CommonFiles\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS physical directory) or one ofits subdirectories. A site page that has not been customized is stored in other subdirectories of%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE, mosttypically in %ProgramFiles%\Common Files\Microsoft Shared\web serverextensions\14\TEMPLATE\SiteTemplates and %ProgramFiles%\Common Files\MicrosoftShared\web server extensions\14\TEMPLATE\FEATURES. A site page that has been customized,such as with Microsoft SharePoint Designer, is stored in the content database of the website forwhich it was customized. New site pages that have been added to the Site Pages gallery are storedjust as customized pages.

Note:

Even an uncustomized site page has an entry in the content database; but whereas the entry of acustomized page contains the ASPX markup that constitutes the page, the entry for anuncustomized page contains the path of the .aspx file on the local front-end web server. Anuncustomized page can be shared by many websites. If it is, it is referenced in each website's



Availability: An application page can be accessed from every website in the web application and istherefore shared among all the websites. But a site page is available only to a user of the websitewhere it is deployed. (Uncustomized site pages are shared by multiple websites, as noted earlier,but only websites where they have been specifically provisioned either as part of a Feature or aspart of a site definition.)

Parsing mode: Application pages are parsed in direct mode, which just means that they are parsedby the standard ASP.NET page parser. The first time an application page is requested, it is parsedand compiled and cached in the front-end web server's memory, where it remains until theapplication domain or the entire IIS host is recycled. With every subsequent request for the page, itis served from the cache, if it is there. Uncustomized site pages are also parsed in direct mode, butcustomized site pages, and new pages that are added to the Site Pages gallery, are parsed in safemode. Safe mode processing differs from direct mode (that is, from standard ASP.NET pageprocessing) in the following ways:

Only controls (including Web Parts) that are registered as safe in the web application'sweb.config file are rendered.

Inline server-side code is not allowed in safe mode, and an error page is returned to the userif the safe mode parser finds inline code on the requested site page. Inline code includes<script> elements, such as <script runat="server"> [code is here]</script>, and control event handlers, such as <asp:buttonOnClick="MyButtonHandler()" />. (Code behind that is compiled into a separateassembly is allowed, and so is embedded JavaScript.)

The page is not compiled. (And, thus, any compilation directives in the file are ignored.)

Note:

The terms safe mode parsing, safe mode processing, and safe mode rendering are usedinterchangeably in SharePoint documentation.

Security and performance are the motivations for the two kinds of pages, especially the difference inprocessing mode. One of the purposes of SharePoint is to delegate administrative control to ordinarybusiness users instead of requiring the intervention of network administrators and IT professionals. Forthis reason, users are allowed to add new pages and customize existing pages. If these users were allowed

content database, with all the entries pointing to the same physical file. For example, everyTeam Site has a content database entry pointing to the default Team Site home page. If the homepage is customized on any of the sites, it is copied into the page's entry in the content database inits customized form, and the pointer to the uncustomized version is removed.

Sometimes the uncustomized site page is referred to as a page template and the pages in thecontent database as page instances. However, remember that if the page is not customized in aparticular website, the "instance" of the page is simply the database entry pointing back to thefile on the file system.



to add any control or Web Part they wanted or add any code blocks they wanted to the pages, there is agreat danger that poor performing or malicious code would be added to a page. The reason that pagesthat use safe mode are not compiled is that there may be thousands of pages on a SharePoint installation.If every one of them was compiled into an assembly and loaded in memory, the performance of the serverwould be degraded, and only recycling the application domain would remove them. Moreover, recyclingthe application domain would remove all assemblies, not just the seldom-used pages. There is also a limiton the number of assemblies that can be loaded in an application domain that is imposed by the .NETFramework.

The safe mode parser only creates a control tree for the page, which can be unloaded again from memoryimmediately after use. On the other hand, pages that are shared, such as application pages anduncustomized site pages should be compiled on first use, because these pages are used a lot andsubsequent requests for them can be handled much faster if the pages are cached as assemblies in theserver memory. That is why they run in direct mode.

Security Note:It is possible to allow inline code, unsafe controls, or both, on selected customized site pages.You can do both things by adding one or more <PageParserPath> elements to the <SafeMode>element of the <SharePoint> section of the web application's web.config file. You can use theattributes of the <PageParserPath> element to specify a customized site page or set ofcustomized site pages, and to enable inline code and unsafe controls for the designated sitepages. However, you should use extreme caution when you make these kinds of changes,because they cancel the security benefits of safe mode. For example, if you allow inline code forall pages that have names on the pattern Contoso*.aspx in thedirectory/sites/contoso/SitePages, anyone with the right to add pages can create a page thathas a name following that pattern and add it to that directory, including a page that containsmalicious or poor-performing code. (The directory path is a "virtual path" that points to a set offiles in the content database.) Notice that allowing unsafe controls only enables such controlsthat are added in an editing tool, such as SharePoint Designer. When an end user adds a WebPart to a page in the browser, the Web Part must still be registered as safe even if unsafe controlshave been enabled in a <PageParserPath> element.

You can turn on compilation for selected customized site pages by using an attribute of the<PageParserPath> element. This might be useful if you have reason to believe that thecustomized page will be visited often enough to justify compiling it into a DLL cached inmemory.

Within the category of site pages, there are additional distinctions. In SharePoint Foundation, thereare standard site pages and Web Part site pages. Standard site pages are wiki-enabled pages that allowinline Web Parts. Standard pages are objects of a class that derives from WikiEditPage. Web Parts pages,on the other hand, derive from WebPartPage. They have one or more Web Part zones into which WebParts can be added, and they have no wiki-editable area.

SharePoint Server 2010 adds a third kind of site page: PublishingPage. (There is also a PageLayout class inSharePoint Server 2010, but this is an extension of the master page/content page system of ASP.NET, notanother kind of site page.)



SharePoint also has a set of built-in pages that are designed for mobile devices. They do not use theASP.NET master page/content page technology, and they are not divided into application pages and sitepages. SharePoint mobile pages are all application pages, and they are located inthe \_layouts\Mobile folder. There is one respect in which a SharePoint mobile page is more like acustomized site page: If the page contains a mobile Web Part adapter, the adapter must be registered asa safe control or it is not rendered.

For more information about page types in SharePoint, see Building Block: Pages and UserInterface, ASP.NET vs. SharePoint: Page Development, SharePoint Page Types, and PublishingProgramming Model in SharePoint Server 2010 (ECM). For more information about mobile pages,see Building Block: Mobile Pages, Controls, and Adapters and Overview of Mobile Pages and theRedirection System. For more information about safe controls and safe mode, see Microsoft SharePointFoundation as an ASP.NET Application.

Data Model, Data Management, and QuerySystemThe 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, datafrom 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, exceptthat the tables are called "lists" in SharePoint lingo. Indeed, the back-end storage of content data for aSharePoint Foundation web application is in one or more SQL Server databases. These are called contentdatabases. (There is also a special configuration database on the computer that is running SQL Server thatholds farm configuration data, and a special BDC database that supports Microsoft Business ConnectivityServices (BCS). For more information about BCS, see External Lists and the Business ConnectivityService later in this article.) However, there are some differences between relational database tables andSharePoint Foundation lists:

Data is not queried by SQL. Instead, data is queried in server-side code either by LINQ or byqueries formulated in CAML. For more information about server-side data querying, seeBuildingBlock: 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 LINQto SharePoint provider. For more information, see Managing Data with LINQ to SharePoint. Fromclient-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.

Caution:

Directly accessing the back-end computer that is running SQL Server by using SQL



queries, stored procedures, or any other method is not supported.

A list can have a column whose possible values are the values of a column on a different list. Thelookup column relationship between the lists is somewhat like a foreign key relationship betweentwo relational tables. However, the field on the target list that provides the values is not necessarilythe foreign key. All SharePoint Foundation lists have an ID column. This column is, in effect, alwaysthe foreign key in any lookup relationship. For more information about lookup relationships inSharePoint Foundation, see Lookups and List Relationships and List Relationships in SharePoint2010.

Lists can be joined just as tables can, but with some restrictions. There must be a lookup relationbetween the lists or they cannot be joined. For more information about list joins, seeList Joins andProjections.

A SharePoint Foundation document library is a special kind of list in which each row includes anattached document, and the other columns are data about the document, such as its author, whenit was last edited, and who has it checked out. Picture libraries are similar except that the attachedfile is an image file. For more information, see Building Block: Lists and Document Libraries.

Every list has a list type, and SharePoint Foundation includes many built-in list types that enable end-usersto create the most common kinds of business and team solutions. Among these are Announcements,Tasks, and Calendar. Developers can also create custom list types. For more information about listdevelopment, see SharePoint List Data Model.

Content Types and Field Types

A row in a list—that is, a list item—also has a type. These are called content types. Each is basically a set ofcolumns and metadata. The simplest is the built-in Item content type. All other content types are derivedfrom Item. SharePoint Foundation includes many built-in content types, such as Event andAnnouncement. Developers can create custom content types. For more information about content types,see Building Block: SharePoint 2010 Content Types, Content Types, and SharePoint Columns, Lists, andContent Types.

A column in a list, also known as a "field," also has a type, and it is distinct from the data type of the valuesthat can be stored in the field. A SharePoint Foundation field type includes not only information about theunderlying data type, but also information about how the data is formatted and rendered on forms, suchas the forms for creating, displaying, and editing specific list items. For example, it is the field type thatdetermines whether a field value is entered as string or from a drop-down list of values. Many field typesare built-in to SharePoint Foundation, such as the Modified By field on a document library and the DueDate field on a Task list. Developers can create custom field types. For more information, see BuildingBlock: Columns and Field Types, Custom Field Types, and SharePoint Columns, Lists, and Content Types.

External Lists and the Business Connectivity Service

External data, such as data in an SAP installation or Oracle database, can also be represented as a list on aSharePoint Foundation page and within SharePoint Workspace and Microsoft Office client applications.



The Microsoft Business Connectivity Services (BCS) of SharePoint Foundation enables read/write access tothis data.

The critical components of BCS are Business Data Connectivity (BDC) service models. Each model is anXML file that describes a type of external data source, such as SAP services. One or more specific instancesof the data source, such as a particular SAP database, are defined in the model, including connection andsecurity information about the data source. The business entities in the data source, such as Customer orOrder, are represented in the model by external content types, and the model also defines relationshipsbetween these entities. Finally, the model defines, for each entity, a set of standard operations,called stereotyped operations, that can be performed on the entity, including create, retrieve, update, anddelete operations. For more information about the structure of BDC models, see BDC ModelInfrastructure. The models are stored in a dedicated database on the SharePoint farm computer that isrunning SQL Server, which is distinct from the configuration database and the content databases. Thisdatabase is called the metadata store.

After a model is added to the metadata store, users can access the external data in a variety of ways. Forexample, in SharePoint Foundation, users can create a SharePoint list out of an external content type, suchas Customer, or add a column of data from the external source to an existing list. SharePoint Server 2010has some BCS enhancements: It includes some built-in Web Parts for working with external data, and itenables users to search the external data. Also, SharePoint Workspace and Microsoft Office clientapplications can access and display the external data directly. Finally, with SharePoint Server 2010, userscan index and search the external data sources.

A service named Business Data Connectivity service manages the interactions between SharePoint and theexternal data source. The service runs on an application server in the farm. There is also a BDC Runtimethat runs on all front-end web servers. When a SharePoint client application requests external data, theBDC Runtime on the front-end web server requests the metadata that defines the BDC model from alocally cached copy of the BDC metadata store. The runtime then uses the metadata provided to performdata operations directly on the external system. Similarly, on client computers that are running SharePointWorkspace and Microsoft Office client applications, a BDC Client Runtime enables direct client access tothe external data by using the BDC model, which is also cached on the client computer (although theSharePoint Server 2010 farm is still needed for long-term persistence of the BDC models). The externaldata itself can be cached on the client computer to enable an offline experience.

After the BDC service is running and the needed BDC models are registered, end users can create non-code solutions that involve external data. For more complex solutions, the BCS Runtime APIs enabledevelopers to make custom Web Parts or other solutions to interact with the external data. Because a BDCmodel provides a kind of translation between operations in code and the stereotyped operations of theexternal data source, the same APIs can be used for all external data sources no matter how different theirindividual access systems are. BDC solutions are packaged and deployed as farm solutions.

Figure 7 shows some of the major components of BCS and their relationships.

Figure 7. BCS runtime and deployment components



The BDC service is built in conformance with the Service Application Framework of SharePoint Foundation.See also Services and the Service Application Framework and Services Hierarchy later in this article.

For more information about BCS architecture, see BDC Architecture, Mechanics of Using BusinessConnectivity Services, Business Data Connectivity (BDC) Service, and External Data in SharePoint 2010.

Services and the Service ApplicationFrameworkServices 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 inMicrosoft 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 inSharePoint 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 permissionand provisioning settings. A CFSI is not an actual running process on a particular server. The same CFSIcan be running on multiple servers, but it is not the same as the entirely abstract service itself either. Eachof 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, theframework provides a means for different versions of the same basic service to be availablesimultaneously. 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 SharePointFoundation. For this article, note only that the light translucent rectangles represent services, the darkertranslucent rectangles represent CFSIs (also known as service applications), and the smaller solidrectangles represent instances of services. The CFSIs are present only for the services that implement theService Application Framework, which in this example are the Usage Service, the Application Discoveryand 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 webserver that hosts the application has a proxy to represent the service itself and a second proxy torepresent the CFSI that is being targeted. The proxies are not depicted in Figure 8, but Figure 9 shows asingle-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 applicationproxy) belongs to a web application. The content publishing web application and the CentralAdministration web application each have their own proxy for the Business Data Catalog CFSI, andthey each have their own for the Usage and Health Data CFSI. Neither has a proxy for theSubscription 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 FrameworkArchitecture, and SharePoint Service Application Topologies.

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

For more information, see Building Block: Websites and Site Collections and the Site Types: WebTemplatesand Site Definitions node of the SharePoint Foundation SDK.

SharePoint SecurityThe 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 hasalready been authenticated, which refers to the process by which the current user is identified. SharePointFoundation does not implement its own system for authentication or identity management, but insteadrelies 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). Underthis model, the user presents an identity to your SharePoint farm as a set of claims. One claim could bethe user's name, another might be an email address. An external identity system is configured to giveSharePoint all the information that it needs about the user with each request, along with cryptographicassurance that the identity data comes from a trusted source. Other types of supported authenticationinclude Windows classic authentication and ASP.NET forms-based authentication. For more informationabout authentication and SharePoint, see the Getting Started with Security and Claims-Based IdentityModel 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 bywhich 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 childobject. A role definition is a set of rights, such as rights to read, create, or delete. A role assignmentassociates a user or group with a role definition.

SharePoint supports two kinds of groups: domain groups and SharePoint groups. Domain groups remainoutside SharePoint control; users cannot use SharePoint to define, browse, or modify domain groupmembership. SharePoint groups are scoped to the site-collection level, and they can be used only withinthe 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 ina 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 therequest that is being processed. The isolation of web applications into separate application pools ensuresthat 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 theassembly is loaded out of the global assembly cache, it operates in full trust. However, if the assembly isloaded out of the web application's \bin directory, it is subject to the trust limitations that are defined bya CAS policy.

If the request is for a sandboxed solution, the SharePoint execution manager that runs in the IIS workerprocess 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 sitecollection 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 controlsand, by default, the page is not returned at all if it contains inline code blocks.

Server Object Model in SharePointThe server object model in SharePoint is large, and only some of the truly critical classes can be describedin 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 threehierarchies, see Server and Site Architecture: Object Model Overview.

Physical Objects Hierarchy

The Physical Objects Hierarchy includes classes that represent physical entities, such as servers andfarms—the two most important.

A SharePoint Foundation farm, and its configuration database, is represented by the SPFarm class. Aserver farm consists of one or more physical servers. These may include one or more front-end webservers, zero or more application servers, and a computer running SQL Server that may be hosted on adedicated 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 farmmanagement UI of the Central Administration application.) A farm may consist of just a single server. Ifthe farm has multiple front-end web servers, they are usually load-balanced. You can use any hardware orsoftware load-balancing solution, including the built-in NLB (Network Load Balancing) in Windows Server2008. SharePoint does not itself supply the load-balancing.

SPFarm inherits from SPPersistedObject, which means that the object (there is only one) that instantiatesthe class persists in the configuration database. The three most important child classesof SPFarm are SPServer, SPService, and SPSolution.

A physical server in a SharePoint Foundation farm is represented by the SPServer class. In addition tomany inherited members, it has an Address property that holds the IP address of the server anda Role property that identifies the server's role in the farm. It also has a ServerInstances property thatholds references to all the instances of Windows services and web services that are running on theserver. SPServer also inherits from SPPersistedObject, so server objects are persisted in the configurationdatabase.

For more information about the Physical Objects Hierarchy in the object model, see The Physical ObjectsHierarchy of Microsoft SharePoint Foundation and Background: Physical Objects in Microsoft SharePointFoundation.

Content Hierarchy

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

High Level Object Model

Beneath the farm, the broadest content container is the web application, which is represented bythe SPWebApplication class. An SPWebApplication object represents a content-publishing webapplication in SharePoint Foundation. It contains one or more content databases, which hold the data ofone or more site collections. Each such web application is served by at least one (and usually only one) IISwebsite and typically has its own application pool in IIS. Also, each web application has its own securityand authentication settings. The SharePoint Foundation object model provides some hooks into the webapplication'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 anASP.NET-IIS Application earlier in this article.

The SPWebApplication class has a ContentDatabases property that holds all its child content databaseobjects.

Every web application contains one or more content databases. Each of these is represented bythe 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 thecustomized page files that constitute the site collections that belong to the database. Objects thatrepresent each child site collection are in the Sites property.

Both SPWebApplication and SPContentDatabase inherit from SPPersistedObject, so these objectspersist in the farm's configuration database.

For more detailed discussions of web applications, content databases, and their classes, see The ContentHierarchy of Microsoft SharePoint Foundation and Background: Content Entities in Microsoft SharePointFoundation.

Middle Level Object Model

At the middle level of the content hierarchy are site collections and their subsites. An SPWeb objectrepresents a single website. An SPSite object represents a collection of websites within a SharePoint webapplication that are grouped together for mainly administrative reasons. (The SPSite class is not acollection 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 werecalled "root webs" in the first version of SharePoint Foundation, Microsoft SharePoint Team Services.) Inturn, the SPWeb object that represents the top-level website has a Webs property that holds all itsimmediate child subsites (but not the subsites of those subsites). (TheAllWebs property returns all thedescendent sites and the top-level website.)

Among the SharePoint elements that can be scoped to the site collection level are master pages, WebParts, themes, lists, content types, and Features. A site collection can also be a unit of backup andrestoration. It is also the level at which groups of users are created and assigned default permissions. Sitecollections are the largest possible scope for a search in SharePoint Foundation, although broader searchscopes 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 classhas 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 SiteCollections, The Content Hierarchy of Microsoft SharePoint Foundation, and Background: Content Entitiesin Microsoft SharePoint Foundation.



Tip:Both SPWeb and SPSite evolved from early versions of what is now called "SharePoint" beforethere was a .NET Framework. Even today they wrap some COM objects. The .NET Frameworkgarbage collector does not know how to release these COM resources. Accordingly, both classesimplement the IDisposable interface. If they are not disposed of, website and site collectionobjects cause memory leaks on the farm servers. It is essential that SharePoint developers callthe Dispose method of every SPWeb and SPSite that their code creates. There are somesubtleties about disposing of such objects. For example, website and site collection objects thatare obtained from the SPContext object should not be disposed of.Developers should carefullystudy Disposing Objects.

Low Level Object Model

At the heart of SharePoint are lists and list items, which are represented, respectively, bythe SPList and SPListItem classes. The SPList class has members for programmatically adding, deleting,and retrieving list items, and also for managing metadata about the list such, as its content types andfields. The SPListItem class has members for managing the item's fields, the values of its fields, its contenttype, and any associated workflows. Lists can have folders that give them a hierarchical structure. Foldersare represented by the SPFolder class.

Note that, although any given list item has a specific content type, the object model provides onlythe SPListItem class to represent all list items. Hence, working with list items and their fields is, in manyways, like working in a weakly typed environment. SharePoint includes a tool, SPMetal, that can generatecode for an object relational mapping. The generated code defines classes for each content type in awebsite and, for each field in the content type, it declares a strongly typed property. The tool makes itpossible for LINQ queries to be strongly typed. For example, if a developer mistakenly refers tothe DueDate field of the Task content type as "DateDue", the compiler catches the mistake if SPMetal isused and the reference is to a property of a Tasktype object, myTask.DateDue. However, withoutSPMetal, the reference would have to be to a member of the fields collection ofan SPListItem object, myItem["DateDue"]. The mistake would not be caught until run time.

Each field (column) on a list item is represented by an SPField object.

For more information about lists, list items, folders, and fields, see Building Block: Lists and DocumentLibraries, Building Block: Columns and Field Types, and SharePoint List Data Model.

Services Hierarchy

The Services Hierarchy includes classes that represent web services, Windows services, other types ofservices, instances of services, and CFSIs of services (see Services and the Service ApplicationFramework earlier in this article).

A SharePoint Foundation service is represented by a class that inherits from SPService. The class providesmembers that get information about the jobs the service is performing. If a service implements the ServiceApplication Framework, the SPService object has an Applications property that holds all the CFSIs of the



service that are running on the farm. A CFSI of a service is represented by an object of a class that inheritsfrom the SPServiceApplication class.

Every SPService object has an Instances property that holds all the instances of the service that arerunning on various servers in the farm. The instances that host a particular CFSI are held inthe ServiceInstances property of the SPServiceApplication object that represents the CFSI. No more thanone instance of each CFSI runs on any one server. However, a given service can have multiple CFSIs, andthey can run on the same servers. Moreover, a given CFSI (and, thus, a given service) can run on multipleservers, in which case each server has its own actual instance (a running process) of the CFSI. If the servicehas no CFSIs, it still has instances on each server on which it runs, but there can be no more than oneinstance of such a service on a given server. Each instance is represented by an object of a class derivedfrom SPServiceInstance.

Applications that consume services that conform to the framework are represented by proxies. Here, also,there is a proxy object for the service as a whole and a proxy for the particular CFSI that is beingconsumed. The consumer proxy for a service is represented by an SPServiceProxy object and the proxy forthe CFSI is represented by an SPServiceApplicationProxy object.

Figure 10 illustrates the relationships among the main classes in the Service Application Framework.

Figure 10. Relation of major classes in the Service Application Framework

The following kinds of objects are persisted in the configuration database because these classes inheritfrom SPPersistedObject:

SPService

SPServiceApplication

SPServiceInstance



SPServiceProxy

SPServiceApplicationProxy

For more information about the services object model, see The Services Hierarchy of Microsoft SharePointFoundation and Background: Service Entities in Microsoft SharePoint Foundation.

Client Object Models in SharePointThere are three client object models in SharePoint Foundation: one each for Microsoft Silverlightapplications, Microsoft .NET Framework applications, and JavaScript. They are almost the same in the APIsthat they expose. The *.js files that contain the JavaScript client object model, like all *.js files, aredownloaded automatically to the user's computer when a page that references the object model isaccessed. (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 anotheralternative is to download at run time the file %ProgramFiles%\Common Files\Microsoft Shared\webserver extensions\14\TEMPLATE\LAYOUTS\ClientBin\Microsoft.SharePoint.Client.xap, which encases theMicrosoft Silverlight assemblies.

The .NET Framework object model can be called only if the assemblies that contain the object model havebeen installed to the client computer. You must use the official redistribution package, SharePointFoundation 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 slightlychanged (usually by dropping the "SP" at the beginning of the class name). The client object models areimplemented as a WCF service (.../_vti_bin/client.svc), but they use web bindings to implementefficient request batching. Commands are serialized into XML and sent to the server in a single HTTPrequest. For every command, a corresponding server object model call is made, and the server returns aresponse 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 shieldedfrom the details of the service. In particular, the client-side runtime handles all communication betweenthe clients and server.

Microsoft.SharePoint.Client is the core namespace used for the Microsoft .NET Framework managed andSilverlight object models, and SP is the core namespace for the JavaScript object model. Client objectsinherit from the ClientObject class (JavaScript: ClientObject).

SharePoint code on a client begins by retrieving a client context object that represents the current requestcontext, and through this context, you can obtain access to client objects at the site-collection level orlower 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, toretrieve 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 ofthe 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 WCFservice, Client.svc, which runs the batched commands by calls to the server-side object model. Returneddata 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 theclient object models are used.

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

Note:The Silverlight client object model in SharePoint is not supported on Windows Phone 7.

For more information about the client object models, see the following topics:

Using the SharePoint Foundation 2010 Managed Client Object Model

Using the SharePoint Foundation Client APIs



SharePoint 2010 Client Object Model

SharePoint 2010 Client Object Model Hierarchy and Identity

Client Context as Central Object

Client Application Models in SharePoint 2010

Note:The client object models are not the only way to query SharePoint list data from a clientapplication. SharePoint also supports a WCF Data Services (formerly ADO.NET Data Services)interface to the list data. For more information, see Data Model, Data Management, and QuerySystem earlier in this article. The section Low Level Object Model earlier in this articlementions that the server object model treats content types and their field types in a weakly typedmanner, but that the SPMetal tool enables strongly typed programming against these entities. Aparallel point applies to client-side computing: Content types are weakly typed in the clientobject model, but they are strongly typed when you are programming against the WCF DataServices interface.

Workflows in SharePointLike all workflows, SharePoint workflows model and systematize business processes. However, SharePointworkflows are generally oriented around the SharePoint list data model. In most cases, each instance of aSharePoint workflow embodies processes that surround an item in a list or document library. Indeed, themost common kinds of SharePoint workflow are workflows that are associated with a list or with one ormore content types. Some SharePoint workflows are manually started, but they are most commonlydesigned to start automatically in response to some event connected with a list item or library item, suchas adding, deleting, or updating an item.

There are also workflows associated with websites rather than lists or content types. These are alwaysstarted manually (or programmatically), not automatically in response to some event. In addition, they aregenerally used to systematize processes that transcend particular list items, such as retrieving and settingvalues of multiple list items across different lists, or performing non-list operations, such as creating andconfiguring subsites.

Note:SharePoint Designer envisages two Reusable and Globally Reusable workflows. These are reallyjust list workflows that you can use on multiple lists without having to re-create them for each ofthose lists.

Workflows in SharePoint are built on the framework provided by Windows Workflow Foundation (WF).When a workflow is running in SharePoint, the WF runtime engine is hosted in the SharePoint process.The WF runtime engine loads and unloads workflow templates and provides sequencing and persistencefor workflows. The persistence services are crucial because they enable workflows to remain active



through discontinuous user sessions, through resets of the front-end web server, and even throughreboots of the server.

For many of its services, WF enables customization by hosting applications. SharePoint provides customimplementations of the following services for the engine: transaction, persistence, notifications, roles,tracking, and messaging. For example, when a workflow instance reaches a point at which it is waiting foruser input, SharePoint unloads that workflow instance from memory and persists its data in the contentdatabase. Then, when an appropriate event occurs that requires that the workflow instance start again,such as when a user enters input, SharePoint re-instantiates the workflow instance by using persisteddata, so the workflow instance can receive and handle the event as necessary.

A SharePoint workflow type is represented by two entities that work in partnership with each other. First,there is a workflow definition. These can be defined in code and compiled into an assembly, or defined inXOML markup. When the workflow type is defined in XOML, it is called a declarative or "no code"workflow, and it persists uncompiled in the content database until it is called, at which point it is compiledjust-in-time for use. The workflow definition, in either compiled or declarative form, specifies theparameters, events (such as activation), and sequence of activities in the workflow. It also defines thebranching structures of the workflow and the conditions that determine the paths of execution.

The partner of the workflow definition is the workflow template definition. A workflow template definitionis an XML file that contains the information SharePoint requires to instantiate and run the workflow, suchas the following:

Name and description of the workflow

Class within the workflow assembly to call

Identity of the workflow assembly

Location of any custom forms used in this workflow

You can store these XML files in either of two locations. The first is %ProgramFiles%\CommonFiles\Microsoft Shared\web server extensions\14\TEMPLATE\lcid\Workflow. For example, the templatedefinition of the built-in moderation workflow is stored in the moderationworkflow.xml file. The secondlocation is the Workflows list of the root website of a site collection. The built-in Three-state workflow isan example. Regardless of where it is stored, at run time, the workflow template definition is used tocreate an SPWorkflowTemplate object, which is cached to speed up the creation of workflow instances.

You can associate workflow templates with lists (including document libraries), content types, andwebsites. For any workflow template that is associated with a list or content type, an item of that list orcontent type can have an instance of the workflow in progress. Although there can be only one instanceof a specific workflow type in progress at any one time for a given item, any item can have multipleworkflows in progress, each of a different type.

You can create compiled workflows by using the Microsoft Visual Studio workflow designer. You can alsocreate declarative workflows by using SharePoint Designer. Workflows are installed as Features at the sitecollection level. But you can also "publish" a workflow directly from SharePoint Designer to a website, inwhich case there is no Feature.



A workflow type is available for a list, content type, or website only if it is associated with the list, contenttype, or website. These associations are stored in the content database of each site collection. Thisassociation data typically includes whether the workflow is started automatically or by users. If a workflowis added to multiple content types, lists, or websites, it will have one entry for each such association.Likewise, if you add multiple workflows to a specific content type, list, or website, the database containsone entry for each workflow that is added to the content type, list, or website.

For more information about the SharePoint workflow infrastructure, see Introduction to Workflows inSharePoint Foundation.

ConclusionEven an article as long as this one cannot cover all the SharePoint architectures or say everything thatcould be said about the architectures that it does cover. It does provide an overview of the mostimportant SharePoint architectures and should enable you to do further research on each of them.

This Resource comes from Microsoft Dynamic Network.

Reviewed by

Eslam Saeed

Documents

Share Point 2010 Architecture 01