Технология СОМ+ для реализации мультиверсионного программного обеспечения информационно-управляющих систем

Программное обеспечение (ПО), являясь неотъемлемой составляющей коммерческих и специальных инфор-мационно-управляющих систем (ИУС), активно используется во многих областях науки и производства. Однако, ввиду многих причин, чрезвычайно сложно создать безупречный программный продукт [1]. А поскольку компьютеры применяются для решения все более сложных проблем в ИУС, то растет вероятность логических ошибок, присутствующих в программном обеспечении.

Мультиверсионность исполнения программных компонентов обеспечивает функционирование системы независимо от скрытых ошибок отдельных версий. Основным достоинством мультиверсионного программного обеспечения является то, что сбой системы может произойти только в единственном случае - в случае сбоя существенного числа модулей. Мультиверсионное программирование в ИУС предполагает, что возникновение сбоя в функционально эквивалентных модулях происходит в различных точках, благодаря чему этот сбой может быть обнаружен и исправлен. Независимость сбоев различных модулей является одной из основ мультиверсионного программного обеспечения [2].

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

При разработке мультиверсионной системы необходимо выполнение следующих требований:

• -    динамического подключения модулей;

• -    требования инкапсуляции;

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

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

Разделение программного обеспечения на независимые модули является наиболее важным методом для обеспечения отказоустойчивости. Без модульной декомпозиции также невозможно и построение мультиверсионного программного обеспечения. Выполнение требований к мультиверсионным модулям гарантирует отказоустойчивость как при проектировании, так и, что особенно важно, при практической реализации модульной архитектуры программной системы.

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

Существуют два наиболее перспективных стандарта компонентного программного обеспечения [4]:

• -    COM ( Component Object Model ) - компонентная объектная модель. Это архитектура, разработанная корпорацией «Microsoft» и позволяющая создавать и поддерживать программные объекты и компоненты. Потенциально только эту технологию могут поддерживать различные языки программирования;

• -    CORBA ( Common Object Request Broker Architecture) - общая архитектура брокера объектных запросов. Этот стандарт был предложен консорциумом OMG для организации взаимодействия распределенных объектов. Архитектура CORBA позволяет выполнять в сети программы, написанные на любом языке, независимо от того, на какой платформе они запускаются. В архитектуре CORBA клиент выполняет запрос к общему интерфейсу который называется брокером объектных запросов ORB, который пересылает запрос соответствующему объекту, а затем возвращает клиенту полученные результаты.

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

Программа-клиент использует при своей работе объект (объекты) некоторой другой программы (сервера) так, словно этот объект является частью самого клиента. Основную роль при этом играет интерфейс объектов, под которым подразумевается поименованное множество функционально связанных методов (операций) объекта. Интерфейс может формироваться, как правило, при помощи IDL ( Interface Definition Language) - специального C++-подобного языка описания интерфейсов. В результате клиент получает именно интерфейс затребованного объекта. Сервер же представляет собой программу, содержащую, кроме всего прочего, еще один или несколько объектов СОМ. Сервер СОМ может создавать реализации объектов из нескольких классов, каждый из которых представляет различные варианты поведения объекта.

СОМ-клиент взаимодействует с СОМ-сервером через указатель на интерфейс и использует этот указатель для вызова методов сервера. При этом клиент и сервер могут сосуществовать и взаимодействовать тремя различными способами:

• -    клиент и сервер выполняются на одном компьютере в рамках единого процесса;

• -    клиент и сервер запускаются на одной машине в рамках разных процессов;

• -    клиент и сервер - разные программы на различных компьютерах в составе сети.

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

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

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

Приложение COM+ является основной единицей для защиты и администрирования компонентов. COM+ - это множество COM-компонентов, которые выполняют согласованные функции:

• -    COM-класс представляет собой именованный набор интерфейсов (одного или нескольких). Интерфейс -это группа логически взаимосвязанных функций, называемых методами;

• -    COM-объект - созданный экземпляр COM-класса;

• -    COM-компонент - это бинарная единица кода, функцией которого является создание COM-объекта.

Таким образом, можно сказать, что каждый из компонентов состоит из интерфейсов, которые в свою очередь состоят из методов. COM-класс идентифицируется уникальным идентификатором CLSID с интерфейсом IID.

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

• -    определение пространства развертывания COM-компонентов;

• -    общее конфигурирование COM-компонентов, включая службу безопасности, балансировку загрузки компонентов, диспетчеризацию очередей сообщений компонентов;

• -    сохранение атрибутов компонентов, обеспечиваемое операционной системой, а не разработчиком;

• -    загрузка компонентных DLL в процесс по усмотрению разработчика;

• -    создание и управление потоками выполнения компонентов;

• -    осуществление доступа к контексту объекта за ресурсами, которое позволяет автоматически ассоциировать их с контекстом объекта.

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

Создание СОМ-компонентов осуществляется в следующем порядке:

• -    определение COM-классов и их воплощение;

• -    группировка классов в компоненты;

• -    определение множества СОМ+-сервисов, необходимых для компонента;

• -    разработка СОМ+-приложения;

• -    интеграция компонентов в, уже существующее или новое СОМ+-приложение;

• -    определение правильного множества атрибутов для каждого класса. Эти атрибуты представляют зависимости компонентов от используемых сервисов (транзакции, очереди ит. д.);

• -    установка системы защиты (права и роли классов, методов, интерфейсов);

• -    конфигурация переменных окружения для классов и приложений;

• -    подготовка приложения для распространения и развертывания;

• -    администрирование СОМ+-приложений;

• -    инсталляция приложения на компьютере администратора;

• -    установка переменных окружения (членов групп-ролей и т. д.);

• -    создание брокеров ( proxy ) приложения (если приложение должно быть доступно удаленным);

