Добавлен: 25.06.2023
Просмотров: 48
Скачиваний: 2
Технология ActiveX представляет собой технологию, использующую компоненты СОМ, особенно элементы управления. Она была создана для того, чтобы работа с элементами управления была более эффективной, что является при работе с приложениями Internet/Intranet, в которых на компьютер клиента элементы управления должны быть загружены, прежде чем они будут использоваться, особенно необходимым.
Технология ActiveX не является единственным расширение СОМ. В табл. 1 представлены некоторые из используемых в настоящее время расширений СОМ.
Таблица 1 -Список расширений СОМ
|
Расширение СОМ |
Краткое описание |
||
|
Серверы автоматизации (Automation servers) |
Серверы автоматизации- это объекты, которыми можно управлять из других приложений во время работы приложения. Таким образом, автоматизация- это способность приложения программно контролировать объекты других приложений |
||
|
Диспетчеры автоматизации или СОМ-клиенты (Automation Controllers, COM Clients) |
Диспетчеры автоматизации- это клиенты серверов автоматизации. Они позволяют разработчику или пользователю писать сценарии для управления серверами автоматизации |
||
|
Элементы управления ActiveX (ActiveX Controls) |
Элементы управления ActiveX предназначены для серверов внутри процесса (in-process COM servers). Элементы ActiveX обычно используются путем встраивания в приложение-клиент |
||
|
Библиотеки типов (Type Libraries) |
Библиотеки типов представляют собой статичные структуры данных, которые часто сохраняются как файлы ресурсов. Они содержат детализированную информацию об объекте и его интерфейсах. Клиенты серверов автоматизации и элементы управления ActiveX используют данную информацию и всегда считают ее доступной |
||
|
Страницы активного сервера (Active Server Pages) |
Активные серверные страницы- это компоненты ActiveX, которые позволяют вам создавать динамически изменяющиеся Web-страницы |
||
|
Активные документы (Active Documents) |
Активные документы - это объекты, которые поддерживают связывание и внедрение, визуальное редактирование, перенос (drag-and-drop). В качестве примера таких документов можно представить документы Microsoft Word и книги Microsoft Excel |
||
|
Визуальные межпроцессные объекты (Visual Cross-process Objects) |
Визуальные межпроцессные объекты- это визуальные объекты, которыми можно управлять из других процессов |
Причем в табл. 1 перечислены не все из имеющихся расширений СОМ. Доработка старых и создание новых, более совершенных технологий межпрограммного взаимодействия идет постоянно.
На рис. 7 представлена диаграмма, которая показывает связь некоторых расширений СОМ и их связь с технологией СОМ.
Рис. 7. Технологии, основанные на СОМ
Использование СОМ-объектов имеет как преимущества, так и некоторые ограничения. СОМ-объекты могут быть как визуальными, так и невизуальными. Какие-то СОМ-объекты должны быть запущены в одном процессе с клиентом, другие - в разных процессах либо на разных,,компьютерах.
Приведенной ниже табл.2 дано краткое описание особенностей каждого из вышеприведенных расширений СОМ объектов.
Таблица 2 - Особенности объектов СОМ
|
СОМ-объект |
Визуальность |
Процесс |
Связь |
Библиотека типов |
||
|
Активный документ (Active Document) |
Обычно визуальный |
Внутренний или локальный |
OLE |
Нет |
||
|
Автоматизация (Automation) |
Может быть как визуальным, так и невизуальным |
Внутренний, локальный или удаленный |
Автоматический маршалинг при помощи интерфейса IDispatch |
Требуется для автоматического маршалмнга |
||
|
Элемент управления ActiveX (ActiveX Control) |
Обычно визуальный |
Внутренний |
Автоматический маршалинг при помощи интерфейса IDispatch |
Требуется |
||
|
Произвольный объект интерфейса |
По выбору |
Внутренний |
Не требуется маршалинг |
Рекомендуется |
||
|
Произвольный объект интерфейса |
По выбору |
Внутренний, локальный или удаленный |
Автоматический маршалинг в зависимости от библиотеки типов, в противном случае-ручной маршалинг |
Рекомендуется |
Для разработки программного обеспечения имеет очень важное значение развитие технологии компонентного проектирования. Кроме того, что процесс разработки сложных многоуровневых приложений ускоряет компонентное конструирование, которое для разработки отказоустойчивых мультиверсионных программных систем открывает дополнтельные возможности.
Базовая программная модель технологий COM и COM+ является идентичной. Компоненты разрабатываются в одинаковом порядке: описываются интерфейсы, для обеспечения автоматизации реализуется IDispatch, реализуется код для регистрации, т. е. в рамках новой парадигмы делается то же, что делалось и ранее. Однако в дополнение к этому появились новые сервисы, значительно расширяющие возможности приложений.
Интерфейс IUnknown позволяет обеспечить механизм учета ссылок (счетчик ссылок на СОМ-объект). Метод интерфейса IUnknown AddRef выполняется при передаче указателя на интерфейс. Завершая работу с интерфейсом, метод Release, который уменьшает счетчик ссылок вызывает приложение-клиент.
При вызове метода Querylnterface интерфейса Iunknown идентификатор интерфейса (параметр IID), имеющий тип TGUID, передается в метод. Параметр метода out возвращает либо ссылку на запрашиваемый интерфейс, либо значение NH. Результатом вызова метода может быть одно из значений, перечисленных в табл. 3.
Таблица 3.1. Возвращаемые методом Queryinterface значения
|
Значение |
Описание |
||
|
S_OK |
Интерфейс поддерживается |
||
|
E_NOINTERFACE |
Интерфейс не поддерживается |
||
|
E_UNEXPECTED |
Неизвестная ошибка |
Указатель интерфейса - это 32-битный указатель на экземпляр объекта, являющийся указателем на реализацию каждого метода интерфейса. Через массив указателей (vtable) на эти методы доступна реализация методов. Применение массива vtable аналогично механизму поддержки виртуальных функций в Object Pascal. Наглядное представление работы указателей СОМ-интерфейса представлено на рис. 8.
Рис. 8. Схема работы указателя СОМ-интерфейса
Приложение или библиотеку, предоставляющую услуги приложению-клиенту или библиотеке, представляет собой СОМ-сервер . При этом содержит СОМ-сервер один или более СОМ-объектов, выступающих в качестве наборов свойств, методов и интерфейсов.
Как СОМ-объект выполняет свои действия клиенты не знают. Свои услуги СОМ-объект предоставляет при помощи интерфейсов. В дополнение, приложению-клиенту не нужно знать, где находится СОМ-объект, т.к. независимо от местонахождения СОМ-объекта технология СОМ обеспечивает прозрачный доступ.
По запросу клиента услугу от СОМ-объекта, осуществляется передаяа идентификатор класса (CLSID) СОМ-объекту. CLSID - это GUID, который применяется при обращении к СОМ-объекту. СОМ-сервер после передачи CLSID должен обеспечить так фабрику класса, которая создает экземпляры СОМ-объектов.
Создание объекта COM и получение указателя интерфейса происходят через фабрику класса данного компонента. При этом происходят следующие действия:
- ищется бинарный файл, содержащий сервер COM;
- файл загружается в память;
- создается экземпляр компонента и передается указатель интерфейса IUnknown, реализованный в этом компоненте.
Обычно для создания экземпляра сервера COM клиент вызывает WinAPI функцию CoCreateInstance, которая имеет такую сигнатуру:
WINOLEAPI CoCreateInstance(REFCLSID rclsid
, LPUNKNOWN pUnkOuter , DWORD dwClsContext , REFIID riid , LPVOID* ppv);
Параметр rclsid – это идентификатор CLSID требуемого компонента. Параметр riid – идентификатор требуемого интерфейса. В параметр ppv присваивается указатель интерфейса.
Функция CoCreateInstance непосредственно не создает экземпляр компонента, а передает указатель на реализацию интерфейса IClassFactory, которая отвечает за построение объектов классов компонента. При реализации интерфейса IClassFactory определяются функции:
- HRESULT CreateInstance(IUnknown* unkOuter, REFIID riid, void** ppvObject);
- HRESULT LockServer(BOOL lock).
Метод CreateInstance создает экземпляр объекта и возвращает указатель на требуемый интерфейс. Метод LockServer сохраняет сервер в памяти для последующего быстрого выполнения.
В методе CreateInstance создается экземпляр объекта с помощью оператора new. В самой реализации компонента он удаляется в методе Release при достижении счетчиком значения 0. Также вызывается метод QueryInterface и запрашивается требуемый интерфейс. Если объект не поддерживает требуемый интерфейс, то вызов завершается ошибкой, и клиент получает значение типа HRESULT с кодом ошибки. Метод LockServer увеличивает или уменьшает переменную locks, которая отвечает за удержание объекта в памяти.
Рассмотрим создание файла DLL. Для окончательного создания сервера COM нужно добавить несколько дополнительных функций API:
- DllMain – точка входа DLL, которая вызывается системой, когда поток или процесс начинает использование DLL. Это позволяет выполнить любую инициализацию и последующую очистку. Данная функция соответствует функции main исполняемых файлов с расширением exe.
- DllGetClassObject – вызывается с помощью функции CoGetClassObject для возврата указателя на интерфейс IClassFactory.
- DllCanUnloadNow – функция возвращает константуS_OK, если количество фиксаций сервера равно 0, в противном случае возвращает S_FALSE.
- DllRegisterServer – используется для регистрации сервера COM в операционной системе. В системах Win32 это означает добавление соответствующих записей в системный реестр Windows.
DllUnregisterSever – применяется для отмены регистрации сервера COM. В системах Win32 это достигается удалением соответствующих записей из системного реестра Windows.
В файле MySrvDll.cpp из примера [6] экземпляр класса CMyClassFactory определен с помощью синглтона Мейерса [3, 4]. Это единственный экземпляр данного класса, используемый для создания объектов компонента COM.
Функции OpenKey, CreateKey, SetValue и DeleteKey применяются для управления регистрацией и отменой регистрации построенного нами сервера COM. Функция DllGetClassObject проверяет запрашиваемый идентификатор CLSID. Если он равен CLSID_MyComponent, то она использует глобальный экземпляр CMyClassFactory для запроса требуемого интерфейса (riid) и возврата результата. Функции DllRegisterServer и DllUnregisterServer управляют добавлением или удалением требуемых ключей и их значений в системном реестре. Фукция DllRegisterServer создает ключ системного реестра в разделе HKEYS_CLASSES_ROOT_CLSID. Название этого ключа является идентификатором CLSID компонента, заключенным в скобки. Для него установлено значение имени нашего компонента MyComponent. Внутри нового ключа создан подчиненный емуключ InprocSever32. В нем установлено значение пути к файлу DLL. Ключ ThreadingModel установлен в значение Apartment. Для экспорта вышеуказанных функций создан текстовый файл MySrvDll.def. В нем определены экспортируемые функции DLL:
LIBRARY "MyComponent"
EXPORTS
DllCanUnloadNow PRIVATE
DllGetClassObject PRIVATE
DllRegisterServer PRIVATE DllUnregisterServer PRIVATE
Функции API, предназначенные для использования в системе COM, экспортируются как PRIVATE.
После сборки проекта необходимо зарегистрировать сервер COM, вызвав команду regsvr32 и передав в качестве параметра имя DLL. Программа Regsvr32.exe загрузит модуль DLL и вызовет функцию DllRegisterServer для создания требуемых записей в системном реестре [1].
В первую очередь технология COM интересна с точки зрения распределенных вычислений, когда каждая из компонент COM находится на отдельном сервере и они взаимодействуют друг с другом через сеть.
Наиболее известным конкурентом технологии COM является архитектура брокеров объектных запросов Common Object Request Broker Architecture (CORBA), которую развивает Консорциум OMG [8].
Функции CORBA и COM – это функции промежуточного программного обеспечения объектной среды. Для того чтобы обеспечить взаимодействие объектов и их интеграцию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов:
- независимость от физического размещения объекта: компоненты программного обеспечения не обязаны находиться в одном исполняемом файле, выполняться в рамках одного процесса или размещаться на одной аппаратной системе;
- независимость от платформы: компоненты могут выполняться на различных аппаратных и операционных платформах, взаимодействуя друг с другом в рамках единой системы;
- независимость от языка программирования: различия в языках, которые используются при создании компонентов, не препятствуют их взаимодействию друг с другом.