SharePoint 【架构系列】-- Sharepoint的四种执行模型 01
Sharepoint210有四种执行模型
1、完全信任执行模型(Full Trust)
2、Bin/CAS 执行模型 （1与2都属于场解决方案）
3、沙盒执行模型(Sand Box)
4、 混合执行方法 (Hybrid Approach)
下面分别来看看它们是怎么回事
一、场解决方案
场解决方案是在 SharePoint 环境中通过服务器端文件系统部署的资源的集合。这些资源可能包含 Microsoft .NET Framework 程序集以及网页、图像和配置文件等非编译组件。在 SharePoint 2010 中的沙盒解决方案库出现之前，场解决方案方法是唯一可将自定义功能部署到 SharePoint 环境的方法。
通常，场解决方案打包为 SharePoint 解决方案包 (WSP) 文件，其中包含程序集、其他未编译组件和 XML 清单文件(这些未编译的文件存放在目录%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\的相关子目录下)。服务器场管理员使用 Windows PowerShell™、STSADM 命令行工具或 SharePoint 管理中心网站将解决方案包安装到服务器环境中。安装解决方案包之后，场管理员可以将该解决方案激活到一个特定 Web 应用程序（或多个 Web 应用程序，如果使用完全信任模型）。
您可以将场解决方案配置为使用完全信任执行模型(Full Trust)或 Bin/CAS 执行模型。
如果使用完全信任方式，解决方案包将程序集部署到每个 Web 服务器上的全局程序集缓存(GAC )。
如果使用 Bin /CAS 方式，解决方案包将程序集部署到每个 Web 服务器上 Internet Information Services (IIS) 文件结构中特定 Web 应用程序的 Bin 文件夹中。
在这两种情况下，解决方案包可以将其他组件（如资源文件、ASCX 用户控件和 ASPX 网页）部署到每个 Web 服务器上的 SharePoint 目录结构中（通常称为"SharePoint 根目录"）。
1、完全信任执行(Full Trust)模型的原理
有关完全信任场解决方案执行方式的准确详细信息会因所部署的 SharePoint 组件的类型而略微有所不同。
例如，Web 部件(Web Part)程序集和大多数事件接收器(Event Receiver)都由一个 IIS 工作进程 (W3wp) 加载，而计时器作业由 SharePoint 计时器作业进程 (Owstimer.exe) 加载。但是，概念大体上是相同的（尽管计时器 进程通常在权限级别比 IIS 工作进程更高的帐户下运行）。在本例中，假设您部署了一个 Web 部件。对该 Web 部件逻辑的调用请求将定向到用于管理与该请求关联的 Web 应用程序的 IIS 工作进程。该 IIS 工作进程从全局程序集缓存加载相应的程序集。因为程序集位于全局程序集缓存中，不受代码访问安全 (CAS) 策略的限制，所以，它可以不受限制地访问 SharePoint 对象模型，也可以从该工作进程访问的任何其他 API。该程序集还可以访问远程资源，如数据库、Web 服务和 Windows Communication Foundation (WCF) 服务。
下图 显示了完全信任执行方式(Full Trust)的各个组件。
2、Bin/CAS 执行模型的原理
如果使用Bin/CAS 执行模型部署场解决方案，程序集将添加到 SharePoint Web 应用程序的 IIS 文件结构中的 Bin文件夹中。因此，程序集只能通过与该 Web 应用程序关联的 IIS 工作进程(W3WP)加载（这与完全信任执行模型不同，在该模型中，通过全局程序集缓存部署的程序集可由任何进程加载）。由于有这种差异，不能使用 Bin/CAS 解决方案部署各种 SharePoint 组件，如计时器作业、事件接收器、服务应用程序和工作流，这些都需要将程序集提供给其他进程使用。
代码的调用请求将定向到运行与该请求关联的 Web 应用程序的 IIS 工作进程(W3WP)。IIS 工作进程从 IIS 文件系统中 Web 应用程序的 Bin 文件夹加载相应程序集。因为程序集位于 Bin文件夹中，所以将受该 Web 应用程序的配置文件中定义的代码访问安全策略(CAS)的限制。这些策略定义程序集可以使用 SharePoint 对象模型以及其他 API、数据库和服务的程度。
下图 显示了 Bin/CAS 执行模型的各个组件。
3、完全信任执行(Full Trust)模型与Bin/CAS 执行模型的比较
完全信任场解决方案在功能或范围方面没有限制。您可以通过完全信任解决方案部署所有类型的 SharePoint 组件，可以将组件提供给服务器场内的网站集使用。
Bin/CAS 解决方案具有更多限制。范围将限于目标 Web 应用程序，功能受应用于 Web 应用程序的代码访问安全策略的约束。Bin/CAS 解决方案也不适用于计时器作业、事件接收器、服务应用程序和工作流的部署，因为这些组件需要将程序集部署到全局程序集缓存。换言之，Bin/CAS 方法仅适用于由 IIS 工作进程 (W3wp.exe) 加载的组件（如 Web 部件程序集），因为只有 IIS 工作进程才能访问 Bin 文件夹。在某些情况下，开发人员使用混合方法将 Web 部件程序集部署到 Bin 文件夹，将其他程序集部署到全局程序集缓存，在全局程序集缓存中，程序集可由任意进程加载，CAS 策略不适用。
- 进程和机制。完全信任解决方案通过宿主进程的权限集运行，而 Bin/CAS 解决方案受 Web.config 指定的 CAS 策略的约束。
- 功能。完全信任解决方案在功能方面不受限制。您不能使用 Bin/CAS 解决方案部署计时器作业、事件接收器、服务应用程序或工作流，因为这些组件需要将程序集部署到全局程序集缓存。
- 核心问题。场解决方案无法部署到每个 SharePoint 环境，托管或集中管理的环境尤其如此。在开发第三方组件时，这是一个重要问题，因为创建场解决方案会限制可使用您的组件的方案的数量。场解决方案不受监视或资源的限制，必须注意确保解决方案不会影响更大范围的 SharePoint 环境中的稳定性或安全性。
此处需要强调的是微软不再建议使用 Bin/CAS 模型方法，只有当完全信任的场方案与沙盒解决方案都不能满足你的要求时，才考虑采用Bin/CAS 模型方法，也即把它当成最后不得已的选项。
二、沙盒解决方案
与任何 ASP.NET 应用程序一样，场解决方案在 IIS 工作进程中运行，而沙盒解决方案却在具有特殊限制的执行环境中运行。这对于阻止未授权或性能不佳的代码减慢应用程序池的速度或导致应用程序池发生崩溃很重要。因此，SharePoint 将对可在沙盒解决方案中执行的代码施加限制。作为此系统的实现的关键部分，沙盒解决方案必须在特殊沙盒工作进程 (SPUCWorkerProcess.exe) 中运行。
当请求尝试访问沙盒解决方案时，IIS 工作进程中运行的 SharePoint 执行管理器将查找沙盒解决方案的代码将在其中运行的沙盒工作进程（如果未运行任何沙盒工作进程，则启动一个沙盒工作进程）。一般而言，可在运行 SharePoint Foundation 沙盒代码服务 (SPUCHostService.exe) 的服务器场中的任何服务器上启动此沙盒工作进程。在 Windows"服务"对话框中，它称作"SharePoint 2010 用户代码主机"服务。
运行 SharePoint Foundation 沙盒代码服务的服务器可以是（但并不一定是）运行 IIS 工作进程的前端 Web 服务器。可在管理中心应用程序内配置要使用的服务器：管理员可选择在"本地模式"中运行每个沙盒进程，这意味着 将在运行 IIS 工作进程的同一前端 Web 服务器上处理对沙盒解决方案的每个请求；或者，管理员可让执行管理器在"远程模式"（有时称作"相似性模式"）中启动每个沙盒进程。在后一种模式中，执行管理器将查找运行 SharePoint Foundation 沙盒代码服务的服务器，该服务器已在其 SPUCWorkerProcess.exe 进程内为相同的沙盒解决方案创建了一个应用程序域。（如果其他网站集的另一个用户之前已请求该相同的沙盒解决方案，则将出现此情况）。如果存在一个匹配的应用程序域，则会将请求发送到相同的应用程序域以进行处理。如果运行 SharePoint Foundation 沙盒代码服务的任何服务器都不具有沙盒解决方案的应用程序域，则执行管理器会将请求分配给这些服务器中最闲的服务器。之后，该服务器将创建所需的应用程序域并处理对沙盒解决方案的请求。不管使用的是"本地模式"还是"相似性模式"，沙盒工作进程中的应用程序域都将在处理完请求后保持活动状态，且如果存在对相同沙盒解决方案的其他请求，则将重用该应用程序域。
由给定服务器处理的所有沙盒解决方案都在相同的沙盒工作进程中运行。每个沙盒解决方案会在常规进程中获取其自己的应用程序域。SharePoint Foundation 沙盒代码服务在服务器场帐户下运行。
当第一次访问沙盒方案时（例如：某个用户访问某个页面，这个页面上包含有以沙盒方案定义的Web Part）,此沙盒方案所在的程序集就会被解包，然后被拷贝到负责处理此沙盒方案的服务器的文件系统中去，默认的文件系统目录是 C:\ProgramData\Microsoft\Sharepoint\UCCache. 此目录所在位置是可以通过配置文件进行修改的。需要注意的，这个拷贝过程不是由运行沙盒方案的工作进程来完成的，因为此工作进程并没有权限操作文件系统，因此，这个拷贝过程是由User Code Host Service来完成的。此目录如下图:
沙盒的程序集并不会在UCCache中一直停留，当用户访问沙盒方案的程序集所相关的Session结束时，此程序集会在UCCache中再保留很短的时间，如果有另一个请求来到，它就会被再次加载。如果最终再没有哪个请求来访问它了，系统将会基于某种算法（服务器是否繁忙、上次访问已经结束多长时间了）来决定这个程序集是否从UCCache中移除。如果在移除后又有用户访问此沙盒方案，于是又重新前面的操作过程，即解包，拷贝与运行……...。
需要说明的是：不管是管理员，还是开发人员或者是第三方代码都无权对UCCache进行任何操作(添加、移除或加载)，只有Sharepoint的基础架构自身才有权来对UCCache进行访问与操作。
转载：http://www.cnblogs.com/wsdj-ITtech/archive/2012/11/16/2544201.html
