Обеспечение синхронизации и доступности для многопоточных приложений

Стандартным решением COM в области многопоточности является применение так называемых апартаментов и концепции "потоковой модели класса". Апартаменты группируют объекты, которые разделяют одни и те же требования к многопоточности. Выделяют одно и многопоточные апартаменты. В однопоточных апартаментах (STA) может выполнятся только один поток, а в многопоточных (MTA) могут параллельно выполняться несколько потоков. В обязанности сервера входит определение типа апартаментов, в котором может выполняться объект. Применение STA приводит к упорядочиванию обращения к любому объекту, размещенному в ней, за счет использования очереди сообщений Windows. При этом параллельного доступа, а значит и параллельность выполнения потоков теряются. При этом клиент из одного потока одного апартамента может обращаться к объекту из другого потока другого апартамента. Это обращение реализуется посредством прокси, который упорядочивает обращения к объекту за счет блокировки параллельных обращений.

Модель потоков MTA не предпринимает никаких действий по упорядочиванию доступа. Еще одна модель потоков "Both" позволяет создать COM-объект в любом апартамента. При этом клиент их STA может вызвать объект непосредственно, без прокси. Следовательно в двух последних случаях, код реализующий методы класса должен быть безопасным с точки зрения параллельности обращений. Таким образом, выигрыш в производительности достигается за счет потенциальной потери безопасности. Еще одной слабой стороной использования апартаментов MTA и STA является снижение производительности за счет того, что вызов пришедший извне вызовет обмен потоков.

В COM+ предложены так называемые нейтральные апартаменты, применение которых который не вызывает обмен потоков. Объект в нейтральном апартаменте всегда работает в потоке, вызвавшем его. Нейтральные апартаменты не обеспечивают поддержки синхронизации, обеспечивая возможность работы механизма синхронизации основанного на активности и не привносящего накладных расходов. Активность предоставляет собой абстракцию, обозначающую группу контекстов, в которой не разрешена параллельная работа. Для определения защиты объекта системой времени выполнения COM+ при параллельных вычислениях в нем должен быть объявлен атрибут синхронизации. защита будет выполнена облегченным перехватчиком, вместо переключения потоков. Таким образом, уменьшение производительности может произойти только, если возможен одновременный безопасный доступ разных клиентов к разным частям объекта. Проведенный анализ показывает, что концептуально стандартные решения COM/COM+ для обеспечения многопоточности, достаточно хорошо продуманы и просты в реализации. Вместе с тем их реализация в некоторых случаях может серьезно уменьшить эффективность функционирования приложения.

Обеспечение доступности вычислительных ресурсов при увеличении масштаба приложения

Возможность масштабирования является один из важнейших вопросов при разработке приложений уровня предприятия или приложений предназначенных для использования в глобальных сетях есть. Практический опыт разработки прикладных программ, а также анализ [] позволил построить, представленную на рис. 2, структуру направленийобеспечения доступности вычислительных ресурсов, связанных с увеличением масштабов приложения COM+. Наиболее простым путем увеличения масштабируемости является уменьшение нагрузки на сервер COM. Кроме рассмотренного выше пула подключений для этого используется активизация по необходимости. Применение активизации по необходимости позволяет клиенту поддерживать ссылки на объект, который деактивирован или даже удален сервером. Когда клиент вызывает метод с применением этой ссылки, сервер создает или активирует этот объект. Таким образом, экономятся ресурсы сервера на хранение объектов. Еще одно решение заключается в применении пула экземпляров объектов. Решение целесообразно в случае, если активизация по необходимости требует высоких накладных расходов на создание и инициализацию объектов. Однако такое решение накладывает существенные требования к программной реализации объекта - отсутствие запоминания состояния, отсутствие привязки к потоку и не возможностью автоматизации работы с транзакциями.

Такие возможности COM+ по увеличению масштабируемости как активизация по необходимости, пул подключений и пул объектов позволяют несколько уменьшить нагрузку на вычислительные мощности компьютерной системы, но не являются решением для общего случая. Выходом из сложившейся ситуации может стать применение кластеризации, т.е. распределение нагрузки между несколькими узлами - кластерами. Отметим, что технология DCOM позволяет распределить нагрузку между несколькими серверами, без привлечения дополнительного программного обеспечения, за счет назначения различным клиентам разных серверов. Однако такое решение является слишком трудным с точки зрения администрирования. Microsoft предлагает несколько программных продуктов, связанных с применением технологий COM/DCOM/COM+, в области кластеризации. Одним из них является Component Load Balancing (CLB), предназначенный для прозрачного с точки зрения клиента, распределения баланса загрузки между серверами COM+.

Рис. 2 Структура направленийувеличения масштаба приложений COM+

Принцип действия сервера CLB заключается в определении какой из серверов COM+ наименее загружен и передачи ему запроса, пришедшего на обработку. Суть алгоритма определения загрузки сводится к тому, что CLB периодически опрашивает серверы приложений и строит список, упорядоченный по их времени отклика. После этого направляет запрос на выполнение очередному серверу из списка. Практика показывает, что кроме балансировки нагрузки CLB позволяет обеспечить защиту приложений от сбоев. Однако его применение вызывает некоторые трудности.

