SharePoint [architecture series]-Four Execution models of SharePoint 01

Sharepoint210 has four execution Models

1. Full Trust)

2. bin/CAS execution model (both 1 and 2 are field solutions)

3. Sandbox execution model (sand box)

4. hybrid approach)

Next, let's take a look at how they are going.

I. Solutions

The field solution is a collection of resources deployed in the SharePoint environment through the server-side file system. These resources may contain Microsoft. NET Framework Assembly and non-compiled components such as webpages, images, and configuration files. Before the sandbox solution library in SharePoint 2010 appears, the field solution method is the only way to deploy custom features to the SharePoint environment.

Generally, the Farm solution is packaged as a Sharepoint solution package (WSP) file, contains the Assembly, other uncompiled components, and XML inventory files (these uncompiled files are stored in related subdirectories in the directory % ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ ). The server farm administrator uses Windows powershell, stsadm command line tool, or the SharePoint Administration Center website to install the solution package to the server environment. After the solution package is installed, the farm administrator can activate the solution to a specific web application (or multiple web applications, if a fully trusted model is used ).

You can configure the Farm solution to use the full trust or bin/CAS execution model.

If you use full trust, the solution package deploys the assembly to the Global Assembly Cache (GAC) on each web server ).

If you use the bin/CAS method, the solution package deploys the assembly to the bin folder of a specific web application in the Internet Information Services (IIS) file structure on each web server.

In both cases, the solution package can include other components (such as resource files, ascx user controls, and aspx web pages) deployed to the SharePoint directory structure on each Web Server (commonly referred to as "SharePoint root directory ").

1. Principle of full trust model

The exact details about how the fully trusted Farm solution is executed are slightly different for the type of the deployed SharePoint component.

For example, the web part assembly and most event receivers are loaded by an IIS worker (w3wp), while the timer job is loaded by the SharePoint timer job process (owstimer.exe. However, the concept is basically the same (although the timer process usually runs under an account with a higher permission level than the IIS working process ). In this example, assume that you have deployed a Web part. Call requests to the Web Part logic are directed to the IIS worker process used to manage the web application associated with the request. The IIS worker process loads the corresponding Assembly from the Global Assembly Cache. Because the Assembly is located in the Global Assembly Cache and is not restricted by the code access security (CAS) policy, it can access the SharePoint object model without restriction, you can also access any other API from this worker process. The Assembly can also access remote resources, such as databases, web services, and Windows Communication Foundation (WCF) services.

Shows the components of full trust.

 

2. Principles of bin/CAS execution model

If you use bin/CAS to run the Model Deployment field solution, the Assembly is added to the bin folder in the IIS File structure of the SharePoint web application. Therefore, an assembly can only be associated with the Web application through the IIS Worker Process (W3wp) Load (this is different from the fully trusted execution model. In this modelAnyProcess loading ). Due to this difference, you cannot use the bin/CAS solution to deploy various SharePoint components, such as timer jobs, event receivers, service applications, and workflows, these must be provided to other processes.

The call request of the Code is directed to the IIS Working Process (w3wp) of the Web application associated with the request ). IIS workers load the corresponding Assembly from the bin folder of the Web application in the IIS File System. Because the Assembly is located in the bin folder, it will be restricted by the code access security policy (CAS) defined in the configuration file of the Web application. These policies define the degree to which an assembly can use the SharePoint object model and other APIs, databases, and services.

Displays the components of the bin/CAS execution model.

3. Comparison between the full trust model and the bin/CAS execution model

A fully trusted Farm solution has no limits on its functionality or scope. You can deploy all types of SharePoint components through a fully trusted solution, and provide the components to the site set on the server.

Bin/CAS solutions have more restrictions. The scope is limited to the target Web application, and the function is restricted by the code access security policy applied to the Web application. The bin/CAS solution does not apply to the deployment of timer jobs, event receivers, service applications, and workflows because these components need to deploy the assembly to the Global Assembly Cache. In other words, the bin/CAS method is only applicable to components loaded by IIS Worker Process (w3wp.exe) (such as Web assembly), because only IIS worker processes can access the bin folder. In some cases, developers use a hybrid method to deploy Web assembly to the bin folder, deploy other assembly to the Global Assembly Cache, and in the Global Assembly Cache, the Assembly can be loaded by any process, and the CAS policy is not applicable.

