Добавлен: 27.06.2023
Просмотров: 37
Скачиваний: 2
Введение
Во многих областях науки и производства используется активно программное обеспечение (ПО), являющееся неотъемлемой составляющей коммерческих и специальных информационно-управляющих систем (ИУС),. Но в силу многих причин создать абсолютно безупречный, совершенный программный продукт чрезвычайно сложно [1].
В настоящее время компьютеры стали применяться в информационно-управляющих системах для решения все более сложных проблем. Поэтому повышается вероятность логических ошибок, которые, возможно, могут присутствовать в программном обеспечении.
Функционирование системы независимо от скрытых ошибок отдельных версий обеспечивается посредством мультиверсионности исполнения программных компонентов. При этом к основному достоинству этого программного обеспечения относится то, что произойти сбой системы может только в единственном случае - в случае сбоя существенного числа модулей. В информационно-управляющих системах мультиверсионное программирование предполагает, что в функционально эквивалентных модулях возникновение сбоя происходит в различных точках, за счет этого можно сбой обнаружить и исправить. Основой мультиверсионного программного обеспечения является независимость сбоев различных модулей [2].
Теоретические основы технологии «СОМ»
Компонент - готовый к использованию фрагмент двоичного кода, содержащихся либо в динамической библиотеке DLL, либо в ехе-файле, который может быть при необходимости загружен в память и стандартным образом динамически подключен к приложению.
Выделяют две основные черты компонентов:
1. динамически связанная - связь компонента и приложения (связь между вызовом функции в приложении, ее кодом в теле компонента) осуществляется не на этапе компоновки приложения, а непосредственно во время выполнения.
2. скрытая внутренняя реализация (инкапсуляция) означает, что для приложения не важно, и приложение не знает как именно реализован компонент внутри, а знает только как вызывать его функции.
При разработке приложения из компонентов основной код приложения и компоненты компилируются отдельно, на этапе исполнения происходит динамическое связывание между вызовами функции в теле приложения и самими функциями, реализованными в компонентах.
Модификация или расширение компонента (приложения) сводится к замене одного из его компонентов новой версией.
Если приложение состоит из компонентов, оно может быть распределенным, к этому располагают 2 особенности:
3. приложение уже разделено на составные части, которые могут находиться в частности на различных ЭВМ;
4. так как компоненты заменяемы, при организации распределенной архитектуры приложения, в него могут быть добавлены специальные компоненты, обеспечивающие связь (например, по локальной сети, Internet).
Приложения, использующие компонент, являются клиентом для данного компонента, при этом компонент подключается к приложению клиенту при помощи единого стандартного интерфейса. В современных версиях Windows в качестве такого интерфейса используется технология СОМ.
Оба эти определения имеют право на существование COM (Component Object Model) - модель многокомпонентных объектов, позволяющая приложению манипулировать удаленными программными объектами, точнее вызывать те или иные функции (методы) этих объектов так, как будто эти объекты находятся «рядом».
СОМ - стандарт (спецификация), которому должны следовать компоненты и клиенты, чтобы иметь возможность совместной работы. При этом компоненты должны быть стандартным образом зарегистрированы операционной системой. Используя схему объявлений СОМ (список зарегистрированных функций компонентов), клиенты могут динамически находить нужные компоненты (рис.1).
Рис.1. Схема СОМ – стандарта
Интерфейс СОМ включает в себя набор функций, которые реализуются компонентами и используются клиентами. Интерфейсом СОМ является определенная структура, содержащая в памяти массив указателей на функции, имеющиеся в компонентах, зарегистрированных в системе. Для организации взаимодействия между частями распределенного приложения, расположенного на различных ЭВМ, технология СОМ использоваться не может. Связано это с тем, что у ЭВМ, работающих раздельно нет общей области памяти, в которой мог бы располагаться интерфейс СОМ. Для организации распределенного взаимодействия компонентов используется технология DCOM (Distributed Component Object Model) (модель распределенных многокомпонентных объектов).
DCOM - программная архитектура, используемая для организации взаимодействия программных компонентов, расположенных на нескольких компьютерах сети (рис.2).
Рис.2. Схема DCOM - стандарта
Приложение на одной из ЭВМ может использоваться DCOM для передачи сообщения (называемого удаленным вызовом процедуры) компоненту на другую ЭВМ. DCOM автоматически устанавливает соединение, передает сообщение и возвращает ответ удаленным компонентам. В принципе в случае использования DCOM неважно, находится ли приложение и компонент на разных ЭВМ или на одной. Однако использование DCOM медленнее, чем СОМ.
Используя СОМ, клиенту не нужно заботиться о том, где объект располагается, потому что он просто вызывает интерфейс данного объекта. Все необходимые шаги для того, чтобы сделать этот вызов обеспечивает технология СОМ. При этом в зависимости от местонахождения объекта шаги могут отличаться. Применение разных типов серверов зависит от того, находится ли объект в том же процессе, где и клиент, или на том же компьютере, где расположен клиент, но в другом процессе, или на другом компьютере в сети. Используются в зависимости от этого следующие виды серверов:
- внутренний (In-process server);
- локальный (Local server) или сервер вне процесса (Out-of-process server);
- удаленный (Remote server).
Внутренний сервер представляет собой библиотеку DLL, запущенную вместе с клиентом в одном процессе. Например, внедренный на Web-страницу элемент управления ActiveX, который можно просматреть при помощи Internet Explorer или Netscape Navigator. Элемент управления ActiveX в данном случае загружен на клиентскую машину, поэтому он находится в одном процессе с и обозревателем Web. С сервером внутри процесса приложение-клиент связывается при помощи прямых вызовов СОМ-интерфейса. На рис. 3. Изображено схематично взаимодействие клиента с внутренним сервером.
Рис. 3. Схема взаимодействия клиента с внутренним сервером
При этом экспортировать внутренний СОМ-сервер должен следующие функции:
- function DllRegisterServer: HResult; stdcall;
- function DllUnregisterServer: HResult; stdcall;
- function DllGetClassObject (const CLSID, IID: TGUID; var Obj): HResult; stdcall;
- function DllCanUnloadNow: HResult; stdcall;
В модуле comserv эти функции уже реализованы, необходимо только добавить их в описание exports реализуемого проекта.
Функция DllRegisterServer используется в системном реестре Windows для регистрации DLL СОМ-сервера. При регистрации в системном реестре СОМ-класса создается раздел в HKEY_CZASSES_ROOT\CLSID\ {XXXXXXXX-XXXX-XXXX-xxxx-xxxxxxxx}, где число, записанное вместо символов х, представляет собой CLSID данного СОМ-класса. В данном разделе для внутреннего сервера происходит создание дополнительного подраздела inProcserver32., в котором указывается путь к DLL внутреннего сервера (рис. 4).
Рис. 4. Путь в окне редактора системного реестра к локальному СОМ-серверу
Для удаления всех разделов, подразделов и параметров, созданных созданы в системном реестре функцией при регистрации DLL СОМ-сервера, применяется функция DllRegisterServer. - DllUnregisterServer - применяется
Для конкретного СОМ-класса возвращает фабрику класса функцияDllGetclassObject.
Применение функции DllcanUnloadNow позволяет определить: возможно ли выгрузить DLL СОМ-сервера из памяти в настоящий момент времени. Функция проверяет наличие указателей данной DLL на любой СОМ-объект,. При отрицательном варианте, т. е. DLL выгрузить нельзя, возвращает значение S_FALSE. При положительном варианте, означающем, что данной DLL не используется ни один СОМ-объект, функция возвращает значение SJTRUE.
Локальный сервер является ЕХЕ-приложением, запущенным на одном компьютере вместе с клиентом, но в другом процессе. В качестве примера можно рассмотреть связанный с документом Microsoft Word лист электронной таблицы Microsoft Excel. Работают эти два разных приложения на одном компьютере. Для соединения с клиентом локальные серверы используют СОМ.
Когда клиент и сервер находятся в различных приложениях, а также, когда они находятся на разных компьютерах в сети, СОМ использует внутренний (внутрипроцессный) прокси (In-process proxy) для реализации процедуры удаленного вызова. Прокси располагается в одном процессе вместе с клиентом, поэтому, с точки зрения клиента, вызов интерфейсов осуществляется так же, как и в случае, когда клиент и сер'вер находятся внутри одного процесса. Задача прокси заключается в том, чтобы перехватывать вызовы клиента и перенаправлять их туда, где запущен сервер. Механизм, который позволяет клиенту получать доступ к объектам, расположенным в другом адресном пространстве или на другом компьютере, называется маршалинг (marshaling).
Функции маршалинга:
- принимать указатель интерфейса из процесса сервера и делать указатель прокси в процессе клиента доступным;
- передавать аргументы вызовов интерфейса таким образом, как будто они произошли от клиента и размещать аргументы в процесс удаленного объекта.
Для любого вызова интерфейса клиент помещает аргументы в стек, вызывает необходимую функцию СОМ-объекта через указатель интерфейса. Если вызов объекта произошел не внутри процесса, вызов проходит через прокси. Прокси упаковывает аргументы в пакет маршалинга и передает получившуюся структуру удаленному объекту. Заглушка (stub) объекта распаковывает пакет маршалинга, выбирает аргументы из стека и вызывает необходимую функцию СОМ-объекта.
Таким образом, маршалинг - это процесс упаковки информации, а демаршалинг - процесс распаковки информации.
Тип маршалинга зависит от объектной принадлежности СОМ. Объекты могут использовать стандартный механизм маршалинга, предоставляемый интерфейсом IDispatch. Стандартный маршалинг позволяет устанавливать связь при помощи стандартного системного удаленного вызова процедуры (Remote Procedure Call, RFC).
На рис. .5 изображена схема, показывающая методику взаимодействия клиента и сервера в случае, когда приложения работают на одном компьютере, но в разных приложениях.
Рис. .5. Схема взаимодействия клиента с сервером в разных процессах на одном компьютере
В системном реестре Windows регистрируется локальный СОМ-сервер так же, как и внутренний СОМ-сервер.
Библиотека DLL или иное приложение, которое запущено на другом компьютере, представляет собой удаленный сервер. При этом работают клиент и сервер в сети на разных компьютерах. В качестве примера рассмотрим написанное с помощью Delphi приложение базы данных, которое соединяется в сети с сервером на другом компьютере. Для связи с клиентом удаленный сервер применяет распределенные СОМ-интерфейсы (Distributed COM, DCOM).
Также удаленный сервер может работать с помощью прокси. Заключается между локальным и удаленным сервером различие в работе в типе используемой межпроцессной связи. При этом СОМ применяется при использовании локального сервера, DCOM– интерфейс – в случае удаленного сервера. На рис. 6 показано, как осуществляется взаимодействие клиента и удаленного сервера.
Рис. 6. Схема взаимодействия клиента с сервером на разных компьютерах
Очень важным при разработке СОМ-приложений является создание приложений, называемых СОМ-клиентами, которые могут запрашивать интерфейсы объектов, чтобы определить те услуги, которые может предоставить СОМ-объект.
Типичным СОМ-клиентом является диспетчер автоматизации (Automation Controller), представляющий собой часть приложения, которая знает какой тип информации необходим ему от разных объектов сервера, и она запрашивает данную информацию по мере надобности.
Использование технологии «СОМ»
Первоначально технология «СОМ» разрабатывалась как ядро для осуществления межпрограммного взаимодействия. Еще на этапе разработки предполагалось при помощи так называемых расширений СОМ расширять возможности технологии. Собственную функциональность СОМ расширяет, посредством создания для решения конкретных задач специализированных наборов интерфейсов.