In my previous blog, I took up overview of Sand boxed
solutions. Now the time is to take a lift and peek into the architecture and
execution model
Architecture
Sandbox solution is often called as 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.
Now the first question arises is where the assemblies are
deployed – The assembly is packaged in 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).
But 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 again it needs to be extracted from the solution. Following is the
detailed execution process
This chronicles the process of using a custom Web Part and solution in a particular site.
- The
SPSite admin uploads a new solution package (*.wsp) into the Solution
Gallery of the SPSite.
- The
SPSite admin "activates" the solution. This activates the
features within the solution. Web Part files are copied into the Web
Part gallery.
• As
part of the activation, solution is validated using the validation framework.
Custom validator can be added for example to check that only solutions signed
with certain key can be activated. Customers and partners can develop their own
validators based on their needs.
- Sometime
later, a user decides to add a Web Part to their home page. They go
into Web Part edit mode, and click "Add a Web Part". They
notice the additional Web Part options, and click Add.
- 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.
- The
assembly is faulted into the assembly cache; it is extracted and copied
from the solution file to temporary folder in disk and loaded to memory
(disk is cleaned immediately). Now the Web Part is about to be used.
- It is
loaded into Sandbox Code service host.
- Processes
deliver the Web Part to be executed to the service.
Execution Model
We’ll see the same execution from the perspective of
execution model
- An
incoming 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
- The
worker process manager queries the configuration database to figure out
which machine and process it should send the request to
- The
worker process then sends the request to the user code manager
on that machine
- 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
- Now,
the SPUserCodeManager (SPUserCodeHostService.exe) delegates the request
to execute the code to SPUserCodeWorkerProcess.exe. The full trust Web
Part wrapper works with the instantiated process to simulate the Web Part
lifecycle
- The
Web Part itself calls into the SharePoint OM to retrieve some set of data
- The
resulting HTML and viewstate changes are bubbled back to the hosting
process, which has been synchronously waiting for this
infrastructure to complete
- The
resulting page is sent back to the user
- Rendered
results sent back to the requester
So, that’s it. Hope this blog served the purpose. I’ll be
back with the next part of this series soon J
No comments:
Post a Comment