Приложения, которые предназначены для использования в системах с балансировкой загрузки, должны быть оптимизированы по критерию размера заданий. В случае использования очень больших заданий сложно обеспечить требуемый уровень распределенной работы, а при очень маленьких балансировка сопровождается большими накладными расходами по их маршрутиризации. Также следует учитывать, что сервер CLB не позволяет запомнить компонентам COM+ свое состояние. Поэтому компонент не должен быть привязан к определенному компьютеру, логика программы должна быть способна обрабатывать перемещение объекта, состояние объекта не должно храниться во временном файле на сервере приложения. Кроме этого, из-за того, что пул объектов храниться на конкретном компьютере, его использовать становиться не возможным. Отметим, что указанные программные особенности во многих случаях могут серьезно усложнить разработку COM+ компонентов. В табл.1 представлены основные достоинства и недостатки рассмотренных путей увеличения масштабов приложеий COM+.

Табл.1

Оценка путей увеличения масштабов приложений COM+

Направление	Достоинства	Недостатки
Уменьшение нагрузки на сервер приложений
Активизация по необходимости	Низкие накладные расходы при хранении ссылок не используемые объекты.	Ограниченность масштаба. Дополнительные расходы на создание объектов.
Использование пула подключений	Низкие накладные расходы на создание использовавшегося соединения	Ограниченность масштаба. Дополнительные расходы на запоминание подключения.
Использование пула объектов	Низкие накладные расходы на создание объектов.	Дополнительные расходы на хранение ссылок на не используемые объекты. Сложность программной реализации. Ограниченность масштаба.
Балансировка нагрузки между несколькими серверами приложений
Назначение клиентам определенных серверов	Не ограниченный масштаб. Отсутствие дополнительного программного обеспечения	Сложность администрирования.
Использование сервера CLB	Не ограниченный масштаб. Защита от сбоев в сети. Поддержка распределенных транзакций.	Сложная программная реализация приложений.

Проблемы безопасности связанные с программными ошибками и наличием "троянских коней"

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

В первую очередь необходимо отметить возможность исчерпания вычислительных ресурсов сервера за счет не удаления COM объекта. Причинами этого обстоятельства могут быть преднамеренные или не преднамеренные ошибки при подсчете указателей на интерфейсы, а также в стандартном методе Release интерфейса IUnknow, который поддерживается каждым компонентом объекта. Подобные ошибки могут возникнуть при реализации фабрики классов. Еще одна потенциальная опасность технологии заключается в том, что при определении сервера клиент может решить, использовать хранящуюся в системном реестре информацию о размещении сервера, или определить его положение самостоятельно. Таким образом, последствия действий клиента являются не предсказуемыми и не безопасными. Кроме этого, клиент, работающий на стандартных портах COM, может быть запущен от имени пользователя с соответствующими полномочиями, а, следовательно, может несанкционированно осуществить прием/передачу некоторой информации. Отметим, что устранение перечисленных выше проблем может быть устранено путем тщательного тестирования программного обеспечения, наличия подробной документации на интерфейсы и методы объектов, вывода пользователю информации о произошедших ошибках и исключительных ситуациях, наличия в программном обеспечении журнала ошибок и исключительных ситуаций, а также ведения грамотной политики безопасности всей компьютерной системы.

Сложной проблемой безопасности является наличие не документированных возможностей сервера, за счет наличия в нем скрытых интерфейсов. В стандартном случае идентификаторы серверов, которые хранятся в системном реестре, обеспечивают поиск необходимой информации о сервере. Кроме этого в системном реестре есть ключ Interfaces, в котором хранятся идентификаторы интерфейсов. С помощью этих идентификаторов интерфейсы сервера становятся доступными как запросам клиентов, так и для просмотра администратором. Информацию о интерфейсах можно просмотреть, например с помощью программы OLE/COM Object Viewer, которая входит в пакет MC Visual Studio. Однако COM не предоставляет механизм для непосредственного поиска интерфейсов, поддерживаемых классом. Другими словами, нельзя запросить у объекта список поддерживаемых им интерфейсов. Кроме системного реестра список интерфейсов можно найти в библиотеке типов класса. Однако разработчик может некоторые интерфейсы там не показывать. При этом клиент хотя и с определенными ограничениями, но все таки может использовать интерфейс не представленный в системном реестре и библиотеке типа. Идентификатор интерфейса не нужен если не использовать фабрику классов. Это случай создания локального объекта, например с помощью функции COM API CoCreateInstance, которая позволяет создать единичный экземпляр объекта COM и возвратить указатель на интерфейс. Возможный путь получения всего списка интерфейсов методом перебора, с помощью стандартного метода QueryInterfase стандартного интерфейса IUnknow весьма затруднителен. Ведь для получения указателя на интерфейс в метод QueryInterfase необходимо передать идентификатор интерфейса (GUID). Из-за того, что GUID является 128-битовым числом подбор возможных интерфейсов методом перебора практически не возможен. Таким образом, априорное наличие программных ошибок и особенно "троянских коней" может серьезно нарушить безопасность программного обеспечения, разработанного с использованием технологии COM.

Отдельной проблемой систем COM/DCOM/COM+, т. е. систем построенных на использовании компонентов является проблемы связанные с качеством программирования, в основном за счет трудностей при тестировании системы в целом. Это предопределяет необходимость существования целостной концептуальной модели проектируемой системы, что в свою очередь идет несколько в разрез с самой идеей компонентного программирования.

Дата добавления: 2014-01-14