Файл: Технология СОМ (Создание и повторное применение объектов СОМ. Маршалинг).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 25.06.2023

Просмотров: 161

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Введение

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

Именно этот подход и реализуется в COM (Component Object Model). Объекты COM являются эффективным механизмом повторного применения программного обеспечения, так как создают дискретные, повторно используемые компоненты, которые могут играть роль, аналогичную той, что играют микросхемы, используемые проектировщиками аппаратуры.

Идея повторного применения является достаточно старой, но имелись технологические трудности. Наиболее распространенные схемы повторного применения: библиотеки и объекты.

Библиотеки, особенно динамические полезны, но не лишены недостатков. Один из них - сложность расширения функциональных возможностей, как установить новую версию динамической библиотеки, не повредив приложениям, ориентированным на старую и каков способ установки в системе более одной реализации одной и той же библиотеки. К тому же динамические библиотеки не поддерживают объектно-ориентированный подход.

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

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


1. Понятие СОМ

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

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

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

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

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

У каждого интерфейса СОМ есть два имени. Одно из них предназначено для людей - строка символов. Другое имя - предназначено для использования в основном программном обеспечении. Символьное имя не является уникальным, имя же используемое программами - уникально, что позволяет точно идентифицировать интерфейс. По соглашению читабельные имена большинства СОМ интерфейсов начинаются с буквы I (от interface). Читабельные имена удобны при упоминании интерфейса в разговоре или выборе имен переменных для указателей интерфейсов. Но они не уникальны и не могут однозначно определить какой именно интерфейс нужен.

В качестве уникального имени используется глобальный уникальный идентификатор (globally unique identifier - (GUID) GUID интерфейса называется идентификатором интерфейса (interface identifier - IID). GUID - это 16-байтовая величина, которая, обычно, генерируется программой-утилитой. При этом гарантируется ее уникальность. При генерации GUID программа использует уникальное значение, имеющееся на большинстве компьютеров - адрес платы сетевого интерфейса. Если в компьютере нет сетевой платы, то из различных случайных характеристик данной системы генерируется фиктивный идентификатор машины.


Единожды определенный интерфейс не может быть изменен. Если при разработке новой версии объекта понадобился интерфейс, похожий на предыдущий, но немного отличающийся, то создается новый интерфейс, имеющий новое имя и новый IID.

Интерфейсы могут наследовать друг другу, причем реализация не наследуется.

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

1.1. Реализация интерфейса

СОМ задает стандартный двоичный формат, который каждый СОМ объект должен поддерживать для каждого интерфейса. Наличие стандартного двоичного формата означает, что любой клиент может вызвать методы любого объекта не зависимо от языка программирования.

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

1.2. Классы

Всякий СОМ объект является экземпляром некоторого класса, и каждому классу может быть присвоен GUID - идентификатор класса (CLSID). При создании клиентом объекта СОМ он должен указать CLSID. Допустимо одновременное существование нескольких объектов одного класса.

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

Связь между классом объекта и интерфейсами, которые он поддерживает, не очень прочна. Добавление к набору интерфейсов, поддерживаемых классом, нового не обязательно меняет класс.

Назначение CLSID - идентификация некоторого фрагмента кода, чтобы можно было загружать и активизировать объекты данного класса.

Существует возможность эмуляции классов. Пусть имеется новый класс, который реализует все те же интерфейсы, что и старый, но и некоторые еще, и он имеет свой CLSID. Допустим мы замешан старый класс на новый. Те приложения, которые использовали старый, могли бы использовать новый (с точки зрения поддерживаемых интерфейсов), но загружают они его по старому CLSID, поэтому необходимо организовать эмуляцию старого объекта новым.


1.3. Интерфейс IUnknown

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

IUnknown содержит только три метода: Querylnterface, AddRef, Release.

Query-Interface. Обычно свой первый указатель на интерфейс объекта клиент получает при создании объекта (см. далее). Для того, чтобы получить указатели на другие интерфейсы используется метод Querylnterface интерфейса IUnknown или любого другого интерфейса. В качестве параметра методу Querylnterface передается IID требуемого интерфейса, Если объект поддерживает этот интерфейс, то будет возвращен указатель на него, иначе NULL.

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

AddRef, Release - подсчет ссылок. Чтобы воспользоваться объектом СОМ, клиент должен явно инициировать начало работы экземпляра этого объекта (как, см. далее). А каким образом решается, когда завершается работа объекта? Кажущееся очевидным решение - возложить на клиент, запустивший объект на выполнение, обязанность сообщить объекту, когда он должен остановиться - неверно, так как данный клиент может оказаться не единственным, кто этот объект использует. Например, первый клиент может передать один из указателей на интерфейсы этого объекта другому клиенту, тот третьему и т.д.

Таким образом, разрешить клиенту уничтожать объект небезопасно. Только сам объект может решить, когда он может безопасно закончить свою работу, если все клиенты сообщили ему, что они закончили. г>то осуществляется с помощью механизма подсчета ссылок, реализуемого методами AddRef, Release интерфейса IUnknown.

Каждый исполняющийся объект поддерживает счетчик ссылок. Всякий раз, выдав вовне указатель на один из своих интерфейсов, объект увеличивает счетчик ссылок на 1. Если один клиент передает указатель интерфейса другому клиенту, т.е. увеличивает число пользователей объекта без его ведома, то клиент, получающий указатель, должен вызвать с помощью этого указателя метод AddRef. В результате объект увеличит свой счетчик ссылок. Независимо от того, как он получил указатель на интерфейс, клиент всегда обязан вызвать для этого указателя метод Release, закончив работу с ним. Исполнение этого метода объектом состоит в уменьшении числа ссылок на 1. Обычно объект уничтожает сам себя, когда счетчик ссылок становится равным 0.


Подсчет ссылок может вызвать проблемы, если не все клиенты следуют правилам, но это единственный способ управления временем жизни объектов.

1.4. Серверы объектов СОМ

Каждый объект СОМ реализован внутри некоторого сервера, содержащего код, который реализует методы интерфейсов объекта, а также контролирует данные объекта, пока тот активен. Один сервер может поддерживать более одного объекта некоторого класса и даже поддерживать несколько классов. Существует три типа серверов:

- сервер «в процессе» (in-process) или внутризадачный: объекты реализуются в динамической библиотеке и исполняются в том же процессе, что и клиент;

- локальный сервер: объекты реализованы в отдельном процессе, исполняющемся на той же машине, что и клиент;

- удаленный сервер: объекты реализованы либо в динамической библиотеке, либо в отдельном процессе, которые расположены на удаленном по отношению к клиенту' компьютере - возможность создания таких серверов поддерживает распределенная СОМ (DCOM).

С точки зрения клиента, объекты, реализованные любой из трех разновидностей серверов, выглядят одинаково.

При определении способа реализации компонентов следует учитывать, что внутризадачные серверы являются наиболее эффективными, поскольку они выполняются в адресном пространстве клиента и не требуется никаких дополнительных средств для передачи параметров методам клиента.

2. Создание и повторное применение объектов СОМ. Маршалинг

2.1. Создание объектов СОМ

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

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