Архитектура изолированных решений

В этом разделе описывается архитектура системы изолированных решений в SharePoint.

Дата последнего изменения: 14 апреля 2011 г.

Применимо к: SharePoint Foundation 2010

В этой статье
Обзор
Система упаковки и установки изолированных решений
Модель обработки для изолированных решений
Выполнение кода и доступ к ресурсам в изолированном рабочем процессе
Ограничения использования ресурсов в изолированных решениях
Система раздельной визуализации страниц
Обход ограничений изолированных решений
Инфраструктура проверки решений

Доступно на сайте SharePoint Online

Приводятся описания системы упаковки, модели обработки, системы раздельной визуализации страниц, ограничений использования ресурсов, ограничений выполнения кода и доступа, а также инфраструктуры проверки решений. Подробные сведения по этим темам можно найти в других разделах на в пакета SDK Изолированные решения.

Обзор

В отличие от решения фермы, для песочницы позволяет администраторам семейства веб-сайтов устанавливать пользовательские решения в Microsoft SharePoint Foundation без привлечения администраторов более высокого уровня. Однако такая независимость ограничивает изолированные решения в плане развертывания, выполняемого кода и доступа к ресурсам.

Примечание

Иногда вместо термина "изолированный" используется термин "пользовательский", особенно в объектной модели для системы изолированных решений. Например, пространством имен с основными API-интерфейсами для системы является Microsoft.SharePoint.UserCode, а служба, управляющая выполнением изолированных решений, называется Узел пользовательского кода SharePoint 2010 в диалоговом окне Windows Службы на интерфейсных веб-серверах. (В приложении центра администрирования она называется службой изолированного кода SharePoint Foundation). Это отражает прежнее название термина, который теперь называется "изолированным решением".

Система упаковки и установки изолированных решений

Подобно решению фермы, изолированное решение упаковывается для установки в файл пакета решения (.wsp). Однако изолированные решения развертываются администратором семейства веб-сайтов не в хранилище решений фермы, а в особую коллекцию решений семейства веб-сайтов. Эта коллекция представляет собой специальный список SharePoint, поэтому она хранится в базе данных контента. Развертывание решения в коллекцию выполняется в пользовательском интерфейсе Действия сайта семейства веб-сайтов или с помощью SharePoint. Дополнительные сведения о процессе установки изолированных решений см. в статье Установка, удаление и обновление изолированных решений.

Изолированные решения могут содержать не все виды элементов, а также ограничены в плане их развертывания. Наиболее примечательно то, что из изолированных решений не могут выполняться развертывания в файловую систему серверов. Из этого ограничения вытекают следующие последствия:

• С помощью изолированного решения не могут развертываться страницы приложения, пользовательские элементы управления (файлы .ascx) и файлы ресурсов локализации (.resx). (Однако существуют другие способы локализации изолированных решений. Дополнительные сведения см. в статье Локализация изолированных решений).

• Изображения, файлы скриптов и компоненты в изолированных решениях развертываются в базу данных контента, а не в файловую систему интерфейсных серверов.

