Создание инфраструктуры SharePoint - Архитектура SharePoint

 

Архитектура SharePoint

Применительно к SharePoint полезно подумать о технологии с точки зрения системного архитектора. Вам не нужно знать все мельчайшие детали, но если вы знакомы с общими зависимостями архитектуры SharePoint, вы будете быстрее находить нужные решения, так как сможете заранее определять, что необходимо настроить и почему.
SharePoint – это технология для подготовки веб-приложений и узлов. Это решение для веб-узлов на основе IIS, интегрированное с IIS посредством ASP.NET и использующее серверную часть базы данных SQL Server для хранения данных настройки и содержимого. Вкратце, SharePoint сочетает три различные архитектуры (IIS, .NET и SQL Server), как показано на рис. 1.

 

Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0

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

Как показано на рисунке, SharePoint полагается на службы IIS и платформу ASP.NET для обработки запросов и ответов HTTP. Стандартные компоненты служб IIS, такие как драйвер HTTP режима ядра (http.sys) и рабочий процесс (w3wp.exe), выполняют первоначальную постановку в очередь и маршрутизацию запросов, пока они не поступают фильтру ISAPI платформы ASP.NET (aspnet_isapi.dll). При установке .NET Framework библиотека aspnet_isapi.dll регистрируется в метабазе служб IIS (C:\Windows\System32\Inetsrv\metabase.xml) следующим образом:

InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"

После загрузки службами IIS фильтра ISAPI платформы ASP.NET все входящие запросы для веб-узла могут быть переданы платформе ASP.NET, что важно, поскольку SharePoint необходимо в конечном счете получить эти запросы через платформу ASP.NET. Для этого SharePoint расширяет настройку выбранного веб-узла the путем добавления сопоставления с подстановочными символами для приложений, маршрутизирующего все входящие запросы независимо от расширения имени файла к фильтру ISAPI платформы ASP.NET.

Это можно увидеть в диспетчере служб IIS после установки WSS 3.0 при выборе базовой установки. Программа установки WSS отключает существующий веб-узел IIS по умолчанию на сервере и создает новый веб-узел по умолчанию для порта 80 с определенным сопоставлением с подстановочными символами для приложений ASP.NET, как показано на рис. 2.

 

Figure 2 Wildcard application map for ASP.NET ISAPI filter

Чтобы платформа ASP.NET в свою очередь передавала запросы серверу SharePoint, SharePoint должен расширить конвейер обработки запросов HTTP посредством настраиваемого объекта HttpApplication, реализуемого с помощью класса SPHttpApplication сборки Microsoft.SharePoint. SharePoint определяет этот настраиваемый объект приложения в файле приложения ASP.NET (global.asax), который находится в корневой папке расширенных с помощью SharePoint веб-узлов в файловой системе. Ниже приведено содержимое такого файла global.asax:

<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>

Платформа ASP.NET динамически обрабатывает и компилирует этот файл для создания экземпляра объекта приложения SharePoint.

Для каждого полученного запроса платформа ASP.NET запускает серию событий, которые может обработать веб-приложение, таких как BeginRequest, AuthenticateRequest, ProcessRequest и EndRequest. Подробная информация об обработке ошибок выходит за рамки развертывания и управления SharePoint, хотя важно знать, что помимо класса SPHttpApplication, указанного в файле global.asax, SharePoint также реализует настраиваемые обработчики данных и модули HTTP, определенные в файле web.config для узла. Например, SharePoint использует модуль HTTP на основе класса SPRequestModule, зарегистрированноый в качестве первого модуля HTTP до стандартных модулей ASP.NET. SPRequestModule инициализирует среду выполнения SharePoint путем регистрации компонента SPVirtualPathProvider в ASP.NET. Модуль SPRequestModule предназначен для внутреннего использования SharePoint, но разработчики решений SharePoint могут изменить файл web.config для регистрации дополнительных компонентов, таких как настраиваемые обработчики данных и модули HTTP. Настраиваемые и стандартные модули HTTP позволяют SharePoint использовать преимущества ASP.NET, сохраняя жесткий контроль над всеми запросами к приложениям SharePoint.

Имейте в виду, что при создании веб-приложения с помощью узла центра администрирования SharePoint 3.0 службы WSS добавляют к выбранному веб-узлу IIS сопоставление с подстановочными символами для приложений ASP.NET и создает в корневой папке веб-узла файлы global.asax и web.config. Каждое веб-приложение использует собственный набор файлов global.asax и web.config высокого уровня.

