 |
Unknown — базовый интерфейс COM
|
|
|
|
Интерфейс lUnknown обеспечивает минимальное «снаряжение» каждого объекта СОМ. Он содержит три операции и предоставляет любому объекту СОМ две функциональные возможности:
q операция Querylnterface() позволяет клиенту получить указатель на любой интерфейс объекта (из другого указателя интерфейса);
q операции AddRef() и Release() обеспечивают механизм управления временем жизни объекта.
Свой первый указатель на интерфейс объекта клиент получает при создании объекта СОМ. Порядок получения других указателей на интерфейсы (для вызова их операций) поясняет рис. 13.17, где расписаны три шага работы. В качестве параметра операции Querylnterface задается идентификатор требуемого интерфейса (IID). Если требуемый интерфейс отсутствует, операция возвращает значение NULL.
Рис. 13.17. Получение указателя на интерфейс с помощью Querylnterface: 1 — с помощью
указателя на интерфейс А клиент запрашивает указатель на интерфейс В, вызывая
Querylnterface (IID_B); 2 — объект возвращает указатель на интерфейс В;
3 — теперь клиент может вызывать операции из интерфейса В
Имеет смысл отметить и второе важное достоинство операции Querylnterface. В сочетании с требованием неизменности СОМ-интерфейсов она позволяет «убить двух зайцев»:
q развивать компоненты;
q обеспечивать стабильность клиентов, использующих компоненты.
Поясним это утверждение. По законам СОМ-этики новый СОМ-объект должен нести в себе и старый СОМ-интерфейс, а операция Querylnterface всегда обеспечит доступ к нему.
Ну а теперь обсудим правила жизни, а точнее смерти СОМ-объекта. В многоликой СОМ-среде бремя ответственности за решение вопроса о финализации должно лежать как на клиенте, так и на СОМ-объекте. Можно сказать, что фирма Microsoft (создатель этой модели) разработала самурайский кодекс поведения СОМ-объекта — он должен сам себя уничтожить. Возникает вопрос — когда? Когда он перестанет быть нужным всем своим клиентам, когда вытечет песок из часов его жизни. Роль песочных часов играет счетчик ссылок (СЧС) СОМ-объекта.
|
|
|
Правила финализации СОМ-объекта очень просты:
q при выдаче клиенту указателя на интерфейс выполняется СЧС+1;
q при вызове операции AddRef выполняется СЧС+1;
q при вызове операции Release выполняется СЧС-1;
q при СЧС=0 объект уничтожает себя.
Конечно, клиент должен помогать достойному харакири объекта-самурая:
q при получении от другого клиента указателя на интерфейс СОМ-объекта он должен вызвать в этом объекте операцию AddRef;
q в конце работы с объектом он обязан вызвать его операцию Release.
Серверы СОМ-объектов
Каждый СОМ-объект существует внутри конкретного сервера. Этот сервер содержит программный код реализации операций, а также данные активного СОМ-объекта. Один сервер может обеспечивать несколько объектов и даже несколько СОМ-классов. Как показано на рис. 13.18, используются три типа серверов:
q Сервер «в процессе» (in-process) — объекты находятся в динамически подключаемой библиотеке и, следовательно, выполняются в том же процессе, что и клиент;
q Локальный сервер (out-process) — объекты находятся в отдельном процессе, выполняющемся на том же компьютере, что и клиент;
q Удаленный сервер — объекты находятся в DLL или в отдельном процессе, которые расположены на удаленном от клиента компьютере.
С точки зрения логики, клиенту безразлично, в сервере какого типа находится СОМ-объект — создание объекта, получение указателя на его интерфейсы, вызов его операций и финализация выполняются всегда одинаково. Хотя временные затраты на организацию взаимодействия в каждом из трех случаев, конечно, отличаются друг от друга.
|
|
|
Рис. 13.18. Различные серверы СОМ-объектов
Преимущества COM
В качестве кратких выводов отметим основные преимущества СОМ.
1. СОМ обеспечивает удобный способ фиксации услуг, предоставляемых разными фрагментами ПО.
2. Общий подход к созданию всех типов программных услуг в СОМ упрощает проблемы разработки.
3. СОМ безразличен язык программирования, на котором пишутся СОМ-объекты и клиенты.
4. СОМ обеспечивает эффективное управление изменением программ — замену текущей версии компонента на новую версию с дополнительными возможностями.
Работа с СОМ-объектами
При работе с СОМ-объектами приходится их создавать, повторно использовать, размещать в других процессах, описывать в библиотеке операционной системы. Рассмотрим каждый из этих вопросов.
Создание СОМ-объектов
Создание СОМ-объекта базируется на использовании функций библиотеки СОМ. Библиотека СОМ:
q содержит функции, предлагающие базовые услуги объектам и их клиентам;
q предоставляет клиентам возможность запуска серверов СОМ-объектов.
Доступ к услугам библиотеки СОМ выполняется с помощью вызовов обычных функций. Чаще всего имена функций библиотеки СОМ начинаются с префикса «Со». Например, в библиотеке имеется функция CoCreateInstance.
Для создания СОМ-объекта клиент вызывает функцию библиотеки СОМ CoCreateInstance. В качестве параметров этой функции посылаются идентификатор класса объекта CLSID и IID интерфейса, поддерживаемого объектом. С помощью CLSID библиотека ищет сервер класса (это делает диспетчер управления сервисами SCM — Service Control Manager). Поиск производится в системном реестре (Registry), отображающем CLSID в адрес исполняемого кода сервера. В системном реестре должны быть зарегистрированы классы всех СОМ-объектов.
Закончив поиск, библиотека СОМ запускает сервер класса. В результате создается неинициализированный СОМ-объект, то есть объект, данные которого не определены. Описанный процесс иллюстрирует рис. 13.19.
Как правило, после получения указателя на созданный СОМ-объект клиент предлагает объекту самоинициализироваться, то есть загрузить себя конкретными значениями данных. Эту процедуру обеспечивают стандартные СОМ-интерфейсы IPersistFile, IPersistStorage и IPersistStream.
|
|
|
Рис. 13.19. Создание одиночного СОМ-объекта: 1 —клиент вызывает CoCreatelnstance
(CLSID M, IID А); 2 — библиотека СОМ находит сервер и запускает его;
3 — библиотека СОМ возвращает указатель на интерфейс А;
4 — теперь клиент может вызывать операции СОМ-объекта
Параметры функции CoCreateInstance, используемой клиентом, позволяют также задать тип сервера, который нужно запустить (например, «в процессе» или локальный).
В более общем случае клиент может создать несколько СОМ-объектов одного и того же класса. Для этого клиент использует фабрику класса (class factory) — СОМ-объект, способный генерировать объекты одного конкретного класса.
Фабрика класса поддерживает интерфейс IClassfactory, включающий две операции. Операция Createlnstance создает СОМ-объект — экземпляр конкретного класса, имеет параметр — идентификатор интерфейса, указатель на который надо вернуть клиенту. Операция LockServer позволяет сохранять сервер фабрики загруженным в память.
Клиент вызывает фабрику с помощью функции библиотеки COM CoGetClassObject:
CoGetClassObject (<CLSID создаваемого обьекта>, < IID интерфейса IClassFactory>)
В качестве третьего параметра функции можно задать тип запускаемого сервера.
Библиотека СОМ запускает фабрику класса и возвращает указатель на интерфейс IClassFactory этой фабрики. Дальнейший порядок работы с помощью фабрики иллюстрирует рис. 13.20.
Рис. 13.20. Создание СОМ-объекта с помощью фабрики класса: 1 — клиент вызывает
IClassFactory:: Createlnstance (IID A); 2 — фабрика класса создает СОМ-объект и получает
указатель на его интерфейс; 3 — фабрика класса возвращает указатель на интерфейс А
СОМ-объекта; 4 — теперь клиент может вызывать операции СОМ-объекта
Клиент вызывает операцию IClassFactory::CreateInstance фабрики, в качестве параметра которой задает идентификатор необходимого интерфейса объекта (IID). В ответ фабрика класса создает СОМ-объект и возвращает указатель на заданный интерфейс. Теперь клиент применяет возвращенный указатель для вызова операций СОМ-объекта.
Очень часто возникает следующая ситуация — существующий СОМ-класс заменили другим, поддерживающим как старые, так и дополнительные интерфейсы и имеющим другой CLSID. Появляется задача — обеспечить использование нового СОМ-класса старыми клиентами. Обычным решением является запись в системный реестр соответствия между старым и новым CLSID. Запись выполняется с помощью библиотечной функции CoTreatAsClass:
CoTreatAsClass (<старый CLSID>, <новый CLSID>).
|
|
|
