What Are the SharePoint Execution Models?

In terms of execution models, there are two principal types of solution in SharePoint 2010: farm solutions and sandboxed solutions. Within each type of solution, there are various execution models available to you. Farm solutions can include components that run in a full-trust environment or components that run under code access security policy restrictions. Sandboxed solutions can include components that run entirely within the sandbox environment as well as hybrid approaches that can include various full-trust components. This topic introduces these execution models and describes the key concepts behind each approach.

Farm Solutions

A farm solution is a collection of resources that you deploy through the server-side file system in your SharePoint environment. These resources execute within the same process space as the SharePoint application, which means that your code can use the full SharePoint object model and has access to all the same resources as SharePoint itself.

When you deploy a farm solution, you can choose from two different execution models: the full trust execution model and the bin folder/code access security (bin/CAS) execution model. These models will already be familiar to you if you have worked with Office SharePoint Server 2007 and Windows SharePoint Services 3.0.

The Full Trust Execution Model

When you use the full-trust execution model, you deploy your assemblies to the global assembly cache on each Web front-end server and application server in the server farm. The SharePoint Web application process loads the assembly from the global assembly cache and your code runs with full trust—in other words, it runs without any code access security restrictions.

The full trust execution model


Because the assemblies are deployed to the global assembly cache, you can make your solution available to any Web application on the server farm.

For more information about the full-trust execution model, see Farm Solutions.

The Bin/CAS Execution Model

The bin/CAS approach is a partial trust execution model. When you use the bin/CAS execution model, you deploy your assemblies to the bin directory associated with a SharePoint Web application. The worker process associated with the SharePoint Web application loads the assembly from the bin directory. However, the operations your code may perform are restricted by the code access security policies that are applied in the Web.config file to assemblies in the bin directory.

The bin/CAS execution model


Because the assemblies are deployed to the bin folder of a specific Web application, your solution is, by definition, scoped to that Web application instead of to the farm as a whole.

In terms of deployment, the only differences between the full-trust execution model and the bin/CAS execution model are the location where you deploy your assemblies and the code access security policies associated with that location. In both cases, any non-compiled items, such as ASP.NET markup files, XML files, or resource files, are typically deployed to the SharePoint root on each Web front-end server. If you want to deploy a farm solution using either of the farm solution execution models, you must have access to the server file system and be a member of the Farm Administrators security group.

For more information about the bin/CAS execution model, see Farm Solutions.

Sandboxed Solutions

Sandboxed solutions are new to SharePoint 2010. A sandboxed solution is a collection of resources that you deploy directly to a specialized gallery (library) in the root site of a site collection. This library is referred to as the Solutions Gallery. Just like a farm solution, you package a sandboxed solution as a SharePoint solution package (WSP). However, you can deploy a sandboxed solution without physical access to the server file system and without the involvement of the IT team by directly uploading the WSP through the Web user interface (UI). Instead, the site collection administrator determines who has permissions to add sandboxed solutions to his or her site collection.

To counterbalance this newfound freedom to deploy solutions without the explicit approval of the IT team, SharePoint includes several constraints that restrict what you can do with a sandboxed solution. The following are some examples:

  • Your code has access to a limited, "safe" subset of the SharePoint object model.
  • Your assemblies are loaded by an isolated process that uses a low-privilege identity.
  • The solution framework terminates your code if it does not respond to requests within a specified duration.

The IT team allocates a resource quota to each site collection that defines the boundaries within which the sandboxed solution must operate. The solution framework shuts down all sandboxed solutions within a site collection if the site collection uses up its daily resource quota for sandboxed solutions. Within an individual site collection, administrators can review the resources consumed by individual sandboxed solutions from the site collection user interface.

There are two approaches to execution using the sandboxed solution environment. You can deploy a solution that runs entirely within the sandbox environment, which is referred to as the sandbox execution model. However, the sandbox environment also allows you call out to full-trust components under certain conditions. For example, you can consume specially developed, fully trusted, global assembly cache–deployed classes from your sandboxed solutions via a full trust proxy. These approaches are referred to as hybrid execution models.