• Processes and mechanisms. The fully trusted solution runs through the permission set of the host process, while the bin/CAS solution is restricted by the CAS policy specified by web. config.
• Function. A fully trusted solution has no functional limitations. You cannot deploy timer jobs, event receivers, service applications, or workflows using the bin/CAS solution because these components need to deploy the assembly to the Global Assembly Cache.
• Core issues. The Farm solution cannot be deployed in each SharePoint environment, especially in hosted or centrally managed environments. This is an important issue when developing third-party components because creating a farm solution limits the number of solutions that can use your components. The on-site solution is not monitored or restricted by resources. Make sure that the solution does not affect stability or security in a wider SharePoint environment.

It should be emphasized that Microsoft no longer recommends using the bin/CAS model method. Only when the field solution and sandbox solution that are fully trusted cannot meet your requirements, to consider using the bin/CAS model method, that is, taking it as a last resort option.

Ii. Sandbox Solutions

Like any ASP. NET application, the field solution runs in the IIS working process, while the sandbox solution runs in the execution environment with special restrictions. This is important to prevent unauthorized or poorly performing code from slowing down the application pool or causing the application pool to crash. As a result, Sharepoint imposes limits on the code that can be executed in the sandbox solution. As a key part of the implementation of this system, the sandbox solution must run in the special sandbox Worker Process (spucworkerprocess.exe.

When a request attempts to access the sandbox solution, the SharePoint execution manager running in the IIS Working Process searches for the sandbox solution code and runs the sandbox Working Process in it (if no sandbox working process is running, starts a sandbox working process ). Generally, you can start the sandbox Worker Process on any server on the server farm that runs the SharePoint Foundation sandbox Code Service (spuchostservice.exe. In the windows "service" dialog box, it is called the "SharePoint 2010 user code host" service.

The server that runs the SharePoint Foundation sandbox code service can be (but not necessarily) the front-end web server that runs the IIS workflow. You can configure the server to be used in the Management Center application: the administrator can choose to run each sandbox process in "Local Mode, this means that each request to the sandbox solution will be processed on the same front-end web server that runs the IIS working process; or, the administrator can ask the execution manager to start each sandbox Process in "remote mode" (sometimes called "similarity mode. In the latter mode, the execution manager searches for the server that runs the SharePoint Foundation sandbox code service, the server has created an application domain for the same sandbox solution in its spucworkerprocess.exe process. (If another user in another website set has previously requested the same sandbox solution, this will happen ). If a matched application domain exists, the request is sent to the same application domain for processing. If any server running the SharePoint Foundation sandbox Code Service does not have an application domain for the sandbox solution, the execution manager allocates requests to the most idle servers on these servers. Then, the server creates the required application domains and processes requests for the sandbox solution. No matter whether the local mode or similarity mode is used, the application domains in the sandbox worker process will remain active after processing the requests, if there are other requests for the same sandbox solution, the application domain will be reused.

All sandbox solutions processed by the given server run in the same sandbox worker process. Each sandbox solution obtains its own application domain in a general process. The SharePoint Foundation sandbox code service runs under the server farm account.

When you access the sandbox solution for the first time (for example, a user accesses a page that contains a Web part defined in the sandbox solution ), the Assembly where the sandbox solution is located will be unwrapped and copied to the file system of the server responsible for processing the sandbox solution. The default file system directory is C: \ programdata \ Microsoft \ SharePoint \ uccache. the directory location can be modified through the configuration file. Note that this copy process is not completed by the working process running the sandbox solution, because the working process does not have the permission to operate the file system. Therefore, the copy process is completed by the user code host service. This directory is shown in the following figure:

The Sandbox assembly does not stay in uccache. When the session related to the Assembly that the user accesses the sandbox scheme ends, the assembly of this program will be retained for a short time in uccache, if another request comes, it will be loaded again. If no more requests come to access the cluster, the system determines whether the Assembly is removed from the uccache based on an algorithm (whether the server is busy or how long the last access has been completed. If another user accesses the sandbox solution after the removal, the previous operation is re-performed, namely, unpacking, copying and running ..........

It should be noted that no operations (add, remove, or load) on the uccache are permitted for administrators, developers, or third-party code ), only the SharePoint infrastructure itself has the right to access and operate the uccache.

Reprinted: http://www.cnblogs.com/wsdj-ITtech/archive/2012/11/16/2544201.html

Sharepoint210 has four execution Models

1. Full Trust)

2. bin/CAS execution model (both 1 and 2 are field solutions)

3. Sandbox execution model (sand box)

4. hybrid approach)