Для обработки запросов и возврата обозревателям значимых данных WSS 3.0 и MOSS 2007 используют стандартный анализатор страниц ASP.NET, который компилирует запрошенные страницы ASP.NET или обрабатывает их в режиме без компиляции. Но страницы ASP.NET, передаваемые службами SharePoint анализатору ASP.NET, не обязательно находятся там, где кажется. Например, файл default.aspx не удастся найти в корневой папке расширенного с помощью SharePoint веб-узла, такого как узла центра администрирования SharePoint 3.0, хотя файл default.aspx открывается при отображении домашней страницы этого веб-узла. Именно компонент SPVirtualPathProvider виртуализируюет среду путем загрузки содержимого страницы из локальной файловой системы или базы данных содержимого SQL Server и его передачи анализатору страницы ASP.NET в качестве виртуального файла. Для узла центра администрирования SharePoint загружает файл default.aspx из папки C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin.

Домашняя страница, также как и большинство других страниц узлов SharePoint, связана с главной страницей ASP.NET (default.master), реализующей общий макет для меню и элементов управления переходами. Страница Default.master находится в папке C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global и имеет в своем составе именованные заглушки для других страниц содержимого в локальной файловой системе или базе данных содержимого SQL Server. Ключевой момент заключается в том, что при открытии узла SharePoint в веб-обозревателе на самом деле отображается информация коллекции страниц содержимого, которые могут быть размещены не на локальном веб-сервере и упорядочены в соответствии с макетом, определенным главной страницей.

Как правило, неизмененные страницы (или неиндивидуализированные страницы в терминологии SharePoint) являются шаблонами страниц локальной файловой системы каждого сервера SharePoint, а индивидуализированные страницы записаны в базе данных содержимого, чтобы для всех серверов SharePoint веб-фермы был доступен один и тот же набор страниц (см. рис. 3). Предполагается, что неиндивидуализированные страницы являются одинаковыми на всех серверах и узлах в веб-ферме. Однако при индивидуализации страниц содержимого или главной страницы узла SharePoint, возможно, с помощью Office SharePoint Designer 2007, SharePoint автоматически сохраняет индивидуализированные страницы в базе данных содержимого.

 

Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application

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

Все серверы WSS в веб-ферме используют одну базу данных настройки для хранения общих метаданных, параметров настройки и сведений обо всех веб-узлах IIS веб-фермы, расширенных с помощью SharePoint. Отдельные веб-приложения, напротив, могут быть связаны с одной или несколькими базами данных содержимого (хотя отдельная база данных содержимого может быть связана только с одним веб-приложением).

Взаимосвязь между веб-узлами IIS, веб-приложениями, семействами узлов и базами данных содержимого может казаться запутанной. В терминологии SharePoint «веб-приложение» – это веб-узел IIS, расширенный с помощью SharePoint. В составе веб-приложения может быть несколько семейств веб-узлов, в составе каждого из которых опять же может быть узел верхнего уровня и узлы подуровней, использующие одни параметры настройки.

Помимо прочего, создание нескольких семейств узлов позволяет делегировать администрирование семейством узлов различным пользователям и группам. В составе одного семейства узлов не может быть несколько баз данных содержимого, но веб-приложение может использовать несколько таких баз данных для увеличения масштабируемости и снижения отрицательного воздействия на производительность большого узла, выполняющего значительный объем операций с базой данных на других узлах SharePoint. Однако размещение всех узлов SharePoint в отдельных семействах узлов – не лучший вариант, поскольку подобное развертывание ограничивает межузловую функциональность.
WSS 3.0 не поддерживает контекстный поиск по нескольким семействам узлов. Для такого поиска необходим MOSS 2007 или Microsoft Search Server 2008. Например, можно создать веб-приложение и узел верхнего уровня для http://contoso, а администратор семейства узлов затем может создать узлы подуровней, используя пользовательский интерфейс SharePoint, например, http://contoso/info и http://contoso/events. Все эти узлы находятся в одной базе данных содержимого, поскольку принадлежат одному семейству узлов.

Вы, как администратор фермы, также можете использовать управляемый путь, такой как /sites, а затем определить дополнительные семейства узлов, например, http://contoso/sites/IT и http://contoso/sites/HR, в центре администрирования SharePoint 3.0. У этих трех семейств узлов (http://contoso, http://contoso/sites/IT и http://contoso/sites/HR) могут быть различные администраторы, параметры настройки и базы данных содержимого, но доступ к ним осуществляется через один веб-узел IIS (http://contoso), и все три семейства используют одно удостоверение пула приложений веб-приложения.

Конечно, существует гораздо больше деталей, но эта взаимосвязь IIS, ASP.NET и SQL Server особенно важна для понимания успешной работы со SharePoint. Тем, кто хочет поближе познакомиться с архитектурой SharePoint, я рекомендую статью Теда Паттинсона в журнале MSDN® Magazine, озаглавленную «Значительные улучшения служб SharePoint Services для разработчика» и доступную по адресу msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview.