SharePoint 2010 Sandbox Solution 2 – Architecture and Execution Model

In my previous post, SharePoint 2010 Sandbox Solution 1 – Overview of Sandboxed Solution, I gave an overview of Sandboxed solutions. Now I’d like to peek into the architecture and execution model.

Architecture

Sandbox solution is often called user solution. The primary API for sandbox solution is Microsoft.SharePoint.UsserCode and the service that takes care of it is SharePoint 2010 User Code Host.
The first question that normally arises is where the assemblies are deployed – The assembly is packaged in a wsp file and the wsp is uploaded in the solution gallery. When, for the first time, the assembly is required (e.g. a page is accessed which contains a webpart of the sandboxed solution) then the assembly is extracted from the gallery and copied to the file system (C:\ProgramData\Microsoft\SharePoint\UCCache) of the server that is handling the request. This may not be web front end server as it is handled by User Code Host Service.
Who copies the assembly to the file system as SPUCWorkerProcess.exe can’t write to file system? The answer is SharePoint 2010 User Code Host service.
Once the user session, which accessed the assembly, ends, the assembly stays in the cache for a short time. If the same assembly is required by some other session it can be accessed from the cache, if present. Otherwise, it needs to be extracted from the solution again. Below is the detailed execution process:


This chronicles the process of using a custom Web Part and solution in a particular site.

1. The SPSite admin uploads a new solution package (*.wsp) into the Solution Gallery of the SPSite.
2. The SPSite admin “activates” the solution. This activates the features within the solution. Web Part files are copied into the Web Part gallery.
1. As part of the activation, solution is validated using the validation framework. A custom validator can be added, for example, to check that only solutions signed with a certain key  can be activated. Customers and partners can develop their own validators based on their needs.
3. Some time later, a user decides to add a Web Part to their homepage. They go into Web Part edit mode and click “Add a Web Part.” They notice the additional Web part options and click Add.
4. SharePoint now checks to see if the custom webpart.dll file, which backs this Web Part, is installed into the assembly cache. It is not.
5. The assembly is faulted into the assembly cache; it is extracted and copied from the solution file to a temporary folder in the disk and loaded to the memory (the disk is cleaned immediately). Now the Web Part is about to be used.
6. It is loaded into Sandbox Code service host.
7. Processes deliver the Web Part to be executed to the service.

Execution Model

We’ll see the same execution from the perspective of the execution model.

1. A request comes in for a page with a Web Part from a partial trust assembly. This is delegated to a Web Part proxy. The Web Part proxy then in turn calls the worker process manager, and tells it to execute the Web Part.
2. The worker process manager queries the configuration database to figure out which machine and process it should send the request to.
3. The worker process then sends the request to the user code manager on that machine.
4. The user code manager needs to ensure that the assembly backing the Web Part is locally deployed. To do this, it reaches back into the Web Part solution package, extracts the assembly, and places it into the assembly cache.
5. Now, the SPUserCodeManager (SPUserCodeHostService.exe) delegates the request to execute the code to SPUswerCodeWorkerProcess.exe. The full trust Web Part wrapper works with the instantiated process to simulate the Web Part lifecycle.
6. The Web Part itself calls into the SharePoint OM to retrieve some set of data.
7. The resulting HTML and viewstate changes are bubbled back to the hosting process, which has been synchronously waiting for this infrastructure to complete.
8. The resulting page is sent back to the user.
9. Rendered results are sent back to the requester.