• В изолированных решениях не могут развертываться определения сайтов. (Но могут развертываться функционально эквивалентные им веб-шаблоны. Дополнительные сведения см. в статье How to: Deploy a Web Template in a Sandboxed Solution.

• Сборки в изолированных решениях также развертываются в базу данных контента, хотя при использовании они временно кэшируются в файловой системе сервера, обрабатывающего запрос. Дополнительные сведения см. в статье Где развертываются сборки изолированных решений?.

Более полное описание элементов, которые могут развертываться в изолированном решении, см. в статье Что можно реализовать в изолированном решении.

Изолированное решение также не может получить доступ к элементам, находящимся вне семейства веб-сайтов, в котором оно развернуто. Поэтому областью действия компонентов, развернутых в изолированных решениях, может быть только семейство веб-сайтов или веб-сайт.

Модель обработки для изолированных решений

SharePoint — это приложение ASP.NET и, как для любого приложения ASP.NET, при получении HTTP-запроса интерфейсным веб-сервером специальный драйвер, HTTP.SYS, обнаруживает запрос и перенаправляет его в пул приложений, который обрабатывает запросы для целевого веб-сайта IIS, и, следовательно, для целевого веб-приложения SharePoint. Каждый пул приложений имеет рабочий процесс IIS (w3wp.exe), в котором выполняется конвейер запросов для каждого запроса. (Дополнительные сведения о рабочих процессах IIS 7.0 и пулах приложений см. в статье, посвященной введению в архитектуру IIS 7 (Возможно, на английском языке)). На сервере SharePoint рабочий процесс IIS выполняется в учетной записи пула приложений. Обычно это учетная запись фермы и, следовательно, процесс имеет разрешения на чтение и запись для ресурсов SharePoint. В ферме с несколькими серверами учетная запись фермы обычно является пользователем домена. Это та же учетная запись, которая получает доступ к базам данных контента. Служба таймера SharePoint 2010 выполняется в контексте той же учетной записи.

Решения фермы выполняются в рабочем процессе IIS так же, как и любое приложение ASP.NET. Однако изолированные решения выполняются в специально ограниченной среде выполнения. Это необходимо для предотвращения замедления или сбоя работы пула приложений в случае выполнения незаконного или несовершенного кода. Таким образом, SharePoint накладывает ограничения на действия кода в изолированном решении. Критически важной частью реализации этой системы является то, что изолированные решения должны выполняться в специальном изолированном рабочем процессе (SPUCWorkerProcess.exe).

Когда запрос пытается обратиться к изолированному решению, диспетчер выполнения SharePoint, работающий в рабочем процессе IIS, находит изолированный рабочий процесс (или запускает его, если ни один не выполняется), в котором будет выполняться код изолированного решения. Как правило, этот изолированный рабочий процесс может быть запущен на любом сервере фермы, на котором выполняется служба изолированного кода SharePoint Foundation (SPUCHostService.exe). В диалоговом окне Windows Службы она называется службой узла пользовательского кода SharePoint 2010.

Сервер, на котором выполняется служба изолированного кода SharePoint Foundation, может быть (но необязательно) интерфейсным веб-сервером, на котором выполняется рабочий процесс IIS. Используемый сервер можно задать в приложении центра администрирования: администраторы могут выбрать выполнение всех изолированных процессов в "локальном режиме", при котором все запросы изолированного решения обрабатываются на том же интерфейсном веб-сервере, на котором выполняется рабочий процесс IIS, или выбрать запуск каждого изолированного процесса диспетчером выполнения в "удаленном режиме", который иногда называют "режимом сходства". В этом режиме диспетчер выполнения осуществляет поиск сервера, на котором работает служба изолированного кода SharePoint Foundation и который уже создал в своем процессе SPUCWorkerProcess.exe домен приложения для такого же изолированного решения. (Это возможно в случае, когда это же изолированное решение уже запрашивалось ранее, например, другим пользователем в другом семействе веб-сайтов). Если соответствующий домен приложения существует, запрос будет отправлен на обработку в этот домен. Если ни на одном сервере со службой изолированного кода SharePoint Foundation нет домена приложения для изолированного решения, диспетчер выполнения назначит запрос наименее занятому из этих серверов. После этого сервер создаст необходимый домен приложения и обработает запрос изолированного решения. Независимо от используемого режима ("локального" или "сходства") домен приложения в изолированном рабочем процессе остается активным после обработки запроса и используется повторно при получении другого запроса для того же изолированного решения.

Все изолированные решения, обрабатываемые одним сервером, выполняются в одном изолированном рабочем процессе. Каждое изолированное решение получает собственный домен приложения в рамках общего процесса. Служба изолированного кода SharePoint Foundation выполняется в учетной записи фермы.

Выполнение кода и доступ к ресурсам в изолированном рабочем процессе

К всему коду, выполняемому в изолированном рабочем процессе, применяются ограничения на выполнение и доступ. Существует две системы ограничений: одна применяется только к вызовам из кода изолированных решений основной сборки SharePoint Foundation, Microsoft.SharePoint.dll. Другая применяется ко всем остальным вызовам, включая вызовы других сборок SharePoint и сборок .NET Framework. В этой статье первая система называется ограничениями серверной объектной модели, а вторая — общими ограничениями. (Также существуют различные ограничения, обусловленные системой раздельной визуализации страниц, используемой в изолированных решениях. Дополнительные сведения см. в разделе Система раздельной визуализации страниц далее в этой статье).

Примечание
Эти две системы являются взаимоисключающими: общие ограничения не применяются к вызовам сборки Microsoft.SharePoint.dll.

Общие ограничения накладываются двумя механизмами:

1. Запрещающая политика разграничения доступа кода (CAS) накладывает ограничения на действия кода в изолированном рабочем процессе. Эта политика определяется в файле wss_usercode.config в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG и на нее ссылается файл web.config в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. (Изменение этого файла не поддерживается). Политика CAS накладывает следующие ограничения:

   • Код изолированного решения не может вызывать неуправляемый код.

   • Код изолированного решения не может вызывать интерфейсы API Reflection Microsoft .NET Framework 3.5.

   • Код изолированного решения может вызывать только те сборки .NET Framework 3.5, которые имеют атрибут AllowPartiallyTrustedCallersAttribute. Это блокирует доступ примерно к 2/3 интерфейсов API .NET Framework 3.5, в том числе, например, к System.Printing. У некоторых сборок SharePoint также нет этого атрибута. Списки сборок .NET Framework, имеющих и не имеющих этот атрибут, см. в статье Сведения о доступности сборок .NET из изолированных решений. Списки сборок SharePoint, имеющих и не имеющих этот атрибут, см. в статье Доступные и недоступные сборки SharePoint из изолированных решений.

   Примечание
   Политика CAS делает исключение для сборок Microsoft Office со строгим именем. Таким сборкам предоставляются разрешения уровня "Полное доверие".

   Дополнительные сведения о политике CAS и ее следствиях см. в статье Ограничения для изолированных решений.

2. Во-вторых, изолированный рабочий процесс имеет маркер безопасности с низкими привилегиями.

   • Маркер не дает процессу право на чтение или запись в файловую систему.

   • Маркер не дает процессу право на вызов сети. Поэтому изолированный рабочий процесс может получить доступ только к ресурсам, доступным на сервере, на котором он выполняется. Например, нельзя получить доступ к внешней базе данных.

   • Маркер не дает процессу право на запись в реестр.

   • Маркер не дает право на вызов сборки, которая не находится в глобальном кэше сборок, даже если она имеет атрибут AllowPartiallyTrustedCallersAttribute и в противном случае могла бы вызываться из изолированного рабочего процесса.

Следует помнить, что эти ограничения не применяются к вызовам интерфейсов API в сборке Microsoft.SharePoint.dll. Так, например, вызов GetLocalizedString может выполнять чтение из файлов ресурсов в файловой системе, а вызовы объектов SPList могут выполнять чтение и запись в базу данных контента, независимо от того, на каком сервере она находится. (Однако файл не может быть развернут на диск в изолированном решении, поэтому файл .resx должен быть установлен отдельно как решение фермы).

Главное ограничение в системе ограничений серверной объектной модели заключается в том, что из изолированного решения может вызываться только подмножество интерфейсов API сборки Microsoft.SharePoint.dll. Вызов запрещенного API приводит к исключению (которое перехватывается и отображается для пользователя в виде ошибки).

Ниже приведены некоторые ограничения объектной модели SharePoint, к которой можно получить доступ:

• Класс SPWebApplication недоступен. Среди прочего это означает, что изолированное решение не может получить доступ к элементам, находящимся вне семейства веб-сайтов, в котором оно размещается.

• Недоступны почти все классы в пространстве имен Microsoft.SharePoint.WebControls, т. е. изолированное решение не может использовать большинство элементов управления ASP.NET.

Полный список классов Microsoft.SharePoint.dll, которые доступны для изолированных решений, см. в статье Программные интерфейсы Microsoft.SharePoint.dll, доступные из изолированных решений.

Реализация этого ограничения выполняется парой специально ограниченных версий сборки Microsoft.SharePoint.dll, называемых сборками оболочки, которые расположены в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies. Основное отличие этих версий от стандартной сборки Microsoft.SharePoint.dll заключается в том, что они содержат только подмножество классов и членов стандартной версии.

Одна из двух сборок оболочки загружается изолированным рабочим процессом. Другая загружается в специальный процесс прокси (SPUCWorkerProcessProxy.exe), который выполняется в режиме полного доверия и управляется службой изолированного кода SharePoint Foundation. Стандартная сборка Microsoft.SharePoint.dll также загружается в этот процесс прокси.

Основной задачей сборок оболочки является фильтрация запрещенных классов и членов SharePoint. Вызов Microsoft.SharePoint.dll из кода изолированного рабочего процесса перенаправляется в сборку оболочки. Если вызываемого интерфейса API нет в сборке оболочки, возникает исключение (которое перехватывается и отображается для пользователя в виде ошибки).

Когда изолированное решение вызывает допустимый интерфейс API, который содержится в сборках оболочки, первая сборка оболочки передает его второй сборке в процесс прокси с полным доверием, которая в свою очередь передает его стандартной сборке Microsoft.SharePoint.dll. Возвращаемые результаты передаются обратно в исходный вызывающий код. Это взаимодействие между процессами возможно благодаря удаленному взаимодействию .NET. Изолированный рабочий процесс и процесс прокси с полным доверием всегда запускаются вместе и действуют в паре. При сбое одного из них второй также останавливается.

В системе ограничений серверной объектной модели существует дополнительное ограничение, которое также обеспечивается сборками оболочки. Некоторые интерфейсы API SharePoint могут быть вызваны из изолированных решений, но только со специальными ограничениями на передаваемые им параметры. Эти входные ограничения обеспечивают сборки оболочки, которые гарантируют, что при их нарушении произойдет исключение. Единственным случаем такого ограничения в SharePoint Foundation 2010 являются конструкторы SPSite(String) и SPSite(Guid). Эти конструкторы доступны для изолированных решений, но им могут передаваться только URL-адреса или идентификаторы GUID, которые ссылаются на семейство веб-сайтов, в котором установлено изолированное решение.

Примечание
Это происходит потому, что вторая сборка оболочки и стандартная сборка Microsoft.SharePoint.dll выполняются в процессе с полным доверием, к которому не применяются общие ограничения. Эти ограничения применяются в изолированном рабочем процессе.

Важно!
Стадия развертывания изолированного решения сама выполняется в изолированном рабочем процессе и подлежит таким же ограничениям выполнения. Например, при развертывании изолированного решения невозможно развернуть файл на диск. Это основная причина, по которой пользовательский элемент управления (файл ASCX) не может быть изолированным решением.

На рис. 1 показана обработка HTTP-запроса при обращении к изолированному решению.

Рис. 1. Модель обработки запросов для изолированных решений

Файлы SPUCHostService.exe, SPUCWorkerProcess.exe и SPUCWorkerProcessProxy.exe находятся в папке %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode.

Ограничения использования ресурсов в изолированных решениях

На изолированные решения накладываются три вида ограничений использования ресурсов, которые можно классифицировать по (1) видам сущностей, к которым относится ограничение, и (2) видам сущностей, на которые накладывается штраф за превышение ограничения.

• На запрос с штрафом запроса: существует жесткое ограничение времени выполнения изолированного решения. По умолчанию это 30 секунд. Если изолированное решение превышает это ограничение, то запрос (но не изолированный рабочий процесс) завершается. (Это ограничение можно настроить, но только посредством пользовательского кода относительно объектной модели. Существенные части объектной модели недоступны для изолированных решений, поэтому ни одно изолированное решение не может изменить это ограничение).

• На запрос с штрафом процесса: существует набор из 15 дополнительных ограничений ресурсов, которые применяются к запросам. Если запрос нарушает одно из них, то процесс (и все выполняемые в нем изолированные решения) завершается.

• На день/на семейство веб-сайтов с штрафом семейства веб-сайтов: для каждого семейства веб-сайтов можно настроить максимальное количество ежедневных "пунктов ресурсов". Эти пункты суммируются на основе алгоритма, который учитывает использование ресурсов в 15 категориях изолированными решениями, установленными в семействе веб-сайтов. Если семейство веб-сайтов превышает максимальное количество разрешенных для него пунктов, все изолированные решения семейства веб-сайтов завершаются и больше не могут выполняться до конца дня.

Дополнительные сведения об ограничениях ресурсов, накладываемых на изолированные решения, см. в статье Ограничения на использование ресурсов для изолированных решений.

Система раздельной визуализации страниц

Когда клиентский компьютер запрашивает страницу SharePoint, которая содержит компонент из изолированного решения, например, развернутую в изолированном решении веб-часть, SharePoint визуализирует несколько объектов страницы. Один визуализируется в рабочем процессе Microsoft ASP.NET (w3wp.exe), а остальные — в изолированном рабочем процессе. Все неизолированные компоненты визуализируются на странице в рабочем процессе ASP.NET, а первый изолированный компонент — в объекте страницы в изолированном рабочем процессе. Когда страница в изолированном рабочем процессе полностью визуализируется, она объединяется с объектом страницы в процессе ASP.NET. Если на запрошенной пользователем странице имеется несколько изолированных компонентов, каждый из них визуализируется по отдельности в собственном объекте страницы в изолированном рабочем процессе. Все эти объекты страницы последовательно объединяются с объектом страницы в процессе ASP.NET.

Побочным эффектом этой системы является наложение нескольких дополнительных ограничений на действия изолированного решения. Дополнительные сведения об этих ограничениях см. в статье Ограничения для изолированных решений.

Обход ограничений изолированных решений

Существует два основных способа обхода изолированными решениями обычных ограничений. Наиболее существенным является использование клиентского кода для доступа к ресурсам, которые недоступны из серверного кода в изолированном решении. Например, изолированное решение может содержать пользовательскую страницу сайта с кодом JavaScript, который вызывает клиентскую объектную модель JavaScript SharePoint. Кроме того, изолированное решение может содержать веб-часть, которая размещает приложение Microsoft Silverlight. Это приложение может вызывать клиентскую объектную модель Silverlight SharePoint. Ни одно из ограничений изолированных решений не применяется к клиентскому коду. Не существует ни ограничений выполнения кода, ни ограничений доступа к ресурсам, ни ограничений использования ресурсов. Дополнительные сведения см. в статье How to: Extend the Power of a Sandboxed Solution with the SharePoint Client Object Model.

Архитектура изолированных решений также позволяет использовать технологию, с помощью которой изолированное решение может вызывать пользовательские операции, выполняемые в режиме полного доверия. Для использования этой технологии необходимо разработать решение фермы, содержащее один или несколько классов, производных от SPProxyOperation. Каждый из этих классов определяет операцию, которая будет выполняться в режиме полного доверия и может вызываться из изолированных решений с помощью метода ExecuteRegisteredProxyOperation. Точнее, эти операции прокси с полным доверием выполняются в том же процессе прокси (SPUCWorkerProcessProxy.exe), в котором выполняется стандартная сборка Microsoft.SharePoint.dll. Операции прокси могут возвращать данные в изолированное решение.

На рис. 2 показана обработка запроса, обратившегося к изолированному решению, когда изолированное решение вызывает прокси с полным доверием.

Рис. 2. Модель обработки запроса, когда изолированное решение вызывает прокси с полным доверием

Предыдущее описание могло создать впечатление, что с помощью этой технологии решения фермы и изолированные решения всегда разрабатываются совместно одной группой разработки. На самом деле, решение фермы, содержащее классы операций прокси, может разрабатываться специально для предоставления определенных операций любым изолированным решениям, которым они необходимы, в том числе изолированным решениям, разработанным другими группами. Например, поскольку изолированное решение не может выполнять запись в журналы ULS SharePoint, может быть весьма полезным решение фермы, открывающее операции ведения журналов прокси для изолированных решений.

Дополнительные сведения о разработке и вызове операций прокси с полным доверием см. в разделе Sandboxed Solutions in Partnership with Full-Trust Proxies in SharePoint 2010 и в других разделах того же узла.

Инфраструктура проверки решений

SharePoint предоставляет инфраструктуру проверки решений, которую можно использовать для разработки пользовательских средств проверки решений, например, средства проверки подписи решения определенным сертификатом. Средства проверки в семействе веб-сайтов выполняются при активации изолированных решений. Активация недопустимого решения блокируется. После обновления или добавления нового средства проверки каждое активированное решение проверяется повторно при следующем выполнении. Недопустимые решения деактивируются. Дополнительные сведения о разработке пользовательских средств проверки см. в статье Solution Validation System.