Next, let's take a look at how they are going.

I. Solutions

The field solution is a collection of resources deployed in the SharePoint environment through the server-side file system. These resources may contain Microsoft. NET Framework Assembly and non-compiled components such as webpages, images, and configuration files. Before the sandbox solution library in SharePoint 2010 appears, the field solution method is the only way to deploy custom features to the SharePoint environment.

Generally, the Farm solution is packaged as a Sharepoint solution package (WSP) file, contains the Assembly, other uncompiled components, and XML inventory files (these uncompiled files are stored in related subdirectories in the directory % ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ ). The server farm administrator uses Windows powershell, stsadm command line tool, or the SharePoint Administration Center website to install the solution package to the server environment. After the solution package is installed, the farm administrator can activate the solution to a specific web application (or multiple web applications, if a fully trusted model is used ).

You can configure the Farm solution to use the full trust or bin/CAS execution model.

If you use full trust, the solution package deploys the assembly to the Global Assembly Cache (GAC) on each web server ).

If you use the bin/CAS method, the solution package deploys the assembly to the bin folder of a specific web application in the Internet Information Services (IIS) file structure on each web server.

In both cases, the solution package can include other components (such as resource files, ascx user controls, and aspx web pages) deployed to the SharePoint directory structure on each Web Server (commonly referred to as "SharePoint root directory ").

1. Principle of full trust model

The exact details about how the fully trusted Farm solution is executed are slightly different for the type of the deployed SharePoint component.

For example, the web part assembly and most event receivers are loaded by an IIS worker (w3wp), while the timer job is loaded by the SharePoint timer job process (owstimer.exe. However, the concept is basically the same (although the timer process usually runs under an account with a higher permission level than the IIS working process ). In this example, assume that you have deployed a Web part. Call requests to the Web Part logic are directed to the IIS worker process used to manage the web application associated with the request. The IIS worker process loads the corresponding Assembly from the Global Assembly Cache. Because the Assembly is located in the Global Assembly Cache and is not restricted by the code access security (CAS) policy, it can access the SharePoint object model without restriction, you can also access any other API from this worker process. The Assembly can also access remote resources, such as databases, web services, and Windows Communication Foundation (WCF) services.

Shows the components of full trust.

 

2. Principles of bin/CAS execution model

If you use bin/CAS to run the Model Deployment field solution, the Assembly is added to the bin folder in the IIS File structure of the SharePoint web application. Therefore, an assembly can only be associated with the Web application through the IIS Worker Process (W3wp) Load (this is different from the fully trusted execution model. In this modelAnyProcess loading ). Due to this difference, you cannot use the bin/CAS solution to deploy various SharePoint components, such as timer jobs, event receivers, service applications, and workflows, these must be provided to other processes.

The call request of the Code is directed to the IIS Working Process (w3wp) of the Web application associated with the request ). IIS workers load the corresponding Assembly from the bin folder of the Web application in the IIS File System. Because the Assembly is located in the bin folder, it will be restricted by the code access security policy (CAS) defined in the configuration file of the Web application. These policies define the degree to which an assembly can use the SharePoint object model and other APIs, databases, and services.

Displays the components of the bin/CAS execution model.

3. Comparison between the full trust model and the bin/CAS execution model

A fully trusted Farm solution has no limits on its functionality or scope. You can deploy all types of SharePoint components through a fully trusted solution, and provide the components to the site set on the server.

Bin/CAS solutions have more restrictions. The scope is limited to the target Web application, and the function is restricted by the code access security policy applied to the Web application. The bin/CAS solution does not apply to the deployment of timer jobs, event receivers, service applications, and workflows because these components need to deploy the assembly to the Global Assembly Cache. In other words, the bin/CAS method is only applicable to components loaded by IIS Worker Process (w3wp.exe) (such as Web assembly), because only IIS worker processes can access the bin folder. In some cases, developers use a hybrid method to deploy Web assembly to the bin folder, deploy other assembly to the Global Assembly Cache, and in the Global Assembly Cache, the Assembly can be loaded by any process, and the CAS policy is not applicable.

