Основы проектирования корпоративных систем - Сергей Зыков

Естественно, для разработчиков, которые приняли решение интегрировать свои компоненты, свои надстройки над Office в стандартную среду Office System 2003, эта новая модель, в том числе и с точки зрения обеспечения безопасности, является весьма удобной. До выполнения кода необходимо убедиться в том, что код признан полностью доверенным. При этом на локальном компьютере каждого пользователя корпоративной системы содержится набор правил, который определяет, какого рода операции разрешены для данного кода и какого рода код может быть исполнен. При загрузке кода языковая среда CLR собирает сведения об этом коде. Основное количество сведений относится к сборке – это версия и автор сборки, цифровая подпись, в том числе зашифрованная, алгоритм шифрования, степень доверия и политика безопасности и т. д. Кроме того, необходимо собрать сведения, относящиеся к хосту, т. е. к источнику кода. После этого сведения по сборке и по источнику соотносятся с той или иной политикой безопасности.

При этом существует четыре уровня этой политики, или четыре различных среза для политики безопасности, – Machine, User, Enterprise и Host. То есть на уровне локальной машины, на уровне пользователя, на уровне предприятия в целом и на уровне источника, например того сервера, с которого эта сборка получена по Интернет каналу. Каждая из этих четырех политик может содержать несколько групп кода – от нуля до некоторого их ограниченного количества. При этом каждая группа кода на основе сведений устанавливает тот уникальный набор прав, который включает то или иное количество разрешений, т. е. операции, допустимые в данном случае, например чтение файла с диска, запись на диск, открытие файла, коррекция и т. д. В результате, используя все собранные сведения о хосте, сборке и политике, среда выполнения соотносит сборку с кодовой группой, которая соотносит ее с матрицей прав для всех политик, для каждой из четырех политик безопасности. При этом удается достаточно четко и в то же время гибко определить, во-первых, разрешается ли выполнять этот код и, во-вторых, если разрешается, то какие именно операции допустимы для этого кода и с какими объектами. Естественно, сборки, которые используются документами Word или таблицами Excel, требуют статуса «полное доверие» – Full Trust, независимо от выбранной модели развертывания. Как правило, право на исполнение выдается определенным локациям для сборок, и после этого выбранным сборкам или наборам сборок на основе строгого, т. е. полного, имени присваивается статус доверия.

Наконец, последнее – это модель развертывания, которая реализует технологию, близкую к ClickOnce, т. е. является достаточно экономичной. По сути, в основе модели, которая применяется в VSTO 2005, лежит структурное разделение на документ, на код и на сборку. Код является частью проекта Visual Studio, а сборка – единственное, что поставляется вместе с документом. При этом сборка связана с документом, а реализация привязки осуществляется различным образом: в VSTO 2003 это делалось на основе свойств документа, в более поздней версии – 2005 – используются специализированные средства, доступные при выполнении приложений. Основных моделей развертывания – три: локальная– локальная, локальная – сетевая и сетевая – сетевая (рис. 14.3).

Если речь идет о модели локальная – локальная, то доступ к сети не требуется, необходима явная установка каждым пользователем приложения на базе Office System, а если документ обновляется, требуется физическое копирование его на каждый компьютер. Все обновления требуют установки на каждом компьютере, и пользователи каждый раз работают с локальной копией документа. Если речь идет о модели развертывания локальная – сетевая, то, как правило, загрузка документа потребует доступа к сети. Тем не менее, как и в предыдущей модели, каждый пользователь работает с локальной копией документа, и обновление документа потребует физического копирования на каждый компьютер пользователя. Однако обновление можно производить из централизованного хранилища. Если речь идет о модели сетевая – сетевая, то для распределенной работы с документом пользователям требуется доступ к сети, и для загрузки документов в том числе. Документ хранится на сервере, обновление документа требует его публикации на сервере, и пользователи работают с этим документом в режиме разделения доступа.

Рис. 14.3. Модель развертывания

При этом для корректной установки полного спектра решения VSTO 2005 на машину клиента необходимо обеспечить наличие предварительных компонентов, таких как. NET Framework (поскольку на этой базе классов реализовано VSTO), а также собственной среды исполнения для VSTO, средств поддержки интерфейсов, связанных со сборками, и необходимых обновлений для корректного функционирования офисной среды. Кроме того, поскольку речь идет о распределенной работе и о работе с компонентами, необходимо предоставить пользователям соответствующие права доступа. В том числе пользователи должны получить права на выполнение кода в сборке. Это можно обеспечить путем модификации политик безопасности. NET. Но поскольку некоторые ограничения содержатся в собственно документах, возможно, потребуется модификации политики безопасности самого документа. Здесь, как известно, осуществляется достаточно гибкая настройка уровня безопасности, поэтому интегрированную настройку нужно делать достаточно аккуратно. Наконец, нужно проверить корректность пути к тому размещению сборки, который указан в манифесте, т. е. в метаданных сборки, соответствие ее реальному местоположению. В ряде случаев, например при попытке сохранения пользователем локального документа, открытого ранее на сервере, могут возникать некорректности. Таким образом, обеспечивается реализация модели развертывания.

Для того чтобы проиллюстрировать возможности работы с данными и элементами офисных приложений в рамках технологии VSTO 2005, попробуем рассмотреть пример фрагментов программы на C#, которая осуществляет настройку меню в приложении MS Excel. Нашей задачей является создание новой строки в меню и добавление в эту строку новых элементов, а затем определение конкретных действий, которые будет осуществлять система при возникновении тех или иных событий со стороны пользователя. Желательно осуществить привязку управляемого кода, т. е. кода на C#, при нажатии пользователем кнопки на панели инструментов. В MS Office панели инструментов называются панелями команд и представляют собой общее средство для всех приложений. В данном случае наблюдается пример, связанный с MS Excel. Иногда, например при построении AddIn, возможно, имеет смысл создать собственную панель команд с дополнительными кнопками. В других случаях можно просто добавить элементы управления к уже существующей панели команд или меню. При использовании инструментария VSTO 2005 можно сделать и то и другое. То есть можно как расширить существующее меню, так и создать новое.