It is important to draw a distinction between components that you can deploy within a sandbox solution and components that actually execute in the sandbox environment. For example, you can deploy a declarative workflow in a sandbox solution. However, all workflow logic actually executes with full trust. Any calls to the SharePoint object model actually execute with full trust. These concepts are explained in greater detail in the topics that follow.

The Sandbox Execution Model

When a SharePoint Web application process receives a request that invokes your sandboxed solution, the Web application process does not directly load your assembly. Instead, the Web application process loads an execution wrapper that loads your assembly into an isolated sandbox process.

The sandbox execution model


When you use the sandbox execution model, your solution is limited in scope to the site collection in which it is deployed. In addition to the constraints outlined previously, the solution cannot access content or resources from other site collections.

For more information about the sandbox execution model, see Sandboxed Solutions.

Hybrid Execution Models

There are times when the benefits of the sandbox approach are appealing to an organization, but the limitations of the sandbox environment prevent you from creating a complete solution. In these cases, a hybrid approach may offer an attractive solution. Sandboxed solutions can access full trust components through various mechanisms. For example, sandboxed solutions can do the following:

  • They can use a full trust proxy to access logic that runs with full trust, such as calls to APIs that are not permitted in the sandbox or calls to external services.
  • They can use a declarative workflow to access a code-based custom workflow activity.
  • They can use an external list to access external data through Business Connectivity Services (BCS).

These full-trust components could be developed in parallel with the sandboxed functionality, or they might be developed and deployed by the IT team to make additional functionality available to sandboxed solution developers. For example, the SharePoint Guidance Library includes a full-trust proxy that you can use to enable sandbox developers to log events and trace information from their sandboxed solutions.

In the first hybrid approach described in this topic, you can execute global access control–deployed, full-trust code from a sandboxed solution by using a full trust proxy. The full-trust proxy is a controlled exit point that allows your sandboxed code to make a synchronous call out to logic that executes outside of the sandbox process.

Hybrid execution using a full-trust proxy


It is important to understand that the full-trust proxy is implemented by the fully trusted component, instead of by the sandboxed solution. If sandboxed solution developers could use a proxy to run any global assembly cache–deployed code, this would subvert the restrictions placed on the sandbox environment. In order to provide services to sandboxed solutions, your fully trusted classes must inherit from the SPProxyOperation abstract class. After your full-trust proxies are deployed to the global assembly cache, they can be consumed from any sandboxed solution in the SharePoint farm.

Creating a full-trust proxy should be carefully considered and managed, because it increases the scope for sandboxed applications to cause security or performance issues. Generally speaking, you should aim to keep the functionality that you expose to sandboxed applications through a full-trust proxy to the minimum required.

In the second hybrid approach described in this topic, the full-trust component is a custom workflow activity that is deployed to the global assembly cache. You can consume the custom workflow activity in a declarative workflow from your sandboxed solution.

Hybrid execution using a declarative workflow


Using this approach, the fully trusted logic in the custom workflow activity is invoked asynchronously when the sandbox process executes the declarative workflow.

In final hybrid approach described in this topic, the full-trust component is an external content type defined in the BCS. The sandboxed solution includes an external list that connects to the external content type. As a result, the sandboxed solution can access data from other applications through the external list, even though the sandbox is prohibited from directly making external connection.

Hybrid execution using an external list


The external content type is a new SharePoint 2010 feature that enables you to define a connection to an external data source. External content types can also define a set of CRUD (Create, Retrieve, Update, and Delete) operations that allow you to manipulate that external data from your SharePoint environment. External lists connect to external content types and provide a SharePoint list wrapper around external data, so that you can access and manipulate that external data from the familiar format of a SharePoint list. For more information about external lists and external content types, see Business Connectivity Services Fundamentals on MSDN.

For more information about hybrid execution models, see Hybrid Approaches.