• -    тестирование приложения;

• -    задание параметров кластеризации.

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

Взаимодействие программ, предоставляющих информацию, изменяющуюся во времени (издатели), с программами, которым необходимы данные об этих изменениях (абоненты), уже давно представляет сложную проблему для разработчиков распределенных приложений.

В технологии СОМ подписчик (абонент) обеспечивает издателя интерфейсом, а издатель вызывает метод этого интерфейса, когда происходит что-то его интересующее. Такой подход используют элементы управления ActiveX для генерации событий в своих контейнерах. Это так называемое жестко связанное событие ( tightly coupled event ), когда подписчик знает точно, у какого издателя запрашивает извещение (контейнер знает идентификатор СЬ8Ш) и механизм для соединения с ним (ICONNЕCТIONРOINТCONТAINЕR и интерфейсы СОХХЕСТЮХРО1М).

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

В технологии СОМ+ служба событий - это сервис операционной системы, который согласовывает и связывает издателя и подписчиков. Эта служба обеспечивает инфраструктуру, которая делает простыми публикацию и подписку к данным.

Издатель - это любая программа, делающая СОМ-вызовы, которые инициализируют события, а абонент (подписчик ) - это СОМ+-компонент, который принимает СОМ-вызовы, представляющие собой события издателя. Абонент осуществляет интерфейс как СОМ-сервер, а издатель делает вызовы как СОМ-клиент. Событие - это одиночный вызов метода СОМ-интерфейса, инициированный издателем и доставленный службой событий (event service ) нужному подписчику (подписчикам). Единственным отличием в работе СОМ+-службы событий от классической СОМ является наличие промежуточной службы событий, отслеживающей множество подписчиков, которые ожидают вызова, и направляющей вызовы этим подписчикам, при этом специфическая информация об издателе не нужна.

Создание одиночного запроса события известно как возбуждение события (в технологической документации термин «публикация» используется в качестве синонима для термина «возбуждение»). Соединение между издателем и подписчиком осуществляется классом события. Класс события - это СОМ+-компонент, содержащий интерфейсы и методы, которые издатель вызывает для инициирования события и которые должен реализовывать подписчик, если он желает получить извещение о событии. Интерфейсы и методы, обеспеченные классом события называются интерфейсами события и методами события.

Средствами СОМ+-библиотек типов устанавливаются, какие СОМ+-интерфейсы и методы должен содержать класс события. Классы событий хранятся в СОМ+-ката-логе, они помещаются туда или непосредственно программами-издателями или административными инструментальными средствами. Подписчик объявляет о своем намерении принимать события от издателя, регистрируя подписку в службе событий СОМ+.

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

Когда издатель хочет инициировать событие, он использует стандартные объектные функции создания объекта требуемого класса события типа CoCreate или CreateObject. Этот объект, известный как объект события, содержит реализацию системы событий требуемого интерфейса. Затем издатель вызывает метод события для инициирования события подписчиком. Система событий просматривает СОМ+-каталог и находит всех подписчиков, которые имеют зарегистрированные подписки к это- му интерфейсу и методу. Далее эта система соединяется с каждым подписчиком и вызывает в каждом указанный метод. Поскольку обычно извещения о событии получают один и более подписчиков, то методы событий не могут возвращать никакого значения, кроме Success или Failure типа HRESULTs. Те же самые ограничения касаются и методов интерфейса очередей компонентов. Таким образом, любой СОМ-клиент может стать издателем, а любой СОМ+-компонент - подписчиком. При этом ни том, ни в другом случае он не обязан ничего знать о действиях, выполняемых службой событий.

Еще одно значительное усовершенствование, которое обеспечивает технология СОМ+, лежит в области защиты.

С появлением DCOM как части Windows NT 4.0 защита стала реальным результатом для разработчиков компонентов. DCOM-поддержка удаленного вызова сделала реальным проектирование распределенных приложений, но стоимость создания защищенных приложений при этом сильно увеличилась. Сервер транзакций MTS смог немного решить эту проблему, введя концепцию системы защиты на основе прикладных ролей ( role-based security ) - так называемую роль-основанную защиту. Эта система позволяет разработчикам приложений создавать различные классы полномочий, или ролей. Каждый пользователь приложения относится к одному или нескольким классам полномочий. Роль-основанная защита позволяет разработчику сосредоточиться на проблемах безопасности прикладного уровня вместо нижнего уровня. Однако сервер MTS смог обеспечить лишь достаточно ограниченную поддержку удаленного вызова. Технология СОМ+ позволила решить эту проблему.

СОМ+-служба безопасности, как и MTS, обеспечивается посредством концепции ролей (конечно, если это не удовлетворяет требованиям связываемого приложения, можно продолжать писать NT-код защиты нижнего уровня). В случае когда роль-основанная защита не эффективна (например, система защиты на основе экземпляров объектов( per-instance security )), СОМ+ обеспечивает обширную поддержку для impersonation and cloaking. Цель архитектуры защиты СОМ+ состоит в том, чтобы в максимально возможной степени изолировать проблемы безопасности нижнего уровня.

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

Используя технологию СОМ+, можно назначать роли определенным компонентовам, интерфейсам и методам в пределах создаваемого приложения. Клиентский доступ к каждому из этих объектов управляется СОМ+ во время выполнения. Это мощная методика, с помощью которой СОМ+ осуществляет систему доступа для приложения. Другой важной особенностью является то, что установка и обслуживание этой системы осуществляется декларативно, т.е. внешне для кода компонента. Так как СОМ+ обеспечивает детали контроля доступа нижнего уровня, то система может управляться административно намного позже разработки самого приложения. Потребителям роли даны, компонентам, интерфейсам и методам роли назначены.

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

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

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