• Processes and mechanisms. The fully trusted solution runs through the permission set of the host process, while the bin/CAS solution is restricted by the CAS policy specified by web. config.
• Function. A fully trusted solution has no functional limitations. You cannot deploy timer jobs, event receivers, service applications, or workflows using the bin/CAS solution because these components need to deploy the assembly to the Global Assembly Cache.
• Core issues. The Farm solution cannot be deployed in each SharePoint environment, especially in hosted or centrally managed environments. This is an important issue when developing third-party components because creating a farm solution limits the number of solutions that can use your components. The on-site solution is not monitored or restricted by resources. Make sure that the solution does not affect stability or security in a wider SharePoint environment.

It should be emphasized that Microsoft no longer recommends using the bin/CAS model method. Only when the field solution and sandbox solution that are fully trusted cannot meet your requirements, to consider using the bin/CAS model method, that is, taking it as a last resort option.

Ii. Sandbox Solutions

Like any ASP. NET application, the field solution runs in the IIS working process, while the sandbox solution runs in the execution environment with special restrictions. This is important to prevent unauthorized or poorly performing code from slowing down the application pool or causing the application pool to crash. As a result, Sharepoint imposes limits on the code that can be executed in the sandbox solution. As a key part of the implementation of this system, the sandbox solution must run in the special sandbox Worker Process (spucworkerprocess.exe.

When a request attempts to access the sandbox solution, the SharePoint execution manager running in the IIS Working Process searches for the sandbox solution code and runs the sandbox Working Process in it (if no sandbox working process is running, starts a sandbox working process ). Generally, you can start the sandbox Worker Process on any server on the server farm that runs the SharePoint Foundation sandbox Code Service (spuchostservice.exe. In the windows "service" dialog box, it is called the "SharePoint 2010 user code host" service.

The server that runs the SharePoint Foundation sandbox code service can be (but not necessarily) the front-end web server that runs the IIS workflow. You can configure the server to be used in the Management Center application: the administrator can choose to run each sandbox process in "Local Mode, this means that each request to the sandbox solution will be processed on the same front-end web server that runs the IIS working process; or, the administrator can ask the execution manager to start each sandbox Process in "remote mode" (sometimes called "similarity mode. In the latter mode, the execution manager searches for the server that runs the SharePoint Foundation sandbox code service, the server has created an application domain for the same sandbox solution in its spucworkerprocess.exe process. (If another user in another website set has previously requested the same sandbox solution, this will happen ). If a matched application domain exists, the request is sent to the same application domain for processing. If any server running the SharePoint Foundation sandbox Code Service does not have an application domain for the sandbox solution, the execution manager allocates requests to the most idle servers on these servers. Then, the server creates the required application domains and processes requests for the sandbox solution. No matter whether the local mode or similarity mode is used, the application domains in the sandbox worker process will remain active after processing the requests, if there are other requests for the same sandbox solution, the application domain will be reused.

All sandbox solutions processed by the given server run in the same sandbox worker process. Each sandbox solution obtains its own application domain in a general process. The SharePoint Foundation sandbox code service runs under the server farm account.

When you access the sandbox solution for the first time (for example, a user accesses a page that contains a Web part defined in the sandbox solution ), the Assembly where the sandbox solution is located will be unwrapped and copied to the file system of the server responsible for processing the sandbox solution. The default file system directory is C: \ programdata \ Microsoft \ SharePoint \ uccache. the directory location can be modified through the configuration file. Note that this copy process is not completed by the working process running the sandbox solution, because the working process does not have the permission to operate the file system. Therefore, the copy process is completed by the user code host service. This directory is shown in the following figure:

The Sandbox assembly does not stay in uccache. When the session related to the Assembly that the user accesses the sandbox scheme ends, the assembly of this program will be retained for a short time in uccache, if another request comes, it will be loaded again. If no more requests come to access the cluster, the system determines whether the Assembly is removed from the uccache based on an algorithm (whether the server is busy or how long the last access has been completed. If another user accesses the sandbox solution after the removal, the previous operation is re-performed, namely, unpacking, copying and running ..........

It should be noted that no operations (add, remove, or load) on the uccache are permitted for administrators, developers, or third-party code ), only the SharePoint infrastructure itself has the right to access and operate the uccache.

Reprinted: http://www.cnblogs.com/wsdj-ITtech/archive/2012/11/16/2544201.html