C++ уже давно с нами. Сообщество программистов на C++ весьма обширно, и большинство из них хорошо знают о западнях и подводных камнях языка. Язык C++ был создан высоко квалифицированной командой разработчиков, которые, работая в Bell Laboratories, выпустили не только первый программный продукт C++ (CFRONT), но и опубликовали много конструктивных работ о C++. Большинство правил языка C++ было опубликовано в конце 1980-х и начале 1990-х годов. В этот период многие разработчики C++ (включая авторов практически каждой значительной книги по C++) работали на рабочих станциях UNIX и создавали довольно монолитные приложения, использующие технологию компиляции и компоновки того времени. Ясно, что среда, в которой работало это поколение программистов, была в основном создана умами всего сообщества C++.

Одной из главных целей языка C++ являлось позволить программистам строить типы, определенные пользователем (user-defined types – UDTs), которые затем можно было бы использовать вне их исходного контекста. Этот принцип лег в основу идеи создания библиотек классов, или структур, какими мы знаем их сегодня. С момента появления C++ рынок библиотек классов C++ расширялся, хотя и довольно медленно. Одной из причин того. что этот рынок рос не так быстро, как можно было ожидать, был NIH-фактор (not invented here – «изобретен не здесь») среди разработчиков C++. Использовать код других разработчиков часто представляется более трудным, чем воспроизведение собственных наработок. Иногда это представление базируется исключительно на высокомерии разработчика. В других случаях сопротивление использованию чужого кода проистекает из неизбежности дополнительного умственного усилия, необходимого для понимания чужой идеологии и стиля программирования. Это особенно верно для библиотек-оберток (wrappers), когда необходимо понять не только технологию того, что упаковано, но и дополнительные абстракции, добавленные самой библиотекой.

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

Повторное использование (reuse) кода всегда было одной из классических мотиваций объектного ориентирования. Несмотря на это обстоятельство, написание классов C++, простых для повторного использования, довольно затруднительно. Помимо таких препятствий для повторного использования, как этап проектирования (design-time) и этап разработки (development-time), которые уже можно считать частью культуры C++, существует и довольно большое число препятствий на этапе выполнения (runtime), что делает объектную модель C++ далекой от идеала для создания программных продуктов повторного использования. Многие из этих препятствий обусловлены моделями компиляции и компоновки, принятой в C++. Данная глава будет посвящена техническим проблемам приведения классов C++ к виду компонентов повторного использования. Все задачи будут решаться методами программирования, которые базируются на готовых общедоступных (off-the-shelf) технологиях. В этой главе будет показано, как, применяя эти технологии, можно создать архитектуру для повторного использования модулей, которая позволяла бы динамично и эффективно строить системы из независимо сконструированных двоичных компонентов.

 

Распространение программного обеспечения и язык С++

Для понимания проблем, связанных с использованием C++ как набора компонентов, полезно проследить, как распространялись библиотеки C++ в конце 1980-х годов. Представим себе разработчика библиотек, который создал алгоритм поиска подстрок за время O (то есть время поиска постоянно, а не пропорционально длине строки). Это, как известно, нетривиальная задача. Для того чтобы сделать алгоритм возможно более простым для пользователя, разработчик должен создать класс строк, основанный на алгоритме, который будет быстро передавать текстовые строки (fast text strings) в любую программу клиента. Чтобы сделать это, разработчику необходимо подготовить заголовочный файл, содержащий определение класса:

// faststring.h

class FastString

{

char *mpsz;

public:

FastString(const char *psz);

~FastString(void);

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

//возвращает смещение

};

После того как класс определен, разработчик должен реализовать его функции-члены в отдельном файле:

// FastString.cpp

#include «faststring.h»

#include

FastString::FastString(const char *psz) : mpsz(new char [strlen(psz) + 1])

{ strcpy(mpsz, psz); }

FastString::~FastString(void)

{ delete[] mpsz; }

int FastString::Length(void) const

{ return strlen(mpsz); }

int FastString::Find(const char *psz) const

{

//O(1) lookup code deleted for> clarity

1

// код поиска 0(1) удален для ясности

}

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

Предположим, что для показанного выше класса FastString сгенерированный машинный код для четырех методов занял 16 Мбайт пространства в результирующем исполняемом файле. Напомним, что при выполнении O(1)-поиска может потребоваться много пространства для кода, чтобы обеспечить заданное время исполнения, – дилемма, которая ограничивает большинство алгоритмов. Как показано на рис. 1.1, если три приложения используют библиотеку FastString, то каждая из трех исполняемых программ будет включать в себя по 16 Мбайт кода. Это означает, что если конечный пользователь инсталлирует все три клиентских приложения, то реализация FastString займет 48 Мбайт дискового пространства. Хуже того – если конечный пользователь запустит все три клиентских приложения одновременно, то код FastString займет 48 Мбайт виртуальной памяти, так как операционная система не может обнаружить дублирующий код, имеющийся в каждой исполняемой программе.

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

 

Динамическая компоновка и С++

Один из путей решения этих проблем – упаковка класса FastString в динамически подключаемую библиотеку (Dynamic Link Library – DLL). Это может быть сделано несколькими способами. Простейший из них – использовать директиву компилятора, действующую на уровне классов, чтобы заставить все методы FastString экспортироваться из DLL. Компилятор Microsoft C++ предусматривает для этого ключевое слово _declspec(dllexport):

class _declspec(dllexport) FastString

{

char *m_psz;

public:

FastString(const char *psz);

~FastString(void);

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

};

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

Рисунок 1.2 иллюстрирует модель FastString на этапе выполнения (runtime model), объявляемую из DLL. Заметим, что библиотека импорта достаточно мала (примерно вдвое больше, чем суммарный размер экспортируемого символьного текста). Когда класс экспортируется из DLL, код FastString должен присутствовать на жестком диске пользователя только один раз. Если даже несколько клиентов применяют этот код для своей библиотеки, загрузчик операционной системы обладает достаточным интеллектом, чтобы разделить физические страницы памяти, содержащие исполняемый код FastString (только для чтения), между всеми клиентскими программами. Кроме того, если разработчик библиотеки найдет дефект в исходном коде, теоретически возможно послать новую DLL конечному пользователю, исправляя дефектную реализацию для всех клиентских приложений сразу. Ясно, что перемещение библиотеки FastString в DLL является важным шагом на пути превращения класса C++ в заменяемый и эффективный компонент повторного использования.

 

C++ и мобильность

Поскольку вы решили распространять классы C++ как DLL, вы непременно столкнетесь с одним из фундаментальных недостатков C++ – недостаточной стандартизацией на двоичном уровне. Хотя рабочий документ ISO/ANSI C++ Draft Working Paper (DWP) предпринимает попытку определить, какие программы будут транслироваться и каковы будут семантические эффекты при их запуске, двоичная динамическая модель C++ ею не стандартизируется. Впервые клиент сталкивается с этой проблемой при попытке скомпоновать библиотеку импорта DLL FastString из среды развития C++, отличной от той, в которой он привык строить эту DLL.

Для обеспечения перегрузки операторов и функций компиляторы C++ обычно видоизменяют символическое имя каждой точки входа, чтобы разрешить многократное использование одного и того же имени (или с различными типами аргументов, или в различных областях действия) без нарушения работы существующих компоновщиков для языка С. Этот прием часто называют коррекцией имени. Несмотря на то что ARM (C++ Annotated Reference Manual) документировала схему кодирования, использующуюся в CFRONT, многие разработчики трансляторов предпочли создать свою собственную схему коррекции. Поскольку библиотека импорта FastString и DLL экспортирует символы, используя корректирующую схему того транслятора, который создал DLL (то есть GNU C++), клиенты, скомпилированные другим транслятором (например, Borland C++), не могут быть корректно скомпонованы с библиотекой импорта. Классическая методика использования extern "С" для отключения коррекции символов не поможет в данном случае, так как DLL экспортирует функции-члены (методы), а не глобальные функции.

Для решения этой проблемы можно проделать фокусы с клиентским компоновщиком, применяя файл описания модуля (Module Definition File), известный как DEF-файл. Одно из свойств DEF-файлов заключается в том, что они позволяют экспортируемым символам совмещаться с различными импортируемыми символами. Имея достаточно времени и информации относительно каждой схемы коррекции, разработчик библиотек может создать особую библиотеку импорта для каждого компилятора. Это утомительно, но зато позволяет любому компилятору обеспечить совместимость с DLL на уровне компоновки, при условии, что разработчик библиотеки заранее ожидал ее использование и создал нужный DEF-файл.

Если вы разрешили проблемы, возникшие при компоновке, вам еще придется столкнуться с более сложными проблемами несовместимости, которые связаны со сгенерированным кодом. За исключением простейших языковых конструкций, разработчики трансляторов часто предпочитают реализовывать особенности языка своими собственными путями. Это формирует объекты, недоступные для кода, созданного любым другим компилятором. Классическим примером таких языковых особенностей являются исключительные ситуации (исключения). Исключительная ситуация в среде C++, исходящая от функции, которая была транслирована компилятором Microsoft, не может быть надежно перехвачена клиентской программой, оттранслированной компилятором Watcom. Это происходит потому, что DWP не может определить, как должна выглядеть та или иная особенность языка на этапе выполнения, поэтому для каждого разработчика компилятора вполне естественно реализовать такую языковую особенность в своей собственной, новаторской манере. Это несущественно при построении независимой однобинарной (single-binary) исполняемой программы, так как весь код будет транслироваться и компоноваться в одной и той же среде. При построении мультибинарных (multibinary) исполняемых программ, основанных на компонентах (component-based), это представляет серьезную проблему, так как каждый компонент может, очевидно, быть построен с использованием другого компилятора и компоновщика. Отсутствие двоичного стандарта в C++ ограничивает возможности того, какие особенности языка могут быть использованы вне границ DLL. Это означает, что простой экспорт функций-членов C++ из DLL недостаточен для создания независимого от разработчика набора компонентов.

 

Инкапсуляция и С++

Предположим, что вам удалось преодолеть проблемы с транслятором и компоновщиком, описанные в предыдущем разделе. Очередное препятствие при построении двоичных компонентов на C++ появится, когда вы будете проводить инкапсуляцию (encapsulation), то есть формирование пакета. Посмотрим, что получится, если организация, использующая FastString в приложении, возьмется выполнить невыполнимое: закончит разработку и тестирование за два месяца до срока рассылки продукта. Пусть также в течение этих двух месяцев некоторые из наиболее скептически настроенных разработчиков решили протестировать O(1) -поисковый алгоритм FastString , запустив профайлер своего приложения. К их большому удивлению, FastString::Find стала бы на самом деле работать очень быстро, независимо от заданной длины строки. Однако с оператором Length дело обстоит не столь хорошо, так как FastString::Length использует подпрограмму strlen из динамической библиотеки С. Эта подпрограмма – алгоритм O(n)– осуществляет линейный поиск по строкам с использованием символа конца строки (null terminator); скорость его работы пропорциональна длине строки. Столкнувшись с тем, что клиентское приложение может многократно вызывать оператор Length, один из таких скептиков, скорее всего, свяжется с разработчиком библиотеки и попросит его убыстрить Length, чтобы его работа также не зависела от длины строки. Но здесь есть одно препятствие. Разработчик библиотеки уже закончил свою разработку и, скорее всего, не расположен менять одну строку исходного кода, чтобы воспользоваться преимуществами улучшенного метода Length. Кроме того, некоторые другие разработчики, возможно, уже выпустили свои продукты, основанные на текущей версии FastString, и теперь разработчик библиотеки не имеет морального права изменять эти приложення.

С этой точки зрения нужно просто вернуться к определению класса FastString и решить, что можно изменить и что необходимо сохранить, чтобы уже установленная база успешно функционировала. К счастью, класс FastString был разработан с учетом возможности инкапсуляции, и все его элементы данных (data members ) являются закрытыми (private ). Это придает классу значительную гибкость, так как ни одна клиентская программа не может непосредственно получить доступ к элементам данных FastString. В силу того, что по отношению к четырем открытым (public ) членам класса не было сделано никаких изменений, то и в любом клиентском приложении никаких изменений также не потребуется. Вооружившись этой верой, разработчик библиотеки переходит к реализации FastString версии 2.0.

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

// faststring.h version 2.0

class declspec(dllexport) FastString {

const int mcch;

// count of characters

// число символов

char mpsz;

public:

FastString(const char *psz);

~FastString(void);

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset – возвращает смещение

};

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

FastString::FastString(const char *psz) : mcch(strlen(psz)), mpsz(new char[mcch + 1])

{

strcpy(mpsz, psz);

}

С введением кэшированной длины метод Length становится тривиальным:

int FastString::Length(void) const

{

return mcch;

// return cached length

// возвращает скрытую длину

}

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

Когда клиенты, заказавшие изменения, получают модернизированный FastString , они включают новое определение класса и DLL в систему контроля своего исходного кода и запускают тестирование нового и улучшенного FastString . Подобно разработчику библиотеки, они тоже приятно удивлены: для того, чтобы воспользоваться преимуществами новой версии Length , не требуется никаких модификаций исходного кода. Вдохновленная этим опытом, команда разработчиков убеждает начальство включить новую DLL в окончательный «золотой» CD, уже готовый для выпуска. Это тот редкий случай, когда руководство идет навстречу энтузиастам-разработчикам и включает в окончательный продукт новую DLL. Подобно большинству программ инсталляции, описание установки клиентской программы настроено на молчаливое (без предупреждения) замещение всех старых версий FastString DLL, какие есть на машине конечного пользователя. Это выглядит вполне безобидно, поскольку эти изменения не затронули открытый интерфейс класса, так что тотальная молчаливая модернизация под версию 2.0 FastString только улучшит любые имеющиеся клиентские приложения, которые были установлены раньше.

Представим себе следующий сценарий: конечные пользователи наконец-то получают свои экземпляры вожделенного продукта. Каждый из них тут же бросает все и устанавливает новое приложение на свою машину, дабы попробовать его. После того как высохли слезы восторга от того, что наконец-то можно делать быстрый текстовый поиск, пользователь возвращается к его или ее нормальному состоянию и запускает ранее установленное приложение, которое также имеет неосторожность использовать DLL FastString. Первые несколько минут всё идет хорошо. Затем внезапно появляется сообщение, что возникла исключительная ситуация и что вся работа конечного пользователя пропала. Он пытается запустить приложение снова, но на этот раз диалоговое окно об исключительной ситуации появляется почти сразу. Конечный пользователь, привычный к употреблению современного программного обеспечения, переустанавливает операционную систему и все приложения, но даже это не спасает от повторения исключительной ситуации. Что же произошло?

А произошло то, что разработчик библиотеки был убаюкан верой в то, что C++ поддерживает инкапсуляцию. Хотя C++ и поддерживает синтаксическую инкапсуляцию через свои закрытые и защищенные ключевые слова, в стандарте C++ ничего не сказано о двоичной инкапсуляции. Это происходит потому, что модель трансляции C++ требует, чтобы клиентский компилятор имел доступ ко всей информации относительно двоичного представления объектов, – с целью обработать экземпляр класса или делать невиртуальные вызовы метода. Это включает в себя информацию о размере и порядке закрытых и защищенных элементов данных объекта. Рассмотрим сценарий, показанный на рис. 1.3. Версия 1.0 FastString требует четыре байта на экземпляр (принимая sizeof(char *) == 4). Клиенты написанного под версию 1.0 определения класса выделяют четыре байта памяти под вызов конструктора класса. Конструктор, деструктор и методы версии 2.0 (а именно эти версии содержатся в DLL в машине конечного пользователя) ожидают, что клиент выделил восемь байт на экземпляр (принято sizeof(int) == 8), и не предусматривают собственных резервов для записи во все восемь байт. К сожалению, у клиентов с версией 1.0 вторые четыре байта этого объекта на самом деле принадлежат кому-то другому, и запись в это место указателя на текстовую строку недопустима, о чем и сообщает диалог исключительной ситуации.

Существует общее решение проблемы версий – переименовывать DLL всякий раз, когда появляется новая версия. Такая стратегия принята в Microsoft Foundation Classes (MFC). Когда номер версии включен в имя файла DLL (например, FastString10.DLL, FastString20.DLL), клиенты всегда загружают ту версию DLL, с которой они были сконфигурированы, независимо от присутствия в системе других версий. К сожалению, со временем, из-за недостаточного опыта в системном конфигурировании, число версий DLL, имеющихся в системе конечного пользователя, может превысить реальное число пользовательских приложений. Чтобы убедиться в этом, достаточно проверить системный каталог любого компьютера, проработавшего больше шести месяцев.

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

 

Отделение интерфейса от реализации

Концепция инкапсуляции основана на разделении того, как объект выглядит (его интерфейса), и того, как он в действительности работает (его реализации). Проблема в C++ в том, что этот принцип неприменим на двоичном уровне, так как класс C++ одновременно является и интерфейсом, и реализацией. Этот недостаток может быть преодолен, если смоделировать две новые абстракции, являющиеся классами C++, но различающиеся по своей сущности. Если определить один класс C++ как интерфейс для типа данных, а второй – как саму реализацию типа данных, то конструктор объектов теоретически может модифицировать некоторые детали класса реализации, в то время как класс интерфейса останется неизменным. Все, что нужно, – это выдержать соотношение интерфейса с его реализацией так, чтобы не показывать клиенту никаких деталей реализации.

Класс интерфейса должен содержать только такое описание основных типов данных, какое должен, по мнению разработчика, представлять себе клиент. Поскольку интерфейс не должен сообщать ни о каких деталях реализации, класс интерфейса C++ не может содержать никаких элементов данных, которые могут быть использованы в реализации объекта. Вместо этого класс интерфейса должен содержать только описания методов для каждой открытой операции объекта. Класс реализации C++ будет содержать фактические элементы данных, необходимые для обеспечения функционирования объекта. Одним из простейших подходов является использование класса-дескриптора (handle-class) в качестве интерфейса. Класс-дескриптор мог бы просто содержать непрозрачный (opaque) указатель, чей тип никогда не может быть полностью определен клиентом. Следующее определение класса демонстрирует эту технику:

// FastStringItf.h

class declspec(dllexport) FastStringItf

{

class FastString;

// introduce name of impl. class

// вводится имя класса реализации

FastString *mpThis;

// opaque pointer (size remains constant)

// непрозрачный указатель (размер остается постоянным)

public: FastStringItf(const char *psz);

~FastStringItf(void);

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

};

Заметим, что двоичное представление этого класса интерфейса не меняется с добавлением или удалением элементов данных из класса реализации FastString. Кроме того, использование опережающего объявления означает, что определение класса FastString не является необходимым для трансляции этого заголовочного файла. Это эффективно скрывает все детали реализации FastString от транслятора клиента. При использовании этого способа машинный код для методов интерфейса становится единственной точкой входа в DLL объекта, и их двоичные сигнатуры никогда не изменятся. Реализации методов класса интерфейса просто передают вызовы методов действующему классу реализации:

// faststringitf.срр

// (part of DLL, not client)

// (часть DLL, а не клиента)

#include «faststring.h»

#include «faststringitf.h»

FastStringItf::FastStringItf(const char *psz) : mpThis(new FastString(psz))

{ assert(mpThis != 0); }

FastStringItf::~FastStringItf(vo1d)

{ delete mpThis; }

int FastStringItf::Length(void) const

{ return mpThis->Length(); }

int FastStringItf::Find(const char *psz) const

{ return mpThis->Find(psz); }

Эти передающие методы должны быть транслированы как часть DLL FastString, так что когда двоичное представление класса реализации FastString меняется, вызов нового оператора в конструкторе FastStringItf будет сразу же перекомпилирован, если, конечно, зарезервировано достаточно памяти. И опять клиент не получит описания класса реализацииFastString. Это дает разработчику FastString возможность со временем развивать реализацию без прерывания существующих клиентов.

Рисунок 1.4 показывает, как использовать классы-дескрипторы для отделения интерфейса от реализации на этапе выполнения. Заметим, что косвенный подход, введенный классом интерфейса, устанавливает двоичную защитную стену (firewall – брандмауэр) между клиентом и реализацией объекта. Эта двоичная стена очень точно описывает, как клиент может сообщаться с реализацией. Все связи клиент-объект осуществляются через класс интерфейса, который содержит очень простой двоичный протокол для входа в область реализации объекта. Этот протокол не содержит никаких деталей класса реализации в C++.

Хотя методика использования классов-дескрипторов имеет свои преимущества и безусловно приближает нас к возможности безопасного извлечения классов из DLL, она также имеет свои недостатки. Отметим, что класс интерфейса вынужден явно передавать каждый вызов метода классу реализации. Для простого класса вроде FastString только с двумя открытыми операторами, конструктором и деструктором, это не проблема. Для большой библиотеки классов с сотнями или тысячами методов написание этих передающих процедур было бы весьма утомительным и явилось бы потенциальным источником ошибок. Кроме того, для областей с повышенными требованиями к эффективности программ (performance-critical domains), цена двух вызовов для каждого метода (один вызов на интерфейс, один вложенный вызов на реализацию) весьма высока. Наконец, методика классов-дескрипторов не полностью решает проблемы совместимости транслятора/компоновщика, а они все же должны быть решены, если мы хотим иметь основу, действительно пригодную для создания компонентов повторного использования.

 

Абстрактные базы как двоичные интерфейсы

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

1. передавать особенности языка на этапе выполнения;

2. символические имена будут представлены на этапе компоновки.

Если бы кто-нибудь придумал, как скрыть детали реализации транслятора/компоновщика за каким-либо двоичным интерфейсом, это сделало бы написанные на C++ библиотеки DLL значительно более широко используемыми.

Двоичная защита, то есть тот факт, что класс интерфейса C++ не использует языковых конструкций, зависящих от транслятора, решает проблему зависимости от транслятора/компоновщика. Чтобы сделать эту независимость более полной, необходимо в первую очередь определить те аспекты языка, которые имеют одинаковую реализацию в разных трансляторах. Конечно, представление на этапе выполнения таких сложных типов, как С-структуры (structs), может быть выдержано инвариантным по отношению к трансляторам. Это – основное, что должен делать системный интерфейс, основанный на С, и иногда это достигается применением условно транслируемых определений типа прагм (pragmas) или других директив транслятора. Второе, что следует сделать, – это заставить все компиляторы проходить параметры функций в одном и том же порядке (слева направо, справа налево) и зачищать стек также одинаково. Подобно совместимости структур, это также решаемая задача, и для унификации работы со стеком часто используются условные директивы транслятора. В качестве примера можно привести макросы WINAPI/WINBASEAPI из Win32 API. Каждая извлеченная из системных DLL функция определена с помощью этих макросов:

WINBASEAPI void WINAPI Sleep(DWORD dwMsecs);

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

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

class calculator

{

public: virtual void add1(short x);

virtual void add2(short x, short y);

};

Все трансляторы с данной платформой должны создать эквивалентные последовательности машинного кода для следующего фрагмента программы пользователя:

extern calculator *pcalc;

pcalc->add1(1);

pcalc->add2(1, 2);

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

Впрочем, это не такое уж блестящее решение проблемы, как может показаться. Реализация виртуальных функций на C++ на этапе выполнения выливается в создание конструкций vptr и vtbl практически на всех трансляторах. При этой методике транслятор молча генерирует статический массив указателей функций для каждого класса, содержащего виртуальные функции. Этот массив называется vtbl (virtual function table – таблица виртуальных функций) и содержит один указатель функции для каждой виртуальной функции, определенной в данном классе или в ее базовом классе. Каждый объект класса содержит единственный невидимый элемент данных, именуемый vptr (virtual function pointer – указатель виртуальных функций); он автоматически инициализируется конструктором для указания на таблицу vtbl класса. Когда клиент вызывает виртуальную функцию, транслятор генерирует код, чтобы разыменовать указатель vptr , занести его в vtbl и вызвать функцию через ее указатель, найденный в назначенном месте. Так на C++ обеспечивается полиморфизм и диспетчеризация динамических вызовов. Рисунок 1.5 показывает представление на этапе выполнения массивов vptr/vtbl для класса calculator, рассмотренного выше.

Фактически каждый действующий в настоящее время качественный транслятор C++ использует базовые концепции vprt и vtbl. Существует два основных способа размещения таблицы vtbl: с помощью CFRONT и корректирующего переходника (adjuster thunk). Каждый из этих приемов имеет свой способ обращения с тонкостями множественного наследования. К счастью, на каждой из имеющихся платформ доминирует один из способов (трансляторы Win32 используют adjuster thunk, Solaris – стиль CFRONT для vtbl ). К тому же формат таблицы vtbl не влияет на исходный код C++, который пишет программист, а скорее является артефактом сгенерированного кода. Желающие узнать подробности об этих двух способах могут обратиться к прекрасной книге Стэна Липпмана «Объектная модель C++ изнутри» (Stan Lippman. Inside C++ Object Model).

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

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

// ifaststring.h

class IFastString

{

public: virtual int Length(void) const = 0;

virtual int Find(const char *psz) const = 0;

};

Определение этих методов как чисто виртуальных также дает знать транслятору, что от класса интерфейса не требуется никакой реализации этих методов. Когда транслятор генерирует таблицу vtbl для класса интерфейса, входная точка для каждой простой виртуальной функции является или нулевой (null), или точкой входа в С-процедуру этапа выполнения (_purecall в Microsoft C++), которая при вызове генерирует логическое утверждение. Если бы метод не был определен как чисто виртуальный, транслятор попытался бы включить в соответствующую входную точку vtbl системную реализацию метода класса интерфейса, которая в действительности не существует. Это вызвало бы ошибку компоновки. Определенный таким образом класс интерфейса является абстрактным базовым классом. Соответствующий класс реализации должен порождаться классом интерфейса и перекрывать все чисто виртуальные фyнкции содержательными реализациями. Эта наследственная связь проявится в объектах, которые в качестве своего представления имеют двоичное надмножество представления класса интерфейса (которое как раз и есть vptr/vtbl). Дело в том, что отношение «является» («is-a») между порождаемым и базовым классами применяется на двоичном уровне в C++ так же, как и на уровне моделирования в объектно-ориентированной разработке:

class FastString : public IFastString

{

const int m_cch;

// count of characters

// число символов

char *m_psz;

public:

FastString(const char *psz);

~FastString(void);

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

};

Поскольку FastString порождается от IFastString, двоичное представление объектов FastString должно быть надмножеством двоичного представления IFastString. Это означает, что объекты FastString будут содержать указатель vptr, указывающий на совместимую с таблицей vtblIFastString. Поскольку классу FastString можно приписывать различные конкретные типы данных, его таблица vtbl будет содержать указатели на существующие реализации методов Length и Find. Их связь показана на рис. 1.6.

Даже несмотря на то, что открытые операторы над типами данных подняты до уровня чисто виртуальных функций в классе интерфейса, клиент не может приписывать значения объектам FastString, не имея определения класса для класса реализации. При демонстрации клиенту определения класса реализации от него будет скрыта двоичная инкапсуляция интерфейса; что не позволит клиенту использовать класс интерфейса. Одним из разумных способов обеспечить клиенту возможность использовать объекты FastString является экспорт из DLL глобальной функции, которая будет вызывать новый оператор от имени клиента. При условии, что эта подпрограмма экспортируется с опцией extern "С" , она будет доступна для любого транслятора C++.

// ifaststring.h

class IFastString {

public:

virtual int Length(void) const = 0;

virtual int Find(const char *psz) const = 0;

};

extern "C"

IFastString *CreateFastString(const char *psz);

// faststring.cpp (part of DLL)

// faststring.cpp (часть DLL)

IFastString *CreateFastString (const char *psz)

{ return new FastString(psz); }

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

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

int f(void)

{

IFastString *pfs = CreateFastString(«Deface me»);

int n = pfs->Find(«ace me»);

delete pfs;

return n;

}

Непредсказуемое поведение вызвано тем фактом, что деструктор класса интерфейса не является виртуальным. Это означает, что вызов оператора delete не сможет динамически найти последний порожденный деструктор и рекурсивно уничтожит объект ближайшего внешнего типа по отношению к базовому типу. Поскольку деструктор FastString никогда не вызывается, в данном примере из буфера исчезнет строка «Deface me», которая должна там присутствовать.

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

// ifaststring.h

class IFastString

{

public:

virtual void Delete(void) = 0;

virtual int Length(void) const = 0;

virtual int Find(const char *psz) const = 0;

};

extern "C"

IFastString *CreateFastString (const char *psz);

она влечет за собой соответствующее определение класса реализации:

// faststring.h

#include «ifaststring.h»

class FastString : public IFastString

{ const int mcch;

// count of characters

// счетчик символов

char *mpsz; public: FastString(const char *psz);

~FastString(void);

void Delete(void);

// deletes this instance

// уничтожает этот экземпляр

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

};

// faststring.cpp

#include

#include «faststring.h»

IFastString* CreateFastString (const char *psz) {

return new FastString(psz);

}

FastString::FastString(const char *psz) : mcch(strlen(psz)), mpsz(new char[mcch + 1]) {

strcpy(mpsz, psz);

}

void FastString::Delete(void) {

delete this;

}

FastString::~FastString(void) {

delete[] mpsz;

}

int FastString::Lengtn(void) const {

return mcch;

}

int FastString::Find(const char *psz) const {

// O(1) lookup code deleted for clarity

// код поиска 0(1) уничтожен для ясности

}

Рисунок 1.7 показывает представление FastString на этапе выполнения. Чтобы использовать тип данных FastString, клиентам надо просто включить в программу файл определения интерфейса и вызвать CreateFastString:

#include «ifaststring.h»

int f(void)

{ int n = -1;

IFastString *pfs = CreateFastString(«Hi Bob!»);

if (pfs) { n = pfs->Find(«ob»);

pfs->Delete(); }

return n; }

Отметим, что все, кроме одной, точки входа в DLL FastString являются виртуальными функциями. Виртуальные функции класса интерфейса всегда вызываются косвенно, через указатель функции, хранящийся в таблице vtbl , избавляя клиента от необходимости указывать их символические имена на этапе разработки. Это означает, что методы интерфейса защищены от различий в коррекции символических имен на разных трансляторах. Единственная точка входа, которая явно компонуется по имени, – это CreateFastString – глобальная функция, которая обеспечивает клиенту доступ в мир FastString. Заметим, однако, что эта функция была экспортирована с опцией extern "С", которая подавляет коррекцию символов. Следовательно, все трансляторы C++ ожидают, что импортируемая библиотека и DLL экспортируют один и тот же идентификатор. Полезным результатом этой методики является то, что вы можете спокойно извлечь класс из DLL, использующей одну среду C++, а обратиться к этому классу из любой другой среды C++. Эта возможность необходима при построении основы для независимых от разработчика компонентов повторного пользования.

 

Полиморфизм на этапе выполнения

Управление реализациями классов с использованием абстрактных базовых классов как интерфейсов открывает целый мир новых возможностей в терминах того, что может случиться на этапе выполнения. Напомним, что DLL FastString экспортирует только один идентификатор – CreateFastString. Теперь пользователю легко динамически загрузить DLL, используя по требованию LoadLibrary, и разрешить этой единственной точке входа использовать GetProcAddress:

IFastString *CallCreateFastString(const char *psz)

{

static IFastString * (*pfn)(const char *) = 0;

if (!pfn) {

// init ptr 1st time through

// первое появление ptr

const TCHAR szDll[] = TEXT(«FastString.DLL»);

const char szFn[] = «CreateFastString»;

HINSTANCE h = LoadLibrary(szDll);

if (h) *(FARPROC*)&pfn = GetProcAddress(h, szFn); }

return pfn ? pfn(psz) : 0;

}

Эта методика имеет несколько возможных приложений. Одна из причин ее использования – предотвращение ошибок, генерируемых операционной системой при работе на машине, где не установлена реализация объектов. Приложения, использующие дополнительные системные компоненты, такие как WinSock или MAPI, используют похожую технику для запуска приложений на машинах с минимальной конфигурацией. Поскольку клиенту никогда не нужно компоновать импортируемую библиотеку DLL, он не зависит от загрузки DLL и может работать на машинах, на которых DLL вообще не установлена. Другой причиной для использования этой методики может быть медленная инициализация адресного пространства. Кроме того, DLL не загружается автоматически во время инициализации; и если в действительности реализация объекта не используется, то DLL не загрузится никогда. Другими преимуществами этого способа являются ускорение запуска клиента и сохранение адресного пространства для длительных процессов, которые могут никогда реально не использовать DLL.

Возможно, одним из наиболее интересных применений этой методики является возможность для клиента динамически выбирать между различными реализациями одного и того же интерфейса. Если описание интерфейса IFastString дано как общедоступное (publicly available), то ничто не препятствует как исходному конструктору (implementor) FastString, так и любым сторонним средствам реализации порождать дополнительные классы реализации от того же самого интерфейса. Подобно исходной реализации класса FastString, эти новые реализации будут иметь такое двоичное представление, что будут совместимы на двоичном уровне с исходным классом интерфейса. Все, что должен сделать пользователь, чтобы добиться полностью совместимых («plug-compatible») реализаций, – это определить правильное имя файла для желаемой реализации DLL.

Чтобы понять, как применить эту методику, предположим, что исходная реализация IFastString выполняла поиск слева направо. Это прекрасно для языков, анализируемых слева направо (например, английский, французский, немецкий). Для языков, анализируемых справа налево, предпочтительней вторая реализация IFastString, осуществляющая поиск справа налево. Эта альтернативная реализация может быть построена как вторая DLL с характерным именем (например, FastStringRL.DLL). Пусть обе DLL установлены на машине конечного пользователя, тогда он может выбрать нужный вариант IFastString простой загрузкой требуемой DLL на этапе выполнения:

IFastString * CallCreateFastString(const char *psz, bool bLeftToRight = true)

{

static IFastString * (*pfnlr)(const char *) = 0;

static IFastString * (*pfnrl)(const char *) = 0;

IFastString *(**ppfn) (const char *) = &pfnlr;

const TCHAR *pszDll = TEXT(«FastString.DLL»);

if (!bLeftToRight) { pszDll = TEXT(«FastStringRL.DLL»);

ppfn = &pfnrl; }

if (!(*ppfn)) {

// init ptr 1st time through

// первое появление ptr

const char szFn[] = «CreateFastString»;

HINSTANCE h = LoadLibrary(pszDll);

if (h) *(FARPROC*)ppfn = GetProcAddress(h, szFn); }

return (*ppfn) ? (*ppfn)(psz) : 0;

}

Когда клиент вызывает функцию без второго параметра,

pfs = CallCreateFastString(«Hi Bob!»);

n = pfs->Find(«ob»);

то загружается исходная DLL FastString, и поиск идет слева направо. Если же клиент указывает, что строка написана на разговорном языке, анализируемом справа налево:

pfs = CallCreateFastString(«Hi Bob!», false);

n = pfs->Find(«ob»);

то загружается альтернативная версия DLL (FastStringRL.DLL ), и поиск будет начинаться с крайней правой позиции строки. Главное здесь то, что вызывающие операторы CallCreateFastString не заботятся о том, какая из DLL используется для реализации методов объекта. Существенно лишь то, что указатель на совместимый с IFastString vptr возвращается функцией и что vptr обеспечивает успешное и семантически корректное функционирование. Эта форма полиморфизма на этапе выполнения чрезвычайно полезна при создании системы, динамически скомпонованной из двоичных компонентов.

 

Расширяемость объекта

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

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

class IFastString {

public:

virtual void Delete(void) = 0;

virtual int Length(void) = 0;

virtual int Find(const char *psz) = 0;

};

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

class IFastString {

public:

// faux version 1.0

// фиктивная версия 1.0

virtual void Delete(void) = 0;

virtual int Length(void) = 0;

virtual int Find(const char *psz) = 0;

// faux version 2.0

// фиктивная версия 2.0

virtual int FindN(const char *psz, int n) = 0;

};

Это решение почти работает. Те клиенты, у которых оттранслирована исходная версия интерфейса, остаются в счастливом неведении относительно всех составляющих таблицы vtbl, кроме первых трех. Когда старые клиенты получают обновленные объекты, имеющие в vtbl вход для FindN, они продолжают нормально работать. Проблема возникает, когда новым клиентам, ожидающим, что IFastString имеет четыре метода, случится столкнуться с устаревшими объектами, где метод FindN не реализуется. Когда клиент вызовет FindN на объект, странслированный с исходным описанием интерфейса, результаты будут вполне определенными. Программа прервет работу.

В этой методике проблема заключается в том, что она нарушает инкапсуляцию объекта, изменяя открытый интерфейс. Подобно тому, как изменение открытого интерфейса в классе C++ может вызвать ошибки на этапе трансляции, когда происходит перестройка клиентского кода, так и изменение двоичного описания интерфейса вызовет ошибки на этапе выполнения, когда клиентская программа перезапущена. Это означает, что интерфейсы должны быть неизменяемыми с момента первой редакции. Решение этой проблемы заключается в том, чтобы разрешить классу реализации выставлять более чем один интерфейс. Этого можно достигнуть, если предусмотреть, что один интерфейс порождается от другого, связанного с ним интерфейса. А можно сделать так, чтобы класс реализации наследовал от нескольких несвязанных классов интерфейса. В любом случае клиент мог бы использовать имеющуюся в C++ возможность определения типа на этапе выполнения – идентификацию Runtime Type Identification – RTTI, чтобы динамически опросить объект и убедиться в том, что его требуемая функциональность действительно поддерживается уже работающим объектом.

Рассмотрим простой случай интерфейса, расширяющего другой интерфейс. Чтобы добавить в IFastString операцию FindN, позволяющую находить n–е вхождение подстроки, необходимо породить второй интерфейс от IFastString и добавить в него новое описание метода:

class IFastString2 : public IFastString {

public: // real version 2.0

// настоящая версия 2.0

virtual int FindN(const char *psz, int n) = 0;

};

Клиенты могут с уверенностью динамически опрашивать объект с помощью оператора C++ dynamic_cast, чтобы определить, является ли он совместимым с IFastString2

int Find10thBob(IFastString *pfs) {

IFastString2 *pfs2 = dynamic_cast(pfs);

if(pfs2)

// the object derives from IFastString2

// объект порожден от IFastString2

return pfs2->FindN(«Bob», 10);

else {

// object doesn't derive from IFastString2

// объект не порожден от IFastString2

error(«Cannot find 10th occurrence of Bob»);

return -1;

}

Если объект порожден от расширенного интерфейса, то оператор dynamic_cast возвращает указатель на вариант объекта, совместимый с IFastString2, и клиент может вызвать расширенный метод объекта. Если же объект не порожден от расширенного интерфейса, то оператор dynamic_cast возвратит пустой (null) указатель. В этом случае клиент может или выбрать другой способ реализации, зарегистрировав сообщение об ошибке, или молча продолжить без расширенной операции. Эта способность назначенного клиентом постепенного сокращения возможностей очень важна при создании гибких динамических систем, которые могут обеспечить со временем расширенные функциональные возможности.

Иногда требуется раскрыть еще один аспект функциональности объекта, тогда разворачивается еще более интересный сценарий. Обсудим, что следует предпринять, чтобы добавить постоянства, или персистентности (persistence), классу реализации IFastString. Хотя, вероятно, можно добавить методы Load и Save к расширенной версии IFastString, другие типы объектов, не совместимые с IFastString, могут тоже быть постоянными. Простое создание нового интерфейса, который расширяет IFastString:

class IPersistentObject : public IFastString

{

public: virtual bool Load(const char *pszFileName) = 0;

virtual bool Save(const char *pszFileName) = 0;

};

требует, чтобы все постоянные объекты поддерживали также операции Length и Find. Для некоторого, весьма малого подмножества объектов это могло бы иметь смысл. Однако для того, чтобы сделать интерфейс IPersistentObject возможно более общим, он должен быть своим собственным интерфейсом, а не порождаться от IFastString:

class IPersistentObject

{

public: virtual void Delete(void) = 0;

virtual bool Load(const char *pszFileName) = 0;

virtual bool Save(const char *pszFileName) = 0;

};

Это не мешает реализации FastString стать постоянной; это просто означает, что постоянная версия FastString должна поддерживать оба интерфейса: и IFastString, и IPersistentObject:

class FastString : public IFastString, public IPersistentObject

{

int m_cch;

// count of characters

// счетчик символов

char *m_psz;

public: FastString(const char *psz);

~FastString(void);

// Common methods

// Общие методы

void Delete(void);

// deletes this instance

// уничтожает этот экземпляр

// IFastString methods

// методы IFastString

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

// IPersistentObject methods

// методы IPersistentObject

bool Load(const char *pszFileName);

bool Save(const char *pszFileName);

};

Чтобы записать FastString на диск, пользователю достаточно с помощью RTTI связать указатель с интерфейсом IPerststentObject, который выставляется объектом:

bool SaveString(IFastString *pfs, const char *pszFN)

{

bool bResult = false;

IPersistentObject *ppo = dynamic_cast(pfs);

if (ppo) bResult = ppo->Save(pszFN);

return bResult;

}

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

RTTI – особенность, сильно зависящая от транслятора. В свою очередь, DWP передает синтаксис и семантику RTTI, но каждая реализация RTTI разработчиком транслятора уникальна и запатентована. Это обстоятельство серьезно подрывает независимость от транслятора, которая была достигнута путем использования абстрактных базовых классов как интерфейсов. Это является неприемлемым для архитектуры компонентов, не зависимой от разработчиков. Удачным решением было бы упорядочение семантики dynamic_cast без использования свойств языка, зависящих от транслятора. Явное выставление хорошо известного метода из каждого интерфейса, представляющего семантический эквивалент dynamic_cast, позволяет достичь желаемого эффекта, не требуя, чтобы все объекты использовали тот же самый транслятор C++:

class IPersistentObject

{

public: virtual void *Dynamic_Cast(const char *pszType) = 0;

virtual void Delete(void) = 0;

virtual bool Load(const char *pszFileName) = 0;

virtual bool Save(const char *pszFileName) = 0;

};

class IFastString

{

public: virtual void *Dynamic_Cast(const char *pszType) = 0;

virtual void Delete(void) = 0;

virtual int Length(void) = 0;

virtual int Find(const char *psz) = 0;

};

Так как всем интерфейсам необходимо выставить этот метод вдобавок к уже имеющемуся методу Delete, имеет большой смысл включить общее подмножество методов в базовый интерфейс, из которого могли бы порождаться все последующие интерфейсы:

class IExtensibleObject { public: virtual void *Dynamic_Cast(const char* pszType) = 0; virtual void Delete(void) = 0; }; class IPersistentObject : public IExtensibleObject { public: virtual bool Load(const char *pszFileName) = 0; virtual bool Save(const char *pszFileName) = 0; }; class IFastString : public IExtensibleObject { public: virtual int Length(void) = 0; virtual int Find(const char *psz) = 0; };

Имея такую иерархию типов, пользователь может динамически запросить объект о данном интерфейсе с помощью следующей не зависящей от транслятора конструкции:

bool SaveString(IFastString *pfs, const char *pszFN) { boot bResult = false; IPersistentObject *ppo = (IPersistentObject) pfs->Dynamic_Cast(«IPers1stentObject»); if (ppo) bResult = ppo->Save(pszFN); return bResult; }

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

class FastString : public IFastString, public IPersistentObject

{

int m_cсh;

// count of characters

// счетчик символов

char *m_psz;

public:

FastString(const char *psz);

~FastString(void);

// IExtensibleObject methods

// методы IExtensibleObject

void *Dynamic_Cast(const char *pszType);

void Delete(void);

// deletes this instance

// удаляет этот экземпляр

// IFastString methods

// методы IFastString

int Length(void) const;

// returns # of characters

// возвращает число символов

int Find(const char *psz) const;

// returns offset

// возвращает смещение

// IPersistentObject methods

// методы IPersistentObject

bool Load(const char *pszFileName);

bool Save(const char *pszFileName);

};

Реализации Dynamic_Cast необходимо имитировать действия RTTI путем управления иерархией типов объекта. Рисунок 1.8 иллюстрирует иерархию типов для только что показанного класса FastString. Поскольку класс реализации порождается из каждого интерфейса, который он выставляет, реализация Dynamic_Cast в FastString может просто использовать явные статические приведения типа (explicit static casts), чтобы ограничить область действия указателя this, основанного на подтипе, который запрашивается клиентом:

void *FastString::Dynam1c_Cast(const char *pszType)

{

if (strcmp(pszType, «IFastString») == 0) return static_cast(this);

else if (strcmp(pszType, «IPersistentObject») == 0) return static_cast(this);

else if (strcmp(pszType, «IExtensibleObject») == 0) return static_cast(this);

else return 0;

// request for unsupported interface

// запрос на неподдерживаемый интерфейс

}

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

Отметим, что после запроса на общий базовый интерфейс IExtensibleObject реализация статически преобразуется в IFastString. Это происходит потому, что интуитивная версия (intuitive version) оператора

return static_cast(this);

неоднозначна, так как и IFastString, и IPersistentObject порождены от IExtensibleObject. Если бы IExtensibleObject был виртуальным базовым классом как для IFastString, так и для IPersistentObject, то данное преобразование не было бы неоднозначным и оператор бы оттранслировался. Тем не менее, применение виртуальных базовых классов добавляет на этапе выполнения ненужную сложность в результирующий объект и к тому же вносит зависимость от транслятора. Дело в том, что виртуальные базовые классы являются всего лишь особенностями языка C++, которые имеют несколько специфических реализации.

 

Управление ресурсами

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

void f(void)

{

IFastString *pfs = 0;

IPersistentObject *ppo = 0;

pfs = CreateFastString(«Feed BOB»);

if (pfs) {

ppo = (IPersistentObject *) pfs->DynamicCast(«IPersistentObject»);

if (!ppo) pfs->Delete();

else { ppo->Save(«C:\\autoexec.bat»);

ppo->Delete(); }

}

}

Хотя вначале объект был связан через свой интерфейс IFastString , клиентский код вызывает метод Delete через интерфейс IPersistentObject. С использованием свойства C++ о множественном наследовании это вполне допустимо, так как все таблицы vtbl , порожденные классом IExtensibleObject, укажут на единственную реализацию метода Delete . Теперь, однако, пользователь должен хранить информацию о том, какие указатели связаны с какими объектами, и вызывать Delete только один раз на объект. В случае простого кода, приведенного выше, это не слишком тяжелое бремя. Для более сложных клиентских кодов управление этими связями становится делом весьма сложным и чреватым ошибками. Одним из способов упрощения задачи пользователя является возложение ответственности за управление жизненным циклом объекта на реализацию. Кроме того, разрешение клиенту явно удалять объект вскрывает еще одну деталь реализации: тот факт, что объект находится в динамически распределяемой памяти (в «куче», on the heap).

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

class IExtensibleObject

{

public:

virtual void *DynamicCast (const char* pszType) =0;

virtual void Delete(void) = 0;

};

на

class IExtensibleObject

{

public:

virtual void *DynamicCast(const char* pszType) = 0;

virtual void DuplicatePointer(void) = 0;

virtual void DestroyPointer(void) = 0;

};

Разместив эти методы, все пользователи IExtensibleObject должны теперь придерживаться следующих двух соображений:

1) Когда указатель интерфейса дублируется, требуется вызов DuplicatePointer.

2) Когда указатель интерфейса более не используется, следует вызвать DestroyPointer.

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

class FastString : public IFastString,

public IPersistentObject

{

int mcPtrs;

// count of outstanding ptrs

// счетчик невыполненных указателей

public:

// initialize pointer count to zero

// сбросить счетчик указателя в нуль

FastString(const char *psz) : mcPtrs(0) { }

void DuplicatePointer(void)

{

// note duplication of pointer

// отметить дублирование указателя

++mcPtrs;

}

void DestroyPointer(void)

{

// destroy object when last pointer destroyed

// уничтожить объект, когда уничтожен последний указатель

if (-mcPtrs == 0) delete this;

}

: : :

};

Этот совершенно стандартный код мог бы просто быть включен в базовый класс или в макрос С-препроцессора, чтобы его могли использовать все реализации.

Чтобы поддерживать эти методы, все программы, которые манипулируют или управляют указателями интерфейса, должны придерживаться двух простых правил DuplicatePointer/DestroyPointer. Для реализации FastString это означает модификацию двух функций. Функция CreateFastString берет начальный указатель, возвращаемый новым оператором C++, и копирует его в стек для возврата клиенту. Следовательно, необходим вызов DuplicatePointer:

IFastString* CreateFastString(const char *psz)

{

IFastString *pfsResult = new FastString(psz);

if (pfsResult) pfsResult->DuplicatePointer();

return pfsResult;

}

Реализация копирует указатель и в другом месте – в методе Dynamic_Cast:

void *FastString::Dynamic_Cast(const char *pszType)

{

void *pvResult = 0;

if (strcmp(pszType, «IFastString») == 0) pvResult = static_cast(this);

else if (strcmp(pszType, «IPersistentObject») == 0) pvResult = static_cast(this); 

else if (strcmp(pszType, «IExtensibleObject») == 0) pvResult = static_cast(this);

else return 0;

// request for unsupported interface

// запрос на неподдерживаемый интерфейс

// pvResult now contains a duplicated pointer, so

// we must call DuplicatePointer prior to returning

// теперь pvResult содержит скопированный указатель,

// поэтому нужно перед возвратом вызвать DuplicatePointer

((IExtensibleObject*)pvResult)->DuplicatePo1nter();

return pvResult;

}

С этими двумя усовершенствованиями соответствующий код пользователя становится значительно более однородным и прозрачным:

void f(void)

{

IFastString *pfs = 0;

IPersistentObject *ppo = 0;

pfs = CreateFastString(«Feed BOB»);

if (pts) {

рро = (IPersistentObject *) pfs->DynamicCast(«IPersistentObject»);

if (ppo) { ppo->Save(«C:\\autoexec.bat»);

ppo->DestroyPointer(); }

pfs->DestroyPointer(); }

}

Поскольку каждый указатель теперь трактуется как автономный объект с точки зрения времени жизни, клиенту можно не интересоваться тем, какой указатель соответствует какому объекту. Вместо этого клиент просто придерживается двух простых правил и предоставляет объектам самим управлять своим временем жизни. При желании способ вызова DuplicatePointer и DestroyPointer можно легко скрыть за интеллектуальным указателем (smart pointer) C++.

Использование этой схемы вычисления ссылок позволяет объекту весьма единообразно выставлять множественные интерфейсы. Возможность выставления нескольких интерфейсов из одного класса реализации позволяет типу данных участвовать в различных контекстах. Например, новая постоянная подсистема могла бы определить собственный интерфейс для управления автозагрузкой и автозаписью объектов на некоторый специализированный носитель. Класс FastString мог бы добавить поддержку этих возможностей простым наследованием от постоянного интерфейса этой подсистемы. Добавление этой поддержки никак не повлияет на уже установленные базы клиентов, которые, может быть, используют прежний постоянный интерфейс для записи и загрузки строки на диск. Механизм согласования интерфейсов на этапе выполнения может служить краеугольным камнем для построения динамической системы из компонентов, которые могут изменяться со временем.

 

Где мы находимся?

Мы начали эту главу с простого класса C++ и рассмотрели проблемы, связанные с объявлением этого класса как двоичного компонента повторного использования. Первым шагом было употребление этого класса в качестве библиотеки Dynamic Link Library (DLL) для отделения физической упаковки этого класса от упаковок его клиентов. Затем мы использовали понятие интерфейсов и реализации для инкапсуляции элементов реализации типов данных за двоичной защитой, что позволило изменять двоичные представления объектов без необходимости перетрансляции клиентами. Затем, используя для определения интерфейсов подход абстрактного базового класса, эта защита приобрела форму указателя vptr и таблицы vtbl. Далее мы исследовали приемы для динамического выбора различных полиморфных реализаций данного интерфейса на этапе выполнения с использованием LoadLibrary и GetProcAddress. Наконец, мы использовали RTTI-подобную структуру для динамического опроса объекта с целью определить, действительно ли он использует нужный интерфейс. Эта структура предоставила нам методику расширения существующих версий интерфейса, а также возможность выставления нескольких несвязанных интерфейсов из одного объекта.

Короче, мы только что создали модель компонентных объектов (Component Object Model – СОМ).

 

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

Снова об интерфейсах и реализациях

 

Снова об интерфейсах и реализациях

Цель отделения интерфейса от реализации заключалась в сокрытии от клиента всех деталей внутренней работы объекта. Этот фундаментальный принцип предусматривал уровень косвенности, или изоляции (level of indirection), который позволял изменяться количеству или порядку элементов данных в реализации класса без перекомпиляции клиента. Кроме того, этот принцип позволял клиентам обнаруживать расширенную функциональность путем опроса объекта на этапе выполнения. И, наконец, этот принцип позволяет сделать библиотеку DLL независимой от транслятора C++, который используется клиентом.

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

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

Хотя C++ – чрезвычайно полезный язык программирования, существует множество областей программирования, где больше подходят другие языки. Но точно так же, как проблемы совместимости при компоновке можно решить путем обеспечения всех существующих компиляторов файлами определения модуля, возможно и перевести определение интерфейса с C++ на любые другие языки программирования. А так как двоичная сигнатура интерфейса есть просто сочетание vptr/vtbl, этот перевод может быть сделан для большой группы языков.

Проделывание этих языковых преобразований данных для всех известных интерфейсов потребовало бы огромного количества работы, а главное – невозможно успевать делать это для бурного потока языков программирования, которые индустрия программного обеспечения не устает изобретать чуть ли не каждую декаду. Идеально было бы написать сервисную программу, которая переводила бы определения класса C++ в некую абстрактную промежуточную форму. Из этой промежуточной формы такая программа могла бы преобразовывать данные для любого языка программирования, имеющего соответствующий выходной генератор (back-end generator). По мере того как новые языки приобретают значимость, могли бы добавляться новые выходные генераторы, и все ранее определенные интерфейсы смогли бы тотчас использоваться в совершенно новом контексте.

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

 

IDL

СОМ IDL базируется на языке определения интерфейсов основного открытого математического обеспечения удаленного вызова процедур в распределенной вычислительной среде – Open Software Foundation Distributed Computing Environment Remote Procedure Call (OSF DCE RPC). DCE IDL позволяет описывать удаленные вызовы процедур не зависящим от языка способом. Это дает возможность компилятору IDL генерировать код для работы в сети, который прозрачным образом (transparently), то есть незаметно для пользователя, переносит описанные операции на всевозможные сетевые средства сообщения. СОМ IDL просто добавляет некоторые расширения, специфические для СОМ, в DCE IDL для поддержки объектно-ориентированных понятий СОМ (например, наследование, полиморфизм). Не случайно, что когда обращение к объектам СОМ осуществляется через границу контекста выполнения или через границы между машинами, все связи клиент-объект используют MS-RPC (реализация DCE RPC, являющаяся частью Windows NT и Windows 95) как основное средство сообщения.

Win32 SDK включает в себя компилятор МIDL.ЕХЕ , который анализирует файлы СОМ IDL и генерирует несколько искусственных объектов – артефактов (artifacts). Как показано на рис. 2.1, MIDL генерирует совместимые с C/C++ заголовочные файлы, которые содержат определения абстрактного базового класса, соответствующие интерфейсам, описанным в исходном IDL-файле.

Эти заголовочные файлы также содержат совместимые с С, основанные на структурах определения (structure-based definitions), которые позволяют С-программам обращаться к интерфейсам, описанным на IDL, или обеспечивать их выполнение. То, что MIDL автоматически генерирует С/С++-заголовочный файл, означает, что ни один из СОМ-интерфейсов не нужно определять на C++ вручную. Исход определений из одной точки исключает возникновение множества несовместимых версий определений интерфейсов, которые со временем могут вызвать асинхронность. MIDL также генерирует исходный код, который позволяет использовать интерфейсы в различных потоках, процессах и машинах. Этот код будет обсуждаться в главе 5. И наконец, MIDL может генерировать двоичный файл, который позволяет другим средам, принимающим СОМ, отображать интерфейсы, определенные в исходном IDL-файле, на другие языки. Этот двоичный файл называется библиотекой типа (type library) и содержит разобранный файл IDL в наиболее эффективной для анализа форме. Библиотеки типа обычно распространяются как часть исполняемого файла реализации и позволяют таким языкам, как Visual Basic, Java, Object Pascal использовать интерфейсы, которые выставляются этой реализацией.

Чтобы понять IDL, необходимо рассмотреть логический и физический аспекты интерфейса. Обсуждение методов интерфейса и выполняемых ими операций относятся к логическому аспекту интерфейса. Обсуждение памяти, стекового фрейма, сетевых пакетов и других динамических явлений обычно относятся к физическому аспекту интерфейса. Некоторые физические аспекты интерфейса могут непосредственно наследовать логическому описанию (например, расположение таблицы vtbl , порядок параметров в стеке). Другие физические аспекты (например, границы массивов, сетевые представления сложных типов данных) требуют дополнительной квалификации.

IDL позволяет разработчикам интерфейса работать непосредственно в сфере логики, используя синтаксис С. Но в то же время IDL требует от разработчиков точно определять все те аспекты интерфейса, которые не могут быть воспроизведены непосредственно по их логическому описанию на С, с помощью использования аннотаций, формально называемых атрибутами. Атрибуты IDL легко распознать в основном тексте IDL: разделенные запятыми, они заключены в скобки. Атрибуты всегда предшествуют описанию объекта, к которому они относятся. Например, в следующем IDL– фрагменте

[

v1enum, helpstring(«This is a color!»)

]

enum COLOR { RED, GREEN, BLUE };

атрибут v1_enum относится к описанию перечисления (enumeration) COLOR. Этот атрибут информирует компилятор IDL о том, что представление COLOR при передаче значения через сеть должно иметь 32 бита, а не 16, как принято по умолчанию. Атрибут helpstring также относится к СОLОR и добавляет строку «This is a color!» («Это – цвет!») в создаваемую библиотеку типа как описание этого перечисления. Если игнорировать атрибуты в IDL-файле, то его синтаксис такой же, как в С. IDL поддерживает структуры, объединения, массивы, перечисления, а также определения типа (typedef) – с синтаксисом, идентичным их аналогам в С.

Определяя методы СОМ в IDL, необходимо четко указать, кто – вызывающий или вызываемый объект – будет записывать или читать каждый параметр метода. Это выполняется с помощью атрибутов параметра [in] и [out]:

void Method1([in] long arg1, [out] long *parg2, [in, out] long *parg3);

Для этого фрагмента IDL предполагается, что вызывающий объект передаст значение в объект arg1 и по адресу, содержащемуся в указателе parg3. По завершении возвращаемые значения будут получены вызывающим объектом по адресам, указанным в parg2 и parg3. Это означает, что для последовательности вызовов:

long arg2 = 20, arg3 = 30;

p->Method1(10, &arg2, &arg3);

объект не может полагаться на получение передаваемого значения 20 через parg2. Если объект запускается в том же контексте выполнения, что и вызывающий объект, и оба участника вызова реализованы на C++, то *parg2 действительно будет иметь на входе метода значение 20. Однако если объект вызывается из другого контекста выполнения или один из участников вызова реализован на языке, который сводит на нет оптимизацию начальных значений чисто выходных (out-only) параметров, то инициализация параметра вызывающим объектом будет утеряна.

 

Методы и их результаты

Результаты методов – это одна из сторон СОМ, где логический и физический миры расходятся. В сущности, все методы СОМ физически возвращают номер ошибки с типом НRESULT. Использование одного типа возвращаемого результата позволяет удаленной COM-архитектуре перегружать результат выполнения метода, а также сообщать об ошибках соединения, просто зарезервировав ряд величин для RPC-ошибок. Величины НRESULT представляют собой 32-битные целые числа, которые передают в вызывающий контекст выполнения информацию о типе ошибок, которые могут произойти (например, ошибки сети, сбои сервера). Во многих языках, поддерживающих СОМ (например, Visual Basic, Java), HRESULT–значения перехватываются контекстом выполнения или виртуальной машиной и преобразуются в программные исключения (programmatic exceptions).

Как показано на рис. 2.2, HRESULT-значения состоят из трех битовых полей: бита серьезности ошибки (severity bit), кода устройства и информационного кода. Бит серьезности ошибки показывает, успешно выполнена операция или нет, код устройства индицирует, к какой технологии относится HRESULT , а информационный код представляет собой точный результат в рамках заданной технологии и серьезности. Заголовки SDK (software development kit – набор инструментальных средств разработки программного обеспечения) определяют два макроса, облегчающие работу с HRESULT:

#define SUCCEEDED(hr) (long(hr) >= 0) #def1ne FAILED(hr) (long(hr) < 0)

Эти два макроса используют тот факт, что при трактовке НRESULT как целого числа со знаком бит серьезности ошибки он является также знаковым битом.

Заголовки SDK содержат определения всех стандартных HRESULT. Эти HRESULT имеют символические имена, соответствующие трем компонентам HRESULT, и используются в следующем формате:

__

Например, HRESULT с именем STG_S_CONVERTED показывает, что кодом устройства является FACILITY_STORAGE. Это означает, что результат относится к структурированному хранилищу (Structured Storage) или к персистентности (Persistence). Код серьезности ошибки – SEVERITY_SUCCESS. Это означает, что вызов смог успешно выполнить операцию. Третья составляющая – CONVERTED – означает, что в данном случае было произведено преобразование базового файла для поддержки структурированного хранилища. HRESULT-значения, являющиеся универсальными и не привязанными к определенной технологии, используют FACILITY_NULL, и их символическое имя не содержит префикса кода устройства. Вот некоторые стандартные имена HRESULT-значений с кодом FACILITY_NULL:

S_OK – успешная нормальная операция

S_FALSE – используется для возвращения логического false в случае успеха

E_FAIL – общий сбой E_NOTIMPL – метод не реализован

E_UNEXPECTED – метод вызван в неподходящее время

FACILITY_ITF используется в специфически интерфейсных HRESULT-значениях и является в то же время единственным допустимым кодом устройства для HRESULT, определяемых пользователем. При этом значения FACILITY_ITF должны быть уникальными в контексте каждого отдельного интерфейса. Стандартные заголовки определяют макрос MAKE_HRESULT для определения пользовательского HRESULT из трех необходимых полей:

const HRESULT CALC_E_IAMHOSED = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF, 0х200 + 15);

Для пользовательских HRESULT принято соглашение, что значения информационного кода должны превышать 0х200 , чтобы избежать повторного использования значений, уже задействованных в системных HRESULT -значениях. Хотя это не опасно, таким образом предотвращается повторное использование значений, уже имеющих смысл для стандартных интерфейсов. Например, большинство HRESULT имеют текстовые описания для пользователя, которые можно получить на этапе выполнения с помощью функции API FormatMessage. Выбор HRESULT, не пересекающихся со значениями, определенными в системе, служит гарантией того, что неверные сообщения об ошибках не будут получены.

Чтобы позволить методам возвращать логический результат, не имеющий отношения к их физическому HRESULT -значению, язык СОМ IDL поддерживает атрибут параметров retval . Атрибут retval показывает, что соответствующий параметр физического метода в действительности является логическим результатом операции и, если контекст это позволяет, должен быть представлен как результат операции. Рассмотрим IDL-описание следующего метода:

HRESULT Method2([in] short arg1, [out, retval] short *parg2);

на языке Java это соответствует:

public short Method2(short arg1);

в то время как Visual Basic дает такое описание метода:

Function Method2(arg1 as Integer) As Integer

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

virtual HRESULT stdcall Method2(short arg1, short *parg2) = 0;

Это значит, что следующий клиентский код на языке C++:

short sum = 10;

short s;

HRESULT hr = pItf->Method2(20, &s);

if (FAILED(hr)) throw hr;

sum += s;

примерно эквивалентен такому Java-коду:

short sum == 10; short s = Itf.Method2(20); sum += s;

Если HRESULT, возвращенный методом, сообщает об аварийном результате, то Java Virtual Machine преобразует HRESULT в исключение Java. Во фрагменте кода на языке C++ необходимо проверить вручную HRESULT, возвращенный этим методом, и соответствующим образом обработать этот аварийный результат.

 

Интерфейсы и IDL

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

[ attribute1, attribute2, …]

interface IThisInterface : IBaseInterface

{

typedef1;

typedef2;

:

:

method1;

method2;

}

Каждый интерфейс СОМ должен иметь как минимум два атрибута IDL. Атрибут [object] служит признаком того, что данный интерфейс является СОМ-, а не DCE-интерфейсом. Второй обязательный атрибут указывает на физическое имя интерфейса (в предшествующем IDL-фрагменте IThisInterface является логическим именем интерфейса).

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

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

Чтобы исключить коллизию имен, всем СОМ-интерфейсам на этапе проектирования назначается уникальное двоичное имя, которое является физическим именем интерфейса. Эти физические имена называются глобально уникальными идентификаторами (Globally Unique Identifiers – GUIDs), что рифмуется со словом squids . GUID используются в СОМ повсюду для именования статических сущностей, таких как интерфейсы или реализации. GUID являются чрезвычайно большими 128-битными числами, что гарантирует их уникальность как во времени, так и в пространстве. GUID в СОМ основаны на универсальных уникальных идентификаторах (Universally Unique Identifiers – UUIDs), используемых в DCE RPC. При использовании GUID для именования СОМ-интерфейсов их часто называют идентификаторами интерфейса (Interface IDs – IIDs). Реализации в СОМ также именуются с помощью GUID, и в этом случае GUID называются идентификаторами класса (Class IDs – CLSIDs ). Будучи представленными в текстовой форме, GUID всегда имеют следующий канонический вид: BDA4A270-A1BA-11d0-8C2C-0080C73925BA

Эти 32 шестнадцатеричные цифры представляют 128-битное значение GUID. Именование интерфейсов и реализации с помощью GUID важно для предотвращения коллизий между разными компонентами.

Для создания нового GUID в СОМ имеется API-функция, которая использует децентрализованный алгоритм уникальности для генерирования нового 128-битного числа, которое никогда больше не встретится в природе:

HRESULT CoCreateGuid(GUID *pguid);

Алгоритм, задействованный в функции CoCreateGuid, использует локальный сетевой интерфейсный адрес машины, текущее машинное время и два постоянных счетчика для компенсации точности часов и нестандартных изменении в них (таких, как переход на летнее время или ручная коррекция системных часов). Если данная машина не имеет сетевого интерфейса, то синтезируется статистически уникальная величина и CoCreateGuid возвращает особого вида HRESULT, показывающий, что данная величина является глобально уникальной только статистически и может считаться таковой только при использовании на локальной машине. Хотя прямой вызов функции CoCreateGuid иногда полезен, большинство разработчиков вызывают ее в неявной форме, применяя из SDK программу GUIDGEN.EXE. На рис. 2.3 показана работа GUIDGEN. GUIDGEN вызывает CoCreateGuid и преобразует полученный GUID в один из четырех форматов, удобных для включения в исходный код на C++ или IDL. При работе в IDL используется четвертый формат (каноническая текстовая форма).

Чтобы связать физическое имя интерфейса с его определением на IDL, используется второй обязательный атрибут интерфейса – [uuid] . Атрибут [uuid] содержит один параметр – каноническую текстовую форму

GUID: [object, uuid(BDA4A270-A1BA-11dO-8C2C-0080C73925BA)]

interface ICalculator : IBaseInterface

{

HRESULT Clear(void);

HRESULT Add([in] long n);

HRESULT Sum([out, retval] long *pn);

}

При использовании при программировании на С или C++ физического имени интерфейса IID данного интерфейса представляет собой просто логическое имя интерфейса, предшествуемое префиксом IID_. Например, интерфейс ICalculator будет иметь IID, которым можно программно манипулировать, используя сгенерированную IDL константу IID_ICalculator. Для предотвращения коллизий между символическими именами интерфейсов можно использовать пространство имен C++.

Поскольку лишь немногие из компиляторов C++ могут поддерживать 128-битные числа, СОМ определяет С-структуру для представления 128-битовой величины GUID и предлагает псевдонимы для типов IID и CLSID с использованием следующего определения типов:

typedef struct GUID

{

DWORD Data1;

WORD Data2;

WORD Data3;

BYTE Data4[8];

} GUID;

typedef GUID IID;

typedef GUID CLSID;

Внутренняя структура GUID для большинства программистов несущественна, так как единственная значимая операция, которую можно выполнить с GUID, – это проверка их эквивалентности. Для обеспечения эффективной передачи величин GUID как аргументов функций СОМ предусматривает также постоянные псевдонимы для ссылок (constant reference aliases) для каждого типа GUID:

#define REFGUID const GUID&

#define REFIID const IID&

#define REFCLSID const CLSID&

Чтобы иметь возможность сравнивать величины GUID, СОМ обеспечивает функции эквивалентности и перегружает операторы == и != для постоянных ссылок GUID:

inline BOOL IsEqualGUID(REFGUID r1, REFGUID r2)

{

return !memcmp(&r1, &r2, sizeof(GUID));

}

#def1ne IsEqualIID(r1, r2) IsEqualGUID((r1) , (r2))

#define IsEqualCLSID(r1, r2) IsEqualGUID((r1), (r2))

inline BOOL operator == (REFGUID r1, REFGUID r2)

{

return !memcmp(&r1, &r2, sizeof(GUID));

}

inline BOOL operator != (REFGUID r1, REFGUID r2)

{

return !(r1 == r2);

}

Фактические заголовки SDK содержат условно компилируемые совместимые с С версии определений типа, макросов и встраиваемых функций, как показано выше.

Поскольку показано, что представления имен интерфейсов на этапе выполнения являются GUID, а не строками; это означает, что метод Dynamic_Cast, описанный в предыдущей главе, следует пересмотреть. Действительно, весь интерфейс IЕхtensibleObject должен быть изменен и преобразован в свой аналог IUnknown, совместимый с СОМ. 

 

Интерфейс IUnknown

СОМ-интерфейс IUnknown имеет то же назначение, что и интерфейс IExtensibleObject, определенный в предыдущей главе. Последняя версия IExtensibleObject, появившаяся в конце предыдущей главы, имеет вид:

class IExtensibleObject

{

public:

virtual void *Dynamic_Cast(const char* pszType) = 0;

virtual void DuplicatePointer(void) = 0;

virtual void DestroyPointer(void) = 0;

}

Для определения типа на этапе выполнения был применен метод Dynamic_Cast, аналогичный оператору C++ dynamic_cast. Для извещения объекта о том, что указатель интерфейса дублировался, использовался метод DuplicatePointer. Для сообщения объекту, что указатель интерфейса уничтожен и все используемые им ресурсы могут быть освобождены, был применен метод DestroyPointer. Вот как выглядит определение IUnknown на C++:

extern "С" const IID IID_IUnknown: interface IUnknown

{

virtual HRESULT STDMETHODCALLTYPE QueryInterface(REFIID riid, void **ppv) = 0;

virtual ULONG STDMETHODCALLTYPE AddRef(void) = 0;

virtual ULONG STDMETHODCALLTYPE Release(void) = 0;

};

Заголовочные файлы SDK дают псевдоним interface ключевому слову C++ struct, используя препроцессор С. Поскольку интерфейсы в СОМ определены не как классы, а как структуры, то для того, чтобы сделать методы интерфейса общедоступными, ключевое слово public не требуется. Чтобы создать для целевой платформы СОМ-совместимые стековые фреймы, необходим макрос STDMETHODCALLTYPE. Если целевыми являются платформы Win32, то при использовании компилятора Microsoft C++ этот макрос раскрывается в _stdcall.

IUnknown функционально эквивалентен IExtensibleObject. Метод QueryInterface используется для динамического определения типа и аналогичен С++-оператору dynamic_cast. Метод AddRef используется для сообщения объекту, что указатель интерфейса дублирован. Метод Release используется для сообщения объекту, что указатель интерфейса уничтожен и все ресурсы, которые объект поддерживал от имени клиента, могут быть отключены. Главное различие между IUnknown и интерфейсом, определенным в предыдущей главе, заключается в том, что IUnknown использует идентификаторы GUID, а не строки для идентификации типов интерфейса на этапе выполнения.

IDL-определение IUnknown можно найти в файле unknwn.idl из директории SDK, содержащей заголовочные файлы:

// unknwn.idl – system IDL file

// unknwn.idl – системный файл IDL

[ local, object, uuid (00000000-0000-0000-C000-000000000046) ] interface IUnknown

{

HRESULT QueryInterface([in] REFIID riid, [out] void **ppv);

ULONG AddRef(void); ULONG Release(void);

}

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

Интерфейс IUnknown является родительским для всех СОМ-интерфейсов. IUnknown – единственный интерфейс СОМ, который не наследует от другого интерфейса. Любой другой допустимый интерфейс СОМ должен быть прямым потомком IUnknown или какого-нибудь другого допустимого интерфейса СОМ, который, в свою очередь, должен сам наследовать или прямо от IUnknown, или от какого-нибудь другого допустимого интерфейса СОМ. Это означает, что на двоичном уровне все интерфейсы СОМ являются указателями на таблицы vtbl, которые начинаются с трех точек входа: QueryInterface, AddRef и Release. Все специфические для интерфейсов методы будут иметь точки входа в vtbl, которые появляются после этих трех общих точек входа.

Чтобы наследовать от интерфейса IDL, нужно или определить базовый интерфейс в том же IDL-файле, или использовать директиву import, чтобы сделать внешнее IDL-определение базового интерфейса явным в данной области действия:

// calculator.idl

[object, uuid(BDA4A270-A1BA-11dO-8C2C-0080C73925BA)]

interface ICalculator : IUnknown

{

import «unknwn.idl»;

// bring in def. of IUnknown

// импортируем определение IUnknown

HRESULT Clear(void);

HRESULT Add([in] long n);

HRESULT Sum([out, retval] long *pn);

}

Оператор import может появляться или внутри определения интерфейса, как показано здесь, или предшествовать описанию интерфейса в глобальной области действия. В любом из этих случаев действия оператора import одинаковы, он может многократно импортировать один IDL-файл без всякого ущерба. Поскольку сгенерированный C/C++ заголовочный файл будет требовать С/С++-версии импортируемого IDL-файла, чтобы обеспечить наследование, оператор import из IDL-файла будет странслирован в команду #include в генерируемом заголовочном С/С++-файле:

// calculator.h – generated by MIDL

// calculator.h – генерированный MIDL

// bring in def. of IUnknown

// вводим определения IUnknown

#include «unknwn.h»

extern "C" const IID IID_ICalculator;

interface ICalculator : public IUnknown

{

virtual HRESULT STDMETHODCALLTYPE Clear(void) = 0;

virtual HRESULT STDMETHODCALLTYPE Add(long n) = 0;

virtual HRESULT STDMETHODCALLTYPE Sum(long *pn) = 0;

}

Компилятор MIDL также создаст С-файл, содержащий фактические определения всех GUID, имеющихся в исходном IDL-файле:

// calculator_i.с – generated by MIDL

const IID IID_ICalculator =

{ 0xBDA4A270, 0xA1BA, 0x11d0, { 0x8C, 0x2C, 

0x00, 0х80, 0хC7, 0х39, 0x25, 0xBA } };

Каждый проект, который будет использовать этот интерфейс, должен или добавить calculator_i.c к своему файлу сборки (makefile), или включить calculator_i.c в один из исходных файлов на С или C++ с использованием препроцессора С. Если это не сделано, то идентификатору IID_ICalculator не будет выделено памяти для его 128-битного значения и проект не будет скомпонован по причине неразрешенных внешних идентификаторов.

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

import «unknwn.idl»;

[object, uuid(DF12E151-A29A-11d0-8C2D-0080C73925BA)]

interface IAnimal : IUnknown {

HRESULT Eat(void);

}

[object, uuid(DF12E152-A29A-11d0-8C2D-0080C73925BA)]

interface ICat : IAnimal

{

HRESULT IgnoreMaster(void);

}

[object, uuid(DF12E153-A29A-11d0-8C2D-0080C73925BA)]

interface IDog : IAnimal

{

HRESULT Bark(void);

}

[object, uuid(DF12E154-A29A-11d0-8C2D-0080C73925BA)]

interface IPug : IDog

{

HRESULT Snore(void);

}

[object, uuid(DF12E155-A29A-11d0-8C2D-0080C73925BA)]

interface IOldPug : IPug

{

HRESULT SnoreLoudly(void);

}

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

[object, uuid(DF12E156-A29A-11d0-8C2D-0080C73925BA)]

interface ICatDog : ICat, IDog

{

// illegal, multiple bases

// неверно, несколько базовых интерфейсов

HRESULT Meowbark(void);

}

СОМ запрещает наследование от нескольких интерфейсов по целому ряду причин. Одна из них состоит в том, что двоичное представление результирующего абстрактного базового класса C++ не будет независимым от компилятора. В этом случае СОМ уже не будет являться двоичным стандартом, независимым от разработчика. Другая причина кроется в тесной связи между СОМ и DCE RPC. При ограничении наследования интерфейсов одним базовым интерфейсом преобразование между интерфейсами СОМ и интерфейсными векторами DCE RPC вполне однозначно. В конце концов, отсутствие поддержки нескольких базовых интерфейсов не является ограничением, так как каждая реализация может выбрать для открытия столько интерфейсов, сколько пожелает. Это означает, что основанный на СОМ Cat/Dog по-прежнему допустим на уровне реализации:

class CatDog : public ICat, public IDog

{

//

...

};

Клиент, желающий трактовать объект как Cat/Dog, просто использует QueryInterface для привязки к объекту обоих типов указателей. Если один из вызовов QueryInterface не достигает успеха, то данный объект не является Cat/Dog и клиент может справляться с этим, как сумеет. Поскольку реализации могут открывать несколько интерфейсов, то запрет для интерфейсов наследовать более чем от одного интерфейса является лишь небольшой потерей в смысле семантической информации или информации о типе.

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

Рисунок 2.4 показывает стандартное обозначение класса CatDog. Заметим, что из этой схемы можно сделать единственный вывод: если не произойдет катастрофических сбоев, объекты CatDog выставят четыре интерфейса: ICat, IDog, IAnimal и IUnknown.

 

Управление ресурсами и IUnknown

Как было в случае с DuplicatePointer и DestroyPointer из предыдущей главы, методы AddRef и Release из IUnknown имеют очень простой протокол, которого должны придерживаться все, кто пользуется указателями этих интерфейсов. Эти правила освобождают клиента от необходимости управлять временем жизни объекта, когда несколько интерфейсных указателей могут указывать или не указывать на один и тот же объект. Клиентам необходимо только следовать простым правилам AddRef/Release единообразно для всех интерфейсных указателей, с которыми им приходится сталкиваться, а объект будет сам управлять своим временем жизни.

Спецификация модели компонентных объектов (Component Object Model Specification) содержит четкие определения правил подсчета ссылок СОМ. Понимание мотивировки этих определений имеет решающее значение при СОМ-программировании на C++. Эти правила СОМ о подсчете ссылок могут быть сведены к трем простым аксиомам:

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

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

Избыточное количество вызовов AddRef и Release можно сократить, если иметь дополнительную информацию о связях между двумя и более ячейками памяти.

Аксиома о дополнительной информации введена главным образом для того, чтобы ввести возможность преобразования запутанных ситуаций в разумные и осмысленные идиомы программирования (например, стеки временных вызовов и сгенерированное компилятором занесение переменной в регистр не нуждаются в подсчете ссылок). Можно провести месяцы в поиске особых связей между переменными, содержащими явные указатели на интерфейс в программе и оптимизировать избыточные вызовы AddRef и Release , но поступать так было бы неосмотрительно. Выгода от удаления этих избыточных вызовов явно незначительна, так как даже в худшем случае, когда объект вызывается с расстояния более 8500 миль со средней скоростью передачи 14.4 кбит/сек, эти избыточные вызовы никогда не уйдут из вызывающего потока и нечасто требуют множество инструкций для выполнения.

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

А1. Когда ненулевой интерфейсный указатель записывается в локальную переменную.

А2. Когда вызываемый объект пишет ненулевой интерфейсный указатель в параметр [out] или [in, out] метода или функции.

A3. Когда вызываемый объект возвращает ненулевой интерфейсный указатель как физический результат (physical result) функции.

А4. Когда ненулевой интерфейсный указатель пишется в элемент данных объекта.

Некоторые типичные ситуации, требующие вызова метода Release :

R1. Перед перезаписью ненулевой локальной переменной или элемента данных.

R2. Перед тем как покинуть область действия ненулевой локальной переменной.

R3. Когда вызываемый объект перезаписывает параметр [in,out] метода или функции, начальное значение которых отлично от нуля. Заметим, что параметры [out] предполагаются нулевыми при вводе и никогда не могут освобождаться вызываемым объектом.

R4. Перед перезаписью ненулевого элемента данных объекта.

R5. Перед завершением работы деструктора объекта, имеющего в качестве элемента данных ненулевой интерфейсный указатель.

Типичная ситуация, к которой применимо правило о дополнительной информации, возникает при передаче указателей интерфейсов функциям как параметрам [in]:

S1. Когда при вызове функции или метода ненулевой интерфейсный указатель передается через [in] -параметр, вызов AddRef и Release, не требуются, так как время жизни временной переменной в стеке является строгим подмножеством времени жизни выражения, использованного для инициализации формального аргумента.

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

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

void GetObject([out] IUnknown **ppUnk);

и что имеется другая глобальная функция, которая выполняет некую полезную работу над объектом:

void UseObject([in] IUnknown *pUnk);

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

void GetAndUse(/* [out] */ IUnknown ** ppUnkOut)

{ IUnknown *pUnk1 = 0, *pUnk2 = 0; *ppUnkOut =0;

// R3

// get pointers to one (or two) objects

// получаем указатели на один (или два) объекта

GetObject(&pUnk1);

//A2

GetObject(&pUnk2);

//A1

// set pUnk2 to point to first object

// устанавливаем pUnk2, чтобы указать на первый объект

if (pUnk2) pUnk2->Release():

//R1

if (pUnk2 = pUnk1) pUnk2->AddRef():

//A1

// pass pUnk2 to some other function

// передаем pUnk2 какой-нибудь другой функции

UseObject(pUnk2);

//S1

// return pUnk2 to caller using ppUnkOut parameter

// возвращаем pUnk2 вызывающему объекту, используя

// параметр ppUnkOut

if (*ppUnkOut = pUnk2) (*ppUnkOut)->AddRef();

// A2

// falling out of scope so clean up

// выходит за область действия и поэтому освобождаем

if (pUnk1) pUnkl->Release();

//R2

if (pUnk2) pUnk2->Release();

//R2

}

Важно отметить, что в вышеприведенном коде правило A2 применяется дважды, но по двум разным причинам. При вызове GetObject код выступает как вызывающий объект, а реализация GetObject является вызываемым объектом. Это означает, что реализация GetObject является ответственной за вызов AddRef через параметр [out]. При перезаписи памяти, на которую ссылается ppUnkOut, код выступает как вызываемый объект и корректно вызывает AddRef через интерфейсный указатель перед возвратом управления вызывающему объекту.

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

Единственный случай, заслуживающий внимания, это когда Release возвращает нуль. Нулевой результат от Release надежно свидетельствует о том, что данный объект более не действителен ни в каком смысле. Однако обратное неверно. Это значит, что когда Release возвращает не нуль, нельзя утверждать, что объект еще работоспособен. Фактически, если Release был вызван указателем интерфейса столько же раз, сколько этим же указателем интерфейса был вызван AddRef , то данный указатель интерфейса недействителен и более не обеспечивает указание на действующий объект. В то же время возможно, что это – случайность, а объект все еще работоспособен благодаря другим, еще не освобожденным, указателям, и все может измениться в самый неподходящий момент. Чтобы однажды освобожденные (released) интерфейсные указатели более не использовались, можно, например, обнулять их сразу же после вызова метода Release:

inline void SafeRelease(IUnknown * &rpUnk)

{

if (rpUnk)

{

rpUnk->Release();

rpUnk = 0;

// rpUnk passed by reference

// rpUnk, переданный ссылкой

}

}

Когда этот способ применен, любое использование указателя интерфейса после его высвобождения немедленно вызовет ошибку доступа. Эта ошибка затем может быть достоверно воспроизведена и, можно надеяться, отловлена еще на этапе разработки.

Еще одна тонкость, относящаяся к AddRef и Release, состоит в выходе из блока. Функция GetAndUse , приведенная ранее, имеет только одну точку выхода. Это означает, что операторы, высвобождающие указатели интерфейса в конце функции, будут всегда выполняться ранее завершения работы функции. Если же функция завершит работу, не доходя до этих операторов – либо благодаря явному оператору return или же, что хуже, необработанному (unhandled) исключению C++, – то эти завершающие операторы будут пропущены и все ресурсы, удерживаемые неосвобожденными интерфейсными указателями, будут утеряны до окончания клиентской программы. Это означает, что к указателям интерфейса СОМ следует относиться с осторожностью, особенно при использовании их в средах, использующих исключения C++. Впрочем, это касается и других системных ресурсов, с которыми приходится работать, будь то семафоры или динамически распределяемая память. Далее в этой главе обсуждаются интеллектуальные СОМ-указатели, которые обеспечивают вызов Release во всех ситуациях.

 

Приведение типов и IUnknown

В предыдущей главе обсуждалось, почему необходимо определять тип на этапе выполнения в динамически собранной системе. Язык C++ предусматривает разумный механизм для динамического определения типа с помощью оператора dynamic_cast. Хотя эта языковая возможность имеет собственную реализацию для каждого компилятора, в предыдущей главе было предложено средство урегулирования этого – добавление к каждому интерфейсу явного метода, являющегося семантическим эквивалентом dynamic_cast. Ниже приводится IDL-описание QueryInterface:

HRESULT QueryInterface([in] REFIID riid, [out] void **ppv);

Первый параметр (riid) является физическим именем запрошенного интерфейса. Второй параметр (ppv) указывает на переменную интерфейсного указателя, которая в случае успешного завершения будет содержать запрошенный указатель на интерфейс.

В ответ на запрос QueryInterface, если объект не поддерживает запрошенный тип интерфейса, он должен возвратить E_NOINTERFACE после установки *ppv в нулевое значение. Если же объект поддерживает запрошенный интерфейс, он должен перезаписать *ppv указателем запрошенного типа и возвратить HRESULT S_OK. Поскольку ppv является [out]-параметром, реализация QueryInterface должна выполнить AddRef для возвращаемого указателя перед тем, как вернуть управление вызывающему объекту (см. в этой главе выше руководящий принцип А2). Этот вызов AddRef должен быть согласован с вызовом Release со стороны клиента. Следующий код показывает динамическое определение типа с использованием оператора C++ dynamic_cast на примере иерархии типов Dog/Cat, описанного ранее в данной главе:

void TryToSnoreAndIgnore(/* [in] */ IUnknown *pUnk)

{

IPug *pPug = 0;

pPug = dynamic_cast (pUnk);

if (pPug)

// the object is Pug-compatible

// объект совместим с Pug

pPug->Snore();

ICat *pCat = 0;

pCat = dynamic_cast(pUnk);

if (pCat)

// the object is Cat-compatible

// объект совместим с Cat

pCat->IgnoreMaster();

}

Если объект, переданный этой функции, совместим одновременно с ICat и с IDog, то задействованы обе функциональные возможности. Если же объект в действительности не совместим с ICat или с IDog, то данная функция просто проигнорирует пропущенный аспект объекта (или оба аспекта сразу). Ниже показан семантически эквивалентный вариант с использованием QueryInterface:

void TryToSnoreAndIgnore(/* [in] */ IUnknown *pUnk)

{

HRESULT hr;

IPug *pPug = 0;

hr = pUnk->QueryInterface(IID_IPug, (void**)&pPug);

if (SUCCEEDED(hr))

{

// the object is Pug-compatible

// объект совместим с Pug

pPug->Snore();

pPug->Release();

// R2

}

ICat *pCat = 0;

hr = pUnk->QueryInterface(IID_ICat, (void**)&pCat);

if (SUCCEEDED(hr))

{

// the object is Cat-compatible

// объект совместим с Cat

pCat->IgnoreMaster();

pCat->Release(); // R2

}

}

Хотя имеются очевидные различия в синтаксисе, единственная существенная разница между двумя приведенными фрагментами кода состоит в том, что вариант, основанный на QueryInterface, подчиняется правилам подсчета ссылок СОМ.

Есть несколько тонкостей, связанных с QueryInterface и его употреблением. Метод QueryInterface может возвращать указатели только на тот же самый СОМ-объект, для которого он вызван. Глава 4 посвящена объяснению каждого нюанса этого оператора. Полезно, однако, отметить уже сейчас, что клиент не должен трактовать AddRef и Release как операции с объектом. Вместо этого следует рассматривать их как операции с указателем интерфейса. Это означает, что нижеследующий код ошибочен:

void BadCOMCode(/*[in]*/ IUnknown *pUnk)

{

ICat *pCat = 0;

IPug *pPug = 0;

HRESULT hr;

hr = pUnk->QueryInterface(IID_ICat, (void**)&pCat);

if (FAILED(hr)) goto cleanup;

hr = pUnk->QueryInterface(IID_IPug, (void**)&pPug);

if (FAILED(hr)) goto cleanup;

pPug->Bark();

pCat->IgnoreMaster();

cleanup:

if (pCat) pUnk->Release();

// pCat got AddRefed in QI

// pCat получил AddRef в QI

if (pPug) pUnk->Release();

// pDog got AddRefed in QI

// pDog получил AddRef в QI

}

Несмотря на то что все три указателя: pCat, pPug и pUnk – указывают на тот же самый объект, клиент не имеет права компенсировать AddRef, который происходит для pCat и pPug при вызове QueryInterface, вызовами Release для pUnk. Правильный вариант этого кода такой:

cleanup:

if (pCat) pCat->Release();

// use AddRefed ptr

// используем указатель AddRef

if (pPug) pPug->Release();

// use AddRefed ptr

// используем указатель AddRef

Здесь Release вызывается для того же интерфейсного указателя, для которого и AddRef (что произошло неявно, когда указатель был возвращен из QueryInterface). Это требование предоставляет разработчику значительную гибкость при реализации объекта. Например, объект может решить подсчитывать ссылки на каждый интерфейс, чтобы активным образом использовать ресурсы, которые обычно используются одним определенным интерфейсом на объект.

Еще одна тонкость относится ко второму параметру QueryInterface, имеющему тип void**. Весьма забавно то, что QueryInterface, являющийся основой системы типов СОМ, имеет довольно сомнительный в смысле типа аналог в C++:

HRESULT _stdcall QueryInterface(REFIID riid, void** ppv);

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

IPug *pPug = 0; hr = punk->QueryInterface(IID_IPug, (void**)&pPug);

К сожалению, для компилятора C++ таким же правильным выглядит и следующее:

IPug *pPug = 0; hr = punk->QueryInterface(IID_ICat, (void**)&pPug);

Даже еще более хитроумный вариант компилируется без ошибок:

IPug *pPug = 0; hr = punk->QueryInterface(IID_IPug, (void**)pPug);

Исходя из того, что правила наследования неприменимы к указателям, такое альтернативное определение QueryInterface нe облегчает проблему:

HRESULT QueryInterface(REFIID riid, IUnknown** ppv);

так как неявное приведение типа к родительскому типу (upcasting) применимо только к объектам и указателям на объекты, а не к указателям на указатели на объекты:

IDerived **ppd; IBase **ppb = ppd;

// illegal

// неверно

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

HRESULT QueryInterface(const IID& riid, void* ppv);

так как позволяет клиентам отказаться от приведения типа (cast). К сожалению, это решение не уменьшает количества ошибок (обе из предшествующих ошибок все еще возможны), а устраняя необходимость приведения, уничтожает и видимый индикатор того, что устойчивость типов C++ может оказаться в опасности. Если желательна семантика QueryInterface, то выбор типов аргументов, сделанный корпорацией Microsoft, по крайней мере, разумен, если не надежен или изящен. Простейший путь избежать ошибок, связанных c QueryInterface,– это всегда быть уверенным в том, что IID соответствует типу указателя интерфейса, который проходит как второй параметр QueryInterface. На самом деле первый параметр QueryInterface описывает «форму» типа указателя второго параметра. Их связь может быть усилена на этапе компиляции с помощью такого макроса предпроцессора С:

#define IID_PPV_ARG(Type, Expr) IID_##type,

reinterpret_cast(static_cast(Expr))

С помощью этого макроса компилятор будет уверен в том, что выражение, использованное в приведенном ниже вызове QueryInterface, имеет правильный тип и что используется соответствующий уровень изоляции (indirecton):

IPug *pPug = 0; hr = punk->QueryInterface(IID_PPV_ARG(IPug, &pPug));

Этот макрос закрывает брешь, вызванную параметром void**, без каких-либо затрат на этапе выполнения.

 

Реализация IUnknown

Имея описанные выше образцы клиентского использования, легко видеть, как реализовать методы IUnknown. Примем предложенную выше иерархию типов Dog/Cat. Чтобы определить С++-класс, который реализует интерфейсы IPug и ICat , нужно просто добавить к списку базовых классов самые последние в иерархии наследования версии интерфейсов:

class PugCat : public IPug, public ICat

При использовании наследования компилятор C++ обеспечивает совместимость двоичного представления производного класса с каждым базовым классом. Для класса PugCat это означает, что все объекты PugCat будут содержать указатель vptr, указывающий на таблицу vtbl, совместимую с IPug. Объекты PugCat также будут содержать указатель vptr, указывающий на вторую таблицу vtbl, совместимую с ICat. Рисунок 2.5 показывает, как интерфейсы в качестве базовых классов соотносятся с представлением объектов.

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

Следующий код является определением класса, которое создает объекты, поддерживающие интерфейсы IPug и ICat:

class PugCat : public IPug, public ICat

{

LONG mcRef;

protected:

virtual ~PugCat(void);

public: PugCat(void);

// IUnknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID riid, void **ppv);

STDMETHODIMP(ULONG) AddRef(void);

STDMETHODIMP(ULONG) Release(void);

// IAnimal methods

// методы IAnimal

STDMETHODIMP Eat(void);

// IDog methods

// методы IDog

STDMETHODIMP Bark(void);

// IPug methods

// методы IPug

STDMETHODIMP Snore(void);

// ICat methods

// методы ICat

STDMETHODIMP IgnoreMaster(void);

};

Отметим, что в классе должен быть реализован каждый метод, определенный в любом интерфейсе, от которого он наследует, так же, как и каждый метод, определенный в любых производных (implied) базовых интерфейсах (например, IDog, IAnimal ). Для создания стековых фреймов, совместимых с СОМ, необходимо использовать макросы STDMETHODIMP и STDMETHODIMP. При ориентации на платформы Win32, использующие компилятор Microsoft C++, заголовки SDK определяют эти два макроса следующим образом:

#define STDMETHODIMP HRESULT stdcall

#define STDMETHODIMP(type) type stdcall

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

Реализация AddRef и Release чрезвычайно прозрачна. Элемент данных mcRef отслеживает, сколько неосвобожденных интерфейсных указателей удерживают объект. Конструктор класса приводит счетчик ссылок в нулевое состояние:

PugCat::PugCat(void) : mcRef(0)

// initialize reference count to zero

// устанавливаем счетчик ссылок в нуль

{ } 

Реализация AddRef в классе фиксирует путем увеличения счетчика ссылок, что вызывающий объект продублировал указатель интерфейса. Измененное значение счетчика ссылок возвращается для целей диагностики:

STDMETHODIMP(ULONG) AddRef(void)

{ return ++mcRef; }

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

STDMETHODIMP(ULONG) Release(void)

{

LONG res = -mcRef;

if (res == 0) delete this;

return res;

}

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

Заметим, что показанные реализации Addref и Release используют собственные операторы инкремента и декремента (увеличения и уменьшения на единицу). Для простой реализации это весьма разумно, так как СОМ не допускает более одного потока для обращения к объекту до тех пор, пока конструктор не обеспечит явный многопоточный доступ (почему и как конструктор сделает это, подробно описано в главе 5). В случае объектов, доступных в многопоточной среде, для автоматического подсчета ссылок следует использовать подпрограммы Win32 InterlockedIncrement/InterlockedDecrement:

STDMETHODIMP(ULONG) AddRef(void)

{

return InterlockedIncrement(&mcRef);

}

STDMETHODIMP(ULONG) Release(void)

{

LONG res = InterlockedDecrement(&mcRef);

if (res == 0) delete this; return res;

}

Этот код несколько менее эффективен, чем версии, использующие собственные операторы C++. Но, вообще говоря, разумнее использовать менее эффективные варианты InterlockedIncrement / InterlockedDecrement, так как известно, что они надежны во всех ситуациях и освобождают разработчика от необходимости сохранять две версии практически одинакового кода.

Показанные выше реализации AddRef и Release предполагают, что объект может размещаться только в динамически распределяемой области памяти (в «куче») с использованием С++-оператора new. В определении класса деструктор сделан защищенной операцией для обеспечения того, чтобы ни один экземпляр класса не был определен никаким другим способом. Однако иногда желательно иметь объекты, не размещенные в «куче». Для этих объектов вызов delete в последнем вызове Release был бы гибельным. Так как единственной причиной для того, чтобы объект в первую очередь поддерживал счетчик ссылок, была необходимость вызова delete this, допустимо оптимизировать счетчик ссылок для объектов, не содержащихся в динамически распределяемой области памяти:

STDMETHODIMP(ULONG) GlobalVar::AddRef(void)

{

return 2;

// any non-zero value is legal

// допустима любая ненулевая величина

}

STDMETHODIMP(ULONG) GlobalVar::Release (void)

{

return 1;

// any non-zero value is legal

// допустима любая ненулевая величина

}

Эта реализация использует тот факт, что результаты AddRef и Release служат только для сведения и не обязаны быть точными.

При наличии реализации AddRef и Release единственным еще не реализованным методом из IUnknown остается QueryInterface. Его реализации должны отслеживать иерархию типов объекта и использовать статические приведения типов для возврата правильного типа указателя для всех поддерживаемых интерфейсов. Для определения класса PugCat, рассмотренного ранее, следующий код является корректной реализацией QueryInterface : STDMETHODIMP

PugCat::QueryInterface(REFIID riid, void **ppv)

{

assert(ppv != 0);

// or return EPOINTER in production

// или возвращаем EPOINTER в реальный продукт

if (riid == IIDIPug) *ppv = staticcast(this);

else if (riid == IIDIDog) *ppv = staticcast(this);

else if (riid == IIDIAnimal)

// cat or pug?

// кот или мопс?

*ppv == staticcast(this);

else if (riid == IIDIUnknown)

// cat or pug?

// кот или мопс?

*ppv = staticcast(this);

else if (riid == IIDICat) *ppv = staticcast(this);

else

{

// unsupported interface

// неподдерживаемый интерфейс

*ppv = 0;

return ENOINTERFACE;

}

// if we reach this point, *ppv is non-null

// and must be AddRef'ed (guideline A2)

// если мы дошли до этого места, то *ppv ненулевой

// и должен быть обработан AddRef'ом ( принцип A2)

reinterpretcast(*ppv)->AddRef();

return SOK;

}

Использование staticcast более предпочтительно, чем традиционные приведения типа в стиле С:

*ppv = (IPug*)this;

так как вариант staticcast вызовет ошибку этапа компиляции, если произведенное приведение типа не согласуется с существующим базовым классом.

Заметим, что в показанной здесь реализации QueryInterface при запросе на интерфейс, поддерживающийся более чем одним базовым интерфейсом (например, IUnknown, IAnimal) приведение типа должно явно выбрать более определенный базовый класс. Например, для класса PugCat такой вполне безобидно выглядящий код не откомпилируется:

if (riid == IIDIUnknown) *ppv = staticcast(this);

Этот код не пройдет компиляцию, поскольку такое приведение типа является неоднозначным и может соответствовать более чем одному базовому классу. Это было показано в случае FastString и IExtensibleObject из предыдущей главы. Вместо этого реализация должна более точно выбрать тип для приведения:

if (riid == IIDIUnknown) ppv = staticcast(this);

или if (riid == IIDIUnknown) ppv = staticcast(this);

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

 

Использование указателей интерфейса СОМ

Программисты C++ должны использовать методы IUnknown явно, потому что перевод модели СОМ на язык C++ не предусматривает использования среды поддержки выполнения (runtime layer) между кодом клиента и кодом объекта. Поэтому IUnknown можно рассматривать просто как набор обещаний, которые все программисты СОМ дают друг другу. Это дает преимущество программистам C++, так как C++ может создавать код, который потенциально более эффективен, чем языки, которые требуют такого динамического слоя при работе с СОМ.

При работе на Visual Basic и Java, в отличие от C++, программисты никогда не видят QueryInterface, AddRef или Release. Для этих двух языков детали IUnknown надежно скрыты за поддерживающей эти языки виртуальной машиной. На Java QueryInterface просто отображается в приведение типа:

public void TryToSnoreAndIgnore(Object obj)

{

IPug pug;

try

{

pug = (IPug)obj;

// VM calls QueryInterface

// VM вызывает QueryInterface

pug.Snore();

}

catch (Throwable ex)

{

// ignore method or QI failures

// игнорируем сбой метода или QI

}

ICat cat;

try

{

cat = (ICat)obj;

// VM calls QueryInterface

// VM вызывает QueryInterface

cat.IgnoreMaster();

}

catch (Throwable ex)

{

// ignore method or QI failures

// игнорируется сбой метода или QI

}

}

Visual Basic не требует от клиентов приведения типов. Вместо этого, когда указатель интерфейса присваивается переменной неподходящего типа, виртуальная машина (VM) Visual Basic молча вызывает QueryInterface от имени клиента:

Sub TryToSnoreAndIgnore(obj as Object)

On Error Resume Next

' ignore errors

' игнорируем ошибки

Dim pug as IPug

Set pug = obj

' VM calls QueryInterface

' VM вызывает QueryInterface

If Not (pug is Nothing)

Then pug.Snore

End

if Dim cat as ICat

Set cat = obj

' VM calls QueryInterface

' VM вызывает QueryInterface

If Not (cat is Nothing)

Then cat.IgnoreMaster

End if End Sub

Обе виртуальные машины, как Java, так и Visual Basic, выбросят при сбое QueryInterface исключения. В обеих средах виртуальная машина автоматически преобразует языковую концепцию живучести переменной в явные вызовы AddRef и Release , избавляя клиента и от этой подробности.

Одна методика, потенциально способная упростить использование в СОМ интерфейсных указателей из C++, состоит в том, чтобы скрыть их в классе интеллектуальных указателей. Это устраняет необходимость необработанных (raw ) вызовов методов IUnknown. В идеале интеллектуальный указатель СОМ будет:

Корректно обрабатывать каждый вызов Add/Release во время присваивания.

Автоматически уничтожать интерфейс в деструкторе, что снижает возможность утечки ресурса и повышает безопасность (надежность) исключений.

Использует систему типов C++ для упрощения вызовов QueryInterface.

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

Последний пункт представляет собой чрезвычайно серьезную проблему. Интернет забит интеллектуальными СОМ-указателями, которые проделывают прозрачную замену обычных указателей, но при этом вводят столько же скрытых ошибок, сколько претендуют устранить. Visual C++ 5.0, например, фактически действует с тремя такими указателями (один на MSC, другой на ATL, а третий для поддержки Direct-to-COM), которые очень просто использовать как правильно, так и неправильно. В сентябрьском 1995 года и в февральском 1996 года выпусках "C++ Report " опубликованы две статьи, где на примерах показаны различные подводные камни при использовании интеллектуальных указателей. Исходный код, который приводится в данной книге, содержит интеллектуальный СОМ-указатель, созданный в процессе написания этих двух статей. В нем делается попытка учесть общие ошибки, случающиеся как в простых, так и в интеллектуальных указателях СОМ. Класс интеллектуальных указателей, SmartInterface , имеет два шаблонных (template) параметра: тип интерфейса в C++ и указатель на соответствующий IID . Все обращения к методам IUnknown скрыты путем перегрузки операторов:

#include «smartif.h»

void TryToSnoreAndIgnore(/* [in] */ IUnknown *pUnk)

{

// copy constructor calls QueryInterface

// конструктор копирования вызывает QueryInterface

SmartInterface pPug = pUnk;

if (pPug)

// typecast operator returns null-ness

// оператор приведения типа возвращает нуль pPug->Snore();

// operator-> returns safe raw ptr

// оператор -> возвращает прямой указатель

// copy constructor calls QueryInterface

// конструктор копирования вызывает QueryInterface

SmartInterface pCat = pUnk;

if (pCat)

// typecast operator returns null-ness

// оператор приведения типа возвращает нуль pCat->IgnoreMaster();

// operator-> returns safe raw ptr

// оператор -> возвращает прямой указатель

// destructors release held pointers on leaving scope

// деструкторы освобождают удерживаемые указатели при

// выходе из области действия

}

Интеллектуальные указатели выглядят очень привлекательными на первый взгляд, но могут оказаться очень опасными, так как погружают программиста в дремотное состояние; будто бы ничего страшного, относящегося к СОМ, произойти не может. Интеллектуальные указатели действительно решают реальные проблемы, особенно связанные с исключениями; однако при неосторожном употреблении они могут внести столько же дефектов, сколько они предотвращают. Например, многие интеллектуальные указатели позволяют вызывать любой метод интерфейса через оператор интеллектуального указателя –>. К сожалению, это позволяет клиенту вызывать Release с помощью этого оператора-стрелки без сообщения базовому интеллектуальному указателю о том, что его автоматический вызов Release в его деструкторе теперь является излишним и недопустимым.

 

Оптимизация QueryInterface

Фактически реализация QueryInterface, показанная ранее в этой главе, очень проста и легко может поддерживаться любым программистом, имеющим хоть некоторое представление о СОМ и C++. Тем не менее, многие среды и каркасы приложений поддерживают реализацию, управляемую данными. Это помогает достичь большей расширяемости и эффективности благодаря уменьшению размера кода. Такие реализации предполагают, что каждый совместимый с СОМ класс предусматривает таблицу, которая отображает каждый поддерживаемый IID на какой-нибудь аспект объекта, используя фиксированные смещения или какие-то другие способы. В сущности, реализация QueryInterface , приведенная ранее в этой главе, строит таблицу, основанную на скомпилированном машинном коде для каждого из последовательных операторов if, а фиксированные смещения вычисляются с использованием оператора staticcast (staticcast просто добавляет смещение базового класса, чтобы найти совместимый с типом указатель vptr).

Чтобы реализовать управляемый таблицей QueryInterface, необходимо сначала определить, что эта таблица будет содержать. Как минимум, каждый элемент таблицы должен содержать указатель на IID и некое дополнительное состояние, которое позволит реализации найти указатель vptr объекта для запрошенного интерфейса. Хранение указателя функции в каждом элементе таблицы придаст этому способу максимальную гибкость, так как это даст возможность добавлять новые методики поиска интерфейсов к обычному вычислению смещения, которое используется для приведения к базовому классу. Исходный код в приложении к данной книге содержит заголовочный файл inttable.h , который определяет элементы таблицы интерфейсов следующим образом:

// inttable.h (book-specific header file)

// inttable.h (заголовочный файл, специфический для этой книги)

// typedef for extensibility function

// typedef для функции расширяемости

typedef HRESULT (*INTERFACEFINDER) (void *pThis, DWORD dwData, REFIID riid, void **ppv);

// pseudo-function to indicate entry is just offset

// псевдофункция для индикации того, что запись просто

// является смещением

#define ENTRYISOFFSET INTERFACEFINDER(-1)

// basic table layout // представление базовой таблицы

typedef struct INTERFACEENTRY

{

const IID * pIID;

// the IID to match

// соответствующий IID

INTERFACEFINDER pfnFinder;

// функция finder DWORD dwData;

// offset/aux data

// данные по offset/aux

} INTERFACEENTRY;

Заголовочный файл также содержит следующие макросы для создания интерфейсных таблиц внутри определения класса:

// Inttable.h (book-specific header file)

// Inttable.h (заголовочный файл, специфический для данной книги)

#define BASEOFFSET(ClassName, BaseName) \ (DWORD(staticcast(reinterpretcast\ (0x10000000))) – 0х10000000)

#define BEGININTERFACETABLE(ClassName) \ typedef ClassName ITCls;\ const INTERFACEENTRY *GetInterfaceTable(void) {\ static const INTERFACEENTRY table [] = {\

#define IMPLEMENTSINTERFACE(Itf) \ {&IID##Itf,ENTRYISOFFSET,BASEOFFSET(ITCls,Itf)},

#define IMPLEMENTSINTERFACEAS(req, Itf) \ {&IID##req,ENTRYISOFFSET, BASEOFFSET(ITCls, Itf)},

#define ENDINTERFACETABLE() \ { 0, 0, 0 } }; return table; }

Все, что требуется, – это стандартная функция, которая может анализировать интерфейсную таблицу в ответ на запрос QueryInterface. Такая функция содержится в файле Inttable.h:

// inttable.cpp (book-specific source file)

// inttable.h (заголовочный файл, специфический для данной книги)

HRESULT InterfaceTableQueryInterface(void *pThis, const INTERFACEENTRY *pTable, REFIID riid, void **ppv)

{

if (InlineIsEqualGUID(riid, IIDIUnknown))

{

// first entry must be an offset

// первый элемент должен быть смещением

*ppv = (char*)pThis + pTable->dwData;

((Unknown*) (*ppv))->AddRef () ;

// A2

return SOK;

} else

{

HRESULT hr = ENOINTERFACE;

while (pTable->pfnFinder)

{

// null fn ptr == EOT

if (!pTable->pIID || InlineIsEqualGUID(riid,*pTable->pIID))

{

if (pTable->pfnFinder == ENTRYISOFFSET)

{

*ppv = (char*)pThis + pTable->dwData;

((IUnknown*)(*ppv))->AddRef();

// A2

hr = SOK;

break;

} else

{

hr = pTable->pfnFinder(pThis, pTable->dwData, riid, ppv);

if (hr == SOK) break;

}

}

pTable++;

}

if (hr!= SOK)

*ppv = 0;

return hr;

}

}

Получив указатель на запрошенный объект, InterfaceTableQueryInterface сканирует таблицу в поисках элемента, соответствующего запрошенному IID, и либо добавляет соответствующее смещение, либо вызывает соответствующую функцию. Приведенный выше код использует усовершенствованную версию IsEqualGUID, которая генерирует несколько больший код, но результаты по скорости примерно на 20-30 процентов превышают данные по существующей реализации, которая не управляется таблицей. Поскольку код для InterfaceTableQueryInterface появится в исполняемой программе только один раз, это весьма неплохой компромисс.

Очень легко автоматизировать поддержку СОМ для любого класса C++, основанную на таком табличном управлении, простым использованием С-препроцессора. Следующий фрагмент из заголовочного файла impunk.h определяет QueryInterface, AddRef и Release для объекта, использующего интерфейсные таблицы и расположенного в динамически распределяемой области памяти:

// impunk.h (book-specific header file)

// impunk.h (заголовочный файл, специфический для данной книги)

// AUTOLONG is just a long that constructs to zero

// AUTOLONG – это просто long, с конструктором,

// устанавливающим значение в О

struct AUTOLONG

{

LONG value;

AUTOLONG (void) : value (0) {}

};

#define IMPLEMENTUNKNOWN(ClassName)

\ AUTOLONG mcRef;

\ STDMETHODIMP QueryInterface(REFIID riid, void **ppv){

\ return InterfaceTableQueryInterface(this,

\ GetInterfaceTable(), riid, ppv);

\ }

\ STDMETHODIMP(ULONG) AddRef(void) {

\ return InterlockedIncrement(&mcRef.value);

\ }

\ STDMETHODIMP(ULONG) Release(void) {

\ ULONG res = InterlockedDecrement(&mcRef.value) ;

\ if (res == 0)

\ delete this;

\ return res;

\ }

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

Для реализации примера PugCat, уже встречавшегося в этой главе, необходимо всего лишь удалить текущие реализации QueryInterface, AddRef и Release и добавить соответствующие макросы:

class PugCat : public IPug, public ICat

{

protected:

virtual ~PugCat(void);

public: PugCat(void);

// IUnknown methods

// методы IUnknown

IMPLEMENTUNKNOWN (PugCat)

BEGININTERFACETABLE(PugCat)

IMPLEMENTSINTERFACE(IPug)

IMPLEMENTSINTERFACE(IDog)

IMPLEMENTSINTERFACEAS(IAnimal,IDog)

IMPLEMENTSINTERFACE(ICat)

ENDINTERFACETABLE()

// IAnimal methods

// методы IAnimal

STDMETHODIMP Eat(void);

// IDog methods

// методы IDog

STDMETHODIMP Bark(void);

// IPug methods

// методы IPug

STDMETHODIMP Snore(void);

// ICat methods

// методы ICat

STDMETHODIMP IgnoreMaster(void);

};

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

 

Типы данных

Все интерфейсы СОМ должны быть определены в IDL. IDL позволяет описывать довольно сложные типы данных в стиле, не зависящем от языка и платформы. Рисунок 2.6 показывает базовые типы, которые поддерживаются IDL, и их отображения в языки С, Java и Visual Basic. Целые и вещественные типы не требуют объяснений. Первые «интересные» типы данных, встречающиеся при программировании в СОМ, – это символы и строки.

Все символы в СОМ представлены с использованием типа данных OLECHAR. Для Windows NT, Windows 95, Win32s и Solaris OLECHAR – это просто typedef для типа данных С wchar_t. Специфика других платформ описана в соответствующих документациях. Платформы Win32 используют тип данных wchar_t для представления 16-битных символов Unicode. Поскольку типы указателей в IDL созданы так, что указывают на одиночные переменные, а не на массивы, то IDL вводит атрибут [string], чтобы подчеркнуть, что указатель указывает на массив-строку с завершающим нулем:

HRESULT Method([in, string] const OLECHAR *pwsz);

Для определения строк и символов, совместимых с OLECHAR, в СОМ введен макрос OLESTR, который приписывает букву L перед строковой или символьной константой, информируя таким образом компилятор о том, что эта константа имеет тип wchar_t. Например, правильным будет такой способ инициализировать указатель OLECHAR с помощью строкового литерала:

const OLECHAR *pwsz = OLESTR(«Hello»);

Под Win32 или Solaris это эквивалентно

const wchar_t *pwsz = L"Hello";

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

Поскольку часто возникает необходимость копировать строки на основе типа wchar_t в обычные буфера на основе char, то динамическая библиотека С предлагает две процедуры для преобразования типов:

size_t mbstowcs(wchar_t *pwsz, const char *psz, int cch);

size_t wcstombs(char *psz, const wchar_t *pwsz, int cch);

Эти две процедуры работают аналогично динамической С-процедуре strncpy, за исключением того, что в эти процедуры как часть операции копирования включено расширение или сужение строки. Следующий код показывает, как параметр метода, размещенный в OLECHAR, можно скопировать в элемент данных, размещенный в char:

class BigDog : public ILabrador

{

char m_szName[1024] ;

public:

STDMETHODIMP SetName(/* [in,string]*/ const OLECHAR *pwsz)

{

HRESULT hr = S_OK;

size_t cb = wcstombs(m_szName, pwsz, 1024);

// check for buffer overflow or bad conversion

// проверяем переполнение буфера или неверное преобразование

if (cb == sizeof(m_szName) || cb == (size_t)-1)

{

m_szName[0] = 0; hr = E_INVALIDARG;

}

return hr;

}

};

Этот код является довольно простым, хотя программист должен осознавать, что используются два различных типа символов. Несколько более сложный (и чаще встречающийся) случай – преобразование между типами данных OLECHAR и TCHAR из Win32. Так как OLECHAR условно компилируется как char или wchar_t, то при реализации метода необходимо должным образом рассмотреть оба сценария:

class BigDog : public ILabrador

{

TCHAR m_szName[1024];

// note TCHAR-based string

// отметим строку типа TCHAR

public:

STDMETHODIMP SetName( /*[in,string]*/ const OLECHAR *pwsz)

{

HRESULT hr = S_OK;

#ifdef UNICODE

// Unicode build (TCHAR == wchar_t)

// конструкция Unicode (TCHAR == wchar_t)

wcsncpy(m_szName, pwsz, 1024);

// check for buffer overflow

// проверка на переполнение буфера

if (m_szName[1023] != 0)

{

m_szName[0] = 0;

hr = E_INVALIDARG;

}

#else

// Non-Unicode build (TCHAR == char)

// не является конструкцией Unicode (TCHAR == char)

size_t cb = wcstombs(m_szName, pwsz, 1024);

// check for buffer overflow or bad conversion

// проверка переполнения буфера или ошибки преобразования

if (cb == sizeof(m_szName) || cb == (size_t)-1)

{

m_szName[0] =0;

hr = E_INVALIDARG; 

} 

#endif return hr;

}

};

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

Одним из подходов к упрощению преобразования текста является применение системы типов C++ и использование перегрузки функций для выбора нужной строковой процедуры, построенной на типах параметров. Заголовочный файл ustring.h из приложения к этой книге содержит семейство библиотечных строковых процедур, аналогичных стандартным библиотечным процедурам С, которые находятся в файле string.h. Например, функция strncpy имеет четыре соответствующих процедуры, зависящие от каждого из параметров, которые могут быть одного из двух символьных типов (wchar_t или char):

// from ustring.h (book-specific header)

// из ustring.h (заголовок, специфический для данной книги)

inline bool ustrncpy(char *p1, const wchar_t *p2, size_t c)

{

size_t cb = wcstombs(p1, p2, c);

return cb != c && cb != (size_t)-1;

};

inline bool ustrncpy(wchar_t *p1, const wchar_t *p2, size_t c)

{

wcsncpy(p1, p2, c);

return p1[c – 1] == 0;

};

inline bool ustrncpy(char *p1, const char *p2, size_t c)

{

strncpy(p1, p2, c);

return p1[c – 1] == 0;

};

inline bool ustrncpy(wchar_t *p1, const char *p2, size_t c)

{

size_t cch = mbstowcs(p1, p2, c);

return cch != c && cch != (size_t)-1;

}

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

class BigDog : public ILabrador

{

TCHAR m_szName[1024];

// note TCHAR-based string

// отметим строку типа TCHAR

public:

STDMETHODIMP SetName(/* [in,string] */ const OLECHAR *pwsz)

{

HRESULT hr = S_OK;

// use book-specific overloaded ustrncpy to copy or convert

// используем для копирования и преобразования

// перегруженную функцию ustrncpy, специфическую для данной книги

if (!ustrncpy(m_szName, pwsz, 1024))

{

m_szName[0] = 0;

hr = E_INVALIDARG;

} return hr;

}

};

Соответствующие перегруженные функции для процедур strlen, strcpy и strcat также включены в заголовочный файл ustring.h.

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

HRESULT IIDFromHWND(HWND hwnd, IID& riid)

{

TCHAR szEditText[1024];

// call a TCHAR-based Win32 routine

// вызываем TCHAR-процедуру Win32

GetWindowText(hwnd, szEditText, 1024);

// call an OLECHAR-based СОМ routine

// вызываем OLECHAR-процедуру СОМ

return IIDFromString(szEditText, &riid);

}

Допуская, что этот код скомпилирован с указанным символом С-препроцессора UNICODE; он работает безупречно, так как TCHAR и OLECHAR являются просто псевдонимами wchar_t и никакого преобразования не требуется. Если же функция скомпилирована с версией Win32 API, не поддерживающей Unicode, то TCHAR является псевдонимом для char, и первый параметр для IIDFromString имеет неправильный тип. Чтобы решить эту проблему, нужно провести условную компиляцию:

HRESULT IIDFromHWND(HWND hwnd, IID& riid)

{

TCHAR szEditText[1024];

GetWindowText(hwnd, szEditText, 1024);

#ifdef UNICODE return IIDFromString(szEditText, &riid);

#else OLECHAR wszEditText[l024];

ustrncpy(wszEditText, szEditText, 1024);

return IIDFromString(wszEditText, &riid);

#endif

}

Хотя этот фрагмент и генерирует оптимальный код, очень утомительно применять эту технику всякий раз, когда символьный параметр имеет неверный тип. Можно справиться с этой проблемой, если использовать промежуточный (shim) класс с конструктором, принимающим в качестве параметра любой тип символьной строки. Этот промежуточный класс должен также содержать в себе операторы приведения типа, что позволит использовать его в обоих случаях: когда ожидается const char * или const wchar_t *. В этих операциях приведения промежуточный класс либо выделяет резервный буфер и производит необходимое преобразование, либо просто возвращает исходную строку, если преобразования не требовалось. Деструктор промежуточного класса может затем освободить все выделенные буферы. Заголовочный файл ustring.h содержит два таких промежуточных класса: _U и _UNCC. Первый предназначен для нормального использования; второй используется с функциями и методами, тип аргументов которых не включает спецификатора const (таких как IIDFromString). При возможности применения двух промежуточных классов предыдущий фрагмент кода может быть значительно упрощен:

HRESULT IIDFromHWND(HWND hwnd, IID& riid)

{

TCHAR szEditText[1024];

GetWindowText(hwnd, szEditText, 1024);

// use _UNCC shim class to convert if necessary

// используем для преобразования промежуточный класс _UNCC,

// если необходимо

return IIDFromString(_UNCC(szEditText), &riid);

}

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

Следует обсудить еще один дополнительный тип данных, связанный с текстом, – BSTR. Строковый тип BSTR нужно применять во всех интерфейсах, которые предполагается использовать из языков Visual Basic или Java. Строки BSTR являются OLECHAR-строками с префиксом длины (length-prefix) в начале строки и нулем в ее конце. Префикс длины показывает число байт, содержащихся в строке (исключая завершающий нуль) и записан в форме четырехбайтового целого числа, непосредственно предшествующего первому символу строки. Рисунок 2.7 демонстрирует BSTR на примере строки «Hi». Чтобы позволить методам свободно возвращать строки BSTR без заботы о выделении памяти, все BSTR размещены с помощью распределителя памяти, управляемого СОМ. В СОМ предусмотрено несколько API-функций для управления BSTR:

// from oleauto.h

// allocate and initialize a BSTR

// выделяем память и инициализируем строку BSTR

BSTR SysAllocString(const OLECHAR *psz);

BSTR SysAllocStringLen(const OLECHAR *psz, UINT cch);

// reallocate and initialize a BSTR

// повторно выделяем память и инициализируем BSTR

INT SysReAllocString(BSTR *pbstr, const OLECHAR *psz);

INT SysReAllocStringLen(BSTR *pbstr, const OLECHAR * psz, UINT cch);

// free a BSTR

// освобождаем BSTR void SysFreeString(BSTR bstr);

// peek at length-prefix as characters or bytes

// считываем префикс длины как число символов или байт

UINT SysStringLen(BSTR bstr);

UINT SysStringByteLen(BSTR bstr);

При пересылке строк методу в качестве параметров типа [in] вызывающий объект должен заботиться о том, чтобы вызвать SysAllocString прежде, чем запускать сам метод, и чтобы вызвать SysFreeString после того, как метод закончил работу. Рассмотрим следующее определение метода:

HRESULT SetString([in] BSTR bstr);

Пусть в вызывающей программе уже имеется строка, совместимая с OLECHAR, тогда для того, чтобы преобразовать строку в BSTR до вызова метода, необходимо следующее:

// convert raw OLECHAR string to a BSTR

// преобразовываем «сырую» строку OLECHAR в строку BSTR

BSTR bstr = SysAllocString(OLESTR(«Hello»));

// invoke method

// вызываем метод HRESULT hr = p->SetString(bstr);

// free BSTR

// освобождаем BSTR SysFreeString(bstr);

Промежуточный класс для работы с BSTR, _UBSTR, включен в заголовочный файл ustring.h:

// from ustring.h (book-specific header file)

// из ustring.h (специфический для данной книги заголовочный файл)

class _UBSTR

{

BSTR m_bstr;

public:

_UBSTR(const char *psz) : m_bstr(SysAllocStringLen(0, strlen(psz)))

{

mbstowcs(m_bstr, psz, INT_MAX);

}

_UBSTR(const wchar_t *pwsz) : m_bstr(SysAllocString(pwsz))

{

}

operator BSTR (void) const

{ return m_bstr; }

~_UBSTR(void)

{ SysFreeString(m_bstr); }

};

При наличии такого промежуточного класса предыдущий фрагмент кода значительно упростится:

// invoke method

// вызываем метод

HRESULT hr = p->SetString(_UBSTR(OLESTR(«Hello»)));

Заметим, что в промежуточном классе UBSTR могут быть в равной степени использованы строки типов char и wchar_t.

При передаче из метода строк через параметры типа [out] объект обязан вызвать SysAllocString, чтобы записать результирующую строку в буфер. Затем вызывающий объект должен освободить буфер путем вызова SysFreeString. Рассмотрим следующее определение метода:

HRESULT GetString([out, retval] BSTR *pbstr);

При реализации метода потребуется создать новую BSTR-строку для возврата вызывающему объекту:

STDMETHODIMP MyClass::GetString(BSTR *pbstr)

{

*pbstr = SysAllocString(OLESTR(«Coodbye!»)) ;

return S_OK;

}

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

extern OLECHAR g_wsz[];

BSTR bstr = 0;

HRESULT hr = p->GetString(&bstr);

if (SUCCEEDED(hr))

{

wcscpy(g_wsz, bstr); SysFreeString(bstr);

}

Тут нужно рассмотреть еще один важный аспект BSTR. В качестве BSTR можно передать нулевой указатель, чтобы указать на пустую строку. Это означает, что предыдущий фрагмент кода не совсем корректен. Вызов wcscpy:

wcscpy(g_wsz, bstr);

должен быть защищен от возможных нулевых указателей:

wcscpy (g_wsz, bstr ? bstr : OLESTR(""));

Для упрощения использования BSTR в заголовочном файле ustring.h содержится простая встраиваемая функция:

intline OLECHAR *SAFEBSTR(BSTR b)

{

return b ? b : OLESTR("");

}

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

Простые типы, показанные на рис. 2.6, могут компоноваться вместе с применением структур языка С. IDL подчиняется правилам С для пространства имен тегов (tag namespace). Это означает, что большинство IDL-определений интерфейсов либо используют операторы определения типа (typedef):

typedef struct tagCOLOR

{

double red;

double green;

double blue;

} COLOR;

HRESULT SetColor([in] const COLOR *pColor);

либо должны использовать ключевое слово struct для квалификации имени тега:

struct COLOR { double red; double green; double blue; };

HRESULT SetColor([in] const struct COLOR *pColor);

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

IDL и СОМ поддерживают также объединения (unions). Для обеспечения однозначной интерпретации объединения IDL требует, чтобы в этом объединении имелся дискриминатор (discriminator), который показывал бы, какой именно член объединения используется в данный момент. Этот дискриминатор должен быть целого типа (integral type) и должен появляться на том же логическом уровне, что и само объединение. Если объединение объявлено вне области действия структуры, то оно считается неинкапсулированным (nonencapsulated):

union NUMBER

{

[case(1)] long i;

[case(2)] float f;

};

Атрибут [case] применен для установления соответствия каждого члена объединения своему дискриминатору. Для того чтобы связать дискриминатор с неинкапсулированным объединением, необходимо применить атрибут [switch_is]:

HRESULT Add([in, switch_is(t)] union NUMBER *pn, [in] short t);

Если объединение заключено вместе со своим дискриминатором в окружающую структуру, то этот составной тип (aggregate type) называется инкапсулированным, или размеченным объединением (discriminated union):

struct UNUMBER

{ short t; [switch_is(t)]

union VALUE

{

[case(1)] long i;

[case(2)] float f;

};

};

СОМ предписывает для использования с Visual Basic одно общее размеченное объединение. Это объединение называется VARIANT и может хранить объекты или ссылки на подмножество базовых типов, поддерживаемых IDL. Каждому из поддерживаемых типов присвоено соответствующее значение дискриминатора:

VT_EMPTY nothing

VT_NULL SQL style Null

VT_I2 short

VT_I4 long

VT_R4 float

VT_R8 double

VT_CY CY (64-bit currency)

VT_DATE DATE (double)

VT_BSTR BSTR

VT_DISPATCH IDispatch *

VT_ERROR HRESULT

VT_BOOL VARIANT_BOOL (True=-1, False=0)

VT_VARIANT VARIANT *

VT_UNKNOWN IUnknown *

VT_DECIMAL 16 byte fixed point

VT_UI1 opaque byte

Следующие два флага можно использовать в сочетании с вышеприведенными тегами, чтобы указать, что данный вариант (variant) содержит ссылку или массив данного типа:

VT_ARRAY Указывает, что вариант содержит массив SAFEARRAY

VT_BYREF Указывает, что вариант является ссылкой

СОМ предлагает несколько API-функций для управления VARIANT:

// initialize a variant to empty

// обнуляем вариант

void VariantInit(VARIANTARG * pvarg);

// release any resources held in a variant

// освобождаем все ресурсы, используемые в варианте

HRESULT VariantClear(VARIANTARG * pvarg);

// deep-copy one variant to another

// полностью копируем один вариант в другой

HRESULT VariantCopy(VARIANTARG * plhs, VARIANTARG * prhs);

// dereference and deep-copy one variant into another

// разыменовываем и полностью копируем один вариант в другой

HRESULT VariantCopyInd(VARIANT * plhs, VARIANTARG * prhs);

// convert a variant to a designated type

// преобразуем вариант к указанному типу

HRESULT VariantChangeType(VARIANTARG * plhs, VARIANTARG * prhs, USHORT wFlags, VARTYPE vtlhs);

// convert a variant to a designated type

// преобразуем вариант к указанному типу (с явным указанием кода локализации)

HRESULT VariantChangeTypeEx(VARIANTARG * plhs, VARIANTARG * prhs, LCID lcid, USHORT wFlags, VARTYPE vtlhs);

Эти функции значительно упрощают управление VARIANT'ами. Чтобы понять, как используются эти API-функции, рассмотрим метод, принимающий VARIANT в качестве [in]-параметра:

HRESULT UseIt([in] VARIANT var);

Следующий фрагмент кода демонстрирует, как передать в этот метод целое число:

VARIANT var;

VariantInit(&var);

// initialize VARIANT

// инициализируем VARIANT

V_VT(&var) = VT_I4;

// set discriminator

// устанавливаем дискриминатор

V_I4(&var) = 100;

// set union

// устанавливаем объединение

HRESULT hr = pItf->UseIt(var);

// use VARIANT

// используем VARIANT

VariantClear(&var);

// free any resources in VARIANT

// освобождаем все ресурсы VARIANT

Отметим, что этот фрагмент кода использует макросы стандартного аксессора (accessor) для доступа к элементам данных VARIANT. Две следующие строки

V_VT(&var) = VT_I4;

V_I4(&var) = 100;

эквивалентны коду, который обращается к самим элементам данных:

var.vt = VT_I4;

var.lVal = 100;

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

Ниже приведен пример того, как с помощью приведенной выше технологии реализация метода использует параметр VARIANT в качестве строки:

STDMETHODIMP MyClass::UseIt( /*[in] */ VARIANT var)

{

// declare and init a second VARIANT

// объявляем и инициализируем второй VARIANT

VARIANT var2;

VariantInit(&var2);

// convert var to a BSTR and store it in var2

// преобразуем переменную в BSTR и заносим ее в var2

HRESULT hr = VariantChangeType(&var2, &var, 0, VT_BSTR);

// use the string

// используем строку

if (SUCCEEDED(hr))

{

ustrcpy(m_szSomeDataMember, SAFEBSTR(V_BSTR(&var2)));

// free any resources held by var2

// освобождаем все ресурсы, поддерживаемые var2

VariantClear(&var2);

}

return hr;

}

Отметим, что API-процедура VariantChangeType способна осуществлять сложное преобразование любого переданного клиентом типа из VARIANT в нужный тип (в данном случае BSTR).

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

HRESULT GetObject([out] IDog **ppDog);

Если же тип на этапе проектирования неизвестен, то разработчик интерфейса может дать пользователю возможность задать тип на этапе выполнения. Для поддержки динамически типизируемых интерфейсов в IDL имеется атрибут [iid_is]:

HRESULT GetObject([in] REFIID riid, [out, iid_is(riid)] IUnknown **ppUnk);

Хотя эта форма будет работать вполне хорошо, следующий вариант предпочтительнее из-за его подобия с QueryInterface:

HRESULT GetObject([in] REFIID riid, [out, iid_is(riid)] void **ppv);

Атрибут [iid_is] можно использовать как с параметрами [in], так и [out] для типов IUnknown * или void *. Для того чтобы использовать параметр интерфейса с динамически типизируемым типом, необходимо просто установить IID указателя требуемого типа:

IDog *pDog = 0; HRESULT hr = pItf->GetObject(IID_IDog, (void**)&pDog);

Соответствующая реализация для инициализации этого параметра просто использовала бы метод QueryInterface для нужного объекта:

STDMETHODIMP Class::GetObject(REFIID riid, void **ppv)

{

extern IUnknown * g_pUnkTheDog;

return g_pUnkTheDog->QueryInterface(riid, ppv);

}

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

 

Атрибуты и свойства

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

[ object, uuid(0BB3DAE1-11F4-11d1-8C84-0080C73925BA) ]

interface ICollie : IDog

{

// Age is a read-only property

// Age (возраст) – это свойство только для чтения

[propget] HRESULT Age([out, retval] long *pVal);

// HairCount is a read/write property

// HairCount (счетчик волос) – свойство для чтения/записи

[propget] HRESULT HairCount([out, retval] long *pVal);

[propput] HRESULT HairCount([in] long val);

// CurrentThought is a write-only property

// CurrentThought (текущая мысль) – свойство только для записи

[propput] HRESULT CurrentThought([in] BSTR val);

}

Использование атрибутов [propget] и [propput] информирует компилятор IDL, что методы, которые ему соответствуют, должны быть отображены в преобразователи свойств (property mutators) или в аксессоры на языках, явно поддерживающих свойства. Применительно к Visual Basic это означает, что элементами Age, HairCount и CurrentThought можно манипулировать, используя тот же синтаксис, как при обращении к элементам структуры:

Sub UseCollie(fido as ICollie)

fido.HairCount = fido.HairCount – (fido.Age * 1000)

fido.CurrentThought = «I wish I had a bone»

End Sub

С++-отображение этого интерфейса просто прибавляет к именам методов конструкции put или get, чтобы подсказать программисту, что обращение относится к свойству:

void UseCollie(ICollie *pFido)

{

long n1, n2;

HRESULT hr = pFido->getHairCount(&n1);

assert(SUCCEEDED(hr));

hr = pFido->getAge(&n2);

assert(SUCCEEDED(hr));

hr = pFido->putHairCount(n1 – (n2 * 1000)): assert(SUCCEEDED(hr));

BSTR bstr = SysAllocString(OLESTR(«I wish I had a bone»));

hr = pFido->putCurrentThought(bstr);

assert(SUCCEEDED(hr));

SysFreeString(bstr);

} 

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

 

Исключения

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

// throw an exception

// возбуждаем исключения

HRESULT SetErrorInfo([in] ULONG reserved, //

m.b.z. [in] IErrorlnfo *pei);

// catch an exception

// перехватываем исключение

HRESULT GetErrorInfo([in] ULONG reserved, // m.b.z.

[out] IErrorInfo **ppei);

Процедура SetErrorInfo вызывается из реализации метода, чтобы связать объект исключения с текущим логическим потоком (logical thread). GetErrorInfo выбирает объект исключения из текущего логического потока и сбрасывает исключение, так что следующие вызовы GetErrorInfo возвратят SFALSE, показывая тем самым, что необработанных исключений нет. Как следует из приведенных ниже подпрограмм, объекты исключений должны поддерживать по крайней мере интерфейс IErrorInfo:

[ object, uuid(1CF2B120-547D-101B-8E65-08002B2BD119) ]

interface IErrorInfo: IUnknown

{

// get IID of interface that threw exception

// получаем IID того интерфейса, который возбудил исключение

HRESULT GetGUID([out] GUID * pGUID);

// get class name of object that threw exception

// получаем имя класса того объекта, который возбудил исключение

HRESULT GetSource([out] BSTR * pBstrSource);

// get human-readable description of exception

// получаем читабельное описание исключения

HRESULT GetDescription([out] BSTR * pBstrDescription);

// get WinHelp filename of documentation of error

// получаем имя файла WinHelp, содержащего документацию об ошибке

HRESULT GetHelpFile([out] BSTR * pBstrHelpFile);

// get WinHelp context ID for documentation of error

// получаем контекстный идентификатор WinHelp для документации ошибки

HRESULT GetHelpContext([out] DWORD * pdwHelpContext);

}

Специальные объекты исключений могут выбрать другие специфические для исключений интерфейсы в дополнение к IErrorInfo.

СОМ предусматривает по умолчанию реализацию IErrorInfo, которую можно создать с использованием API-функции СОМ CreateErrorInfo:

HRESULT CreateErrorInfo([out] ICreateErrorInfo **ppcei);

В дополнение к IErrorInfo объекты исключений по умолчанию открывают интерфейс ICreateErrorInfo, чтобы позволить пользователю инициализировать состояние нового исключения:

[ object, uuid(22F03340-547D-101B-8E65-08002B2BD119) ]

interface ICreateErrorInfo: IUnknown

{

// set IID of interface that threw exception

// устанавливаем IID интерфейс, который возбудил исключение

HRESULT SetGUID([in] REFGUID rGUID);

// set class name of object that threw exception

// устанавливаем классовое имя объекта, который возбудил исключение

HRESULT SetSource([in, string] OLECHAR* pwszSource);

// set human-readable description of exception

// устанавливаем читабельное описание исключения

HRESULT SetDescription([in, string] OLECHAR* pwszDesc);

// set WinHelp filename of documentation of error

// устанавливаем имя файла WinHelp, содержащего документацию об ошибке

HRESULT SetHelpFile([in, string] OLECHAR* pwszHelpFile);

// set WinHelp context ID for documentation of error

// устанавливаем идентификатор контекста WinHelp для документации ошибки

HRESULT SetHelpContext([in] DWORD dwHelpContext);

}

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

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

STDMETHODIMP PugCat::Snore(void)

{

if (this->IsAsleep())

// ok to perform operation?

// можно ли выполнять операцию?

return this->DoSnore();

//do operation and return

// выполняем операцию и возвращаемся

//otherwise create an exception object

// в противном случае создаем объект исключений

ICreateErrorInfo *рсеi = 0; HRESULT hr = CreateErrorInfo(&pcei);

assert(SUCCEEDED(hr));

// initialize the exception object

// инициализируем объект исключений

hr = pcei->SetGUID(IIDIPug);

assert(SUCCEEDED(hr));

hr = pcei->SetSource(OLESTR(«PugCat»));

assert(SUCCEEDED(hr));

hr = pcei->SetDescription(OLESTR("I am not asleep!"));

assert(SUCCEEDED(hr));

hr = pcei->SetHelpFile(OLESTR(«C:\\PugCat.hlp»));

assert(SUCCEEDED(hr));

hr = pcei->SetHelpContext(5221);

assert(SUCCEEDED(hr));

// «throw» exception

// «выбрасываем» исключение

IErrorInfo *pei = 0;

hr = pcei->QueryInterface(IIDIErrorInfo, (void**)&pei);

assert(SUCCEEDED(hr));

hr = SetErrorInfo(0, pei);

// release resources and return a SEVERITYERROR result

// высвобождаем ресурсы и возвращаем результат

// SEVERITYERROR (серьезность ошибки)

pei->Release();

pcei->Release();

return PUGEPUGNOTASLEEP;

}

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

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

[ object, uuid(DFOB3060-548F-101B-8E65-08002B2BD119) ]

interface ISupportErrorInfo: IUnknown

{

HRESULT InterfaceSupportsErrorInfo([in] REFIID riid);

}

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

STDMETHODIMP PugCat::InterfaceSupportsErrorInfo(REFIID riid)

{

if (riid == IIDIAnimal || riid == IIDICat || riid == IIDIDog || riid == IIDIPug) return SOK;

else return SFALSE;

}

Ниже приведен пример клиента, который надежно обрабатывает исключения, используя ISupportErrorInfo и GetErrorInfo:

void TellPugToSnore(/*[in]*/ IPug *pPug)

{

// call a method

// вызываем метод

HRESULT hr = pPug->Snore();

if (FAILED(hr))

{

// check to see if object supports СОМ exceptions

// проверяем, поддерживает ли объект исключения СОМ

ISupportErrorInfo *psei = 0;

HRESULT hr2 =pPug->QueryInterface( IIDISupportErrorInfo, (void**)&psei);

if (SUCCEEDED(hr2))

{

// check if object supports СОМ exceptions via IPug methods

// проверяем, поддерживает ли объект исключения СОМ через методы

IPug hr2 = psei->InterfaceSupportsErrorInfo(IIDIPug);

if (hr2 == SOK)

{

// read exception object for this logical thread

// читаем объект исключений для этого логического потока

IErrorInfo *реi = 0;

hr2 = GetErrorInfo(0, &pei);

if (hr2 == SOK)

{

// scrape out source and description strings

// извлекаем строки кода и описания

BSTR bstrSource = 0, bstrDesc = 0;

hr2 = pei->GetDescription(&bstrDesc);

assert(SUCCEEDED(hr2));

hr2 = pei->GetSource(&bstrSource);

assert(SUCCEEDED(hr2));

// display error information to end-user

// показываем информацию об ошибке конечному пользователю

MessageBoxW(0, bstrDesc ? bstrDesc : L"«, bstrSource ? bstrSource : L»", MBOK);

// free resources

// высвобождаем ресурсы

SysFreeString(bstrSource);

SysFreeString(bstrDesc);

pei->Release();

}

}

psei->Release();

}

}

if (hr2!= SOK)

// something went wrong with exception

// что-то неладно с исключением

MessageBox(0, «Snore Failed», «IPug», MBOK);

}

Довольно просто отобразить исключения СОМ в исключения C++, причем в любом месте. Определим следующий класс, который упаковывает объект исключений СОМ и HRESULT в один класс C++:

struct COMException

{

HRESULT mhresult;

// hresult to return

// hresult для возврата IErrorInfo *mpei;

// exception to throw

// исключение для выбрасывания

COMException(HRESULT hresult, REFIID riid, const OLECHAR *pszSource, const OLECHAR *pszDesc, const OLECHAR *pszHelpFile = 0, DWORD dwHelpContext = 0)

{

// create and init an error info object

// создаем и инициализируем объект информации об ошибке

ICreateErrorInfo *рсеi = 0;

HRESULT hr = CreateErrorInfo(&pcei);

assert(SUCCEEDED(hr));

hr = pcei->SetGUID(riid);

assert(SUCCEEDED(hr));

if (pszSource) hr=pcei->SetSource(constcast(pszSource));

assert(SUCCEEDED(hr));

if (pszDesc) hr=pcei->SetDescription(constcast(pszDesc));

assert(SUCCEEDED(hr));

if (pszHelpFile) hr=pcei->SetHelpFile(constcast(pszHelpFile));

assert(SUCCEEDED(hr));

hr = pcei->SetHelpContext(dwHelpContext);

assert(SUCCEEDED(hr));

// hold the HRESULT and IErrorInfo ptr as data members

// сохраняем HRESULT и указатель IErrorInfo как элементы данных

mhresult = hresult;

hr=pcei->QueryInterface(IIDIErrorInfo, (void**)&mpei);

assert(SUCCEEDED(hr));

pcei->Release();

}

};

С использованием только что приведенного С++-класса COMException показанный выше метод Snore может быть модифицирован так, чтобы он преобразовывал любые исключения C++ в исключения СОМ:

STDMETHODIMP PugCat::Snore(void)

{

HRESULT hrex = SOK;

try

{

if (this->IsAsleep()) return this->DoSnore();

else throw COMException(PUGEPUGNOTASLEEP, IIDIPug, OLESTR(«PugCat»), OLESTR(«I am not asleep!»));

}

catch (COMException& ce)

{

// a C++ COMException was thrown

// было сброшено исключение COMException C++

HRESULT hr = SetErrorInfo(0, ce.mpei);

assert(SUCCEEDED(hr));

ce.mpei->Release();

hrex = ce.mhresult;

}

catch (…)

{

// some unidentified C++ exception was thrown

// было выброшено какое-то неидентифицированное исключение C++

COMException ex(EFAIL, IIDIPug, OLESTR(«PugCat»), OLESTR(«A C++ exception was thrown»));

HRESULT hr = SetErrorInfo(0, ex.mpei);

assert(SUCCEEDED(hr));

ex.mpei->Release();

hrex = ex.mhresult;

}

return hrex;

}

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

 

Где мы находимся?

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

Большая часть этой главы была посвящена IUnknown – базовому интерфейсу, на котором построен весь СОМ. Все интерфейсы СОМ должны наследовать от IUnknown. Следовательно, все объекты СОМ должны реализовывать IUnknown. В IUnknown предусмотрено три сигнатуры метода, посредством которых клиент может безошибочно управлять иерархией типов объекта для доступа к дополнительным возможностям, предоставляемым этим объектом. С учетом этого QueryInterface можно рассматривать как оператор приведения типа в СОМ. По этой же причине IUnknown можно рассматривать как «void *» (указатель на пустой тип) среди указателей интерфейса, так как от него не слишком много пользы до тех пор, пока он не «приведен» (is «cast») к чему-нибудь более содержательному с помощью QueryInterface.

Следует заметить, что при обращении или реализации IUnknown не было сделано никаких существенных системных вызовов. В этом смысле IUnknown просто является протоколом или набором обещаний (promises), которого должны придерживаться все программы. Это позволяет объектам СОМ быть очень простыми и эффективными. Реализация IUnknown в C++ требует всего нескольких строк стандартного кода. Чтобы автоматизировать реализацию IUnknown в C++, была представлена серия макросов для препроцессора, которые реализуют QueryInterface под табличным управлением. Хотя эти макросы не были совершенно необходимыми, они удаляли большую часть общего стандартного кода из каждого определения класса, не внося при этом заметных усложнений в реализацию.

 

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

 

Снова об интерфейсе и реализации

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

[object, uuid(753A8A7C-A7FF-11d0-8C30-0080C73925BA)]

interface IApe : Unknown

{

import «unknwn.idl»;

HRESULT EatBanana(void);

HRESULT SwingFromTree(void);

[propget] HRESULT Weight([out, retval] long *plbs);

}

Сопровождающая IApe документация должна специфицировать примерную семантику трех операций: EatBanana, SwingFromTree и Weight. Все объекты, раскрывающие IАре посредством QueryInterface , должны гарантировать, что их реализации этих методов придерживаются семантического контракта IАре. В то же время определения интерфейса почти всегда специально оставляют место для интерпретации разработчиком объекта. Это означает, что клиенты никогда не могут быть полностью уверены в точном поведении любого заданного метода, а только в том, что его поведение будет следовать схематическим правилам, описанным в документации к интерфейсу. Эта контролируемая степень неопределенности является фундаментальной характеристикой полиморфизма и одной из основ развития объектно-ориентированного программного обеспечения.

Рассмотрим только что приведенный интерфейс IАре. Вероятно (и даже возможно), что будет более одной реализации интерфейса IАре. Поскольку определение IАре является общим для всех реализаций, то предположения, которые могут сделать клиенты о поведении метода EatBanana, должны быть достаточно неопределенными, чтобы позволить каждой обезьяне – гориллам, шимпанзе и орангутангам (все они могут реализовывать интерфейс IАре ), получить свои допустимые (но слегка различные) интерпретации данной операции. Без этой гибкости полиморфизм невозможен.

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

В смысле инкапсуляции о СОМ-классе известно только его имя и потенциальный список интерфейсов, которые он выставляет. Подобно СОМ-интерфейсам, СОМ-классы именуются с использованием GUID (globally unique identifier – глобально уникальный идентификатор), хотя если GUID используются для именования СОМ-классов, то они называются идентификаторами класса – CLSID. Аналогично именам интерфейсов, эти имена классов должны быть хорошо известны клиенту до того, как он их использует. Поскольку для обеспечения полиморфизма СОМ-интерфейсы являются семантически неопределенными, то СОМ не позволяет клиентам просто запрашивать любую доступную реализацию данного интерфейса. Вместо этого клиенты должны точно специфицировать требуемую реализацию. Это лишний раз подчеркивает тот факт, что СОМ-интерфейсы – это всего лишь абстрактные коммуникационные протоколы, единственное назначение которых – обеспечить клиентам связь с объектами, принадлежащими конкретным, имеющим ясную цель классам реализации .

Кроме того, что реализации могут быть именованы с помощью CLSID, СОМ поддерживает текстовые псевдонимы, так называемые программные идентификаторы (programmatic identifiers), иначе ProgID. Эти ProgID поступают в формате libraryname.classname.version и, в отличие от CLSID, являются уникальными только по соглашению. Клиенты могут преобразовывать ProgID в CLSID и обратно с помощью API-функций СОМ CLSIDFromProgID и ProgIDFromCLSID:

HRESULT CLSIDFromProgID([in, string] const OLECHAR *pwszProgID, [out] CLSID *pclsid);

HRESULT ProgIDFromCLSID([in] REFCLSID rclsid, [out, string] OLECHAR **ppwszProgID);

Для преобразования ProgID в CLSID нужно просто вызвать CLSIDFromProgID:

HRESULT GetGorillaCLSID(CLSID& rclsid)

{

const OLECHAR wszProgID[] = OLESTR(«Apes.Gorilla.1»);

return CLSIDFromProgID(wszProgID, &rclsid);

}

На этапе выполнения будет просматриваться база данных конфигураций СОМ для преобразования ProgID Apes.Gorilla.1 в CLSID, соответствующий классу реализации СОМ.

 

Объекты классов

Основное требование всех СОМ-классов состоит в том, что они должны иметь объект класса. Объект класса – это единственный экземпляр (синглетон), связанный с каждым классом, который реализует функциональность класса, общую для всех его экземпляров. Объект класса ведет себя как метакласс по отношению к заданной реализации, а реализуемые им методы выполняют роль статических функций-членов из C++. По логике вещей, может быть только один объект класса в каждом классе; однако в силу распределенной природы СOМ каждый класс может иметь по одному объекту класса на каждую хост-машину (host machine), на учетную запись пользователя или на процесс, – в зависимости от того, как используется этот класс. Первой точкой входа в реализацию класса является ее объект класса.

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

class GorillaClass : public IApe

{

public:

// class objects are singletons, so don't delete

// объекты класса существуют в единственном экземпляре,

// так что не удаляйте их

IMPLEMENTUNKNOWNNODELETE (GorillaClass)

BEGININTERFACETABLE(GorillaClass)

IMPLEMENTSINTERFACE(IApe)

ENDINTERFACETABLE()

// IApe methods

// методы IApe

STDMETHODIMP EatBanana(void);

STDMETHODIMP SwingFromTree(void);

STDMETHODIMP getWeight(long *plbs);

};

Если для данного класса C++ может существовать лишь один экземпляр (так ведут себя все объекты классов в СОМ), то в любом заданном экземпляре может быть только одна горилла (gorilla). Для некоторых областей одноэлементных множеств достаточно. В случае с гориллами, однако, весьма вероятно, что клиенты могут захотеть создавать приложения, которые будут использовать несколько различных горилл одновременно. Чтобы обеспечить такое использование, объект класса не должен экспортировать интерфейс IApe , а вместо этого должен экспортировать новый интерфейс, который позволит клиентам создавать новых горилл и/или находить известных горилл по их имени. Это потребует от разработчика определить два класса C++: один для реализации объекта класса и другой для реализации действительных экземпляров класса. Для реализации гориллы класс C++, который определяет экземпляры гориллы, будет реализовывать интерфейс IApe:

class Gorilla : public IApe

{

public:

// Instances are heap-based, so delete when done

// копии размещены в куче, поэтому удаляем после выполнения

IMPLEMENTUNKNOWN()

BEGININTERFACETABLE()

IMPLEMENTSINTERFACE(IApe)

ENDINTERFACETABLE()

// IApe methods

// методы IApe

STDMETHODIMP EatBanana(void);

STDMETHODIMP SwingFromTree(void);

STDMETHODIMP getWeight(long *plbs):

};

Второй интерфейс понадобится для определения тех операций, которые будет реализовывать объект класса Gorilla:

[object, uuid(753A8AAC-A7FF-11d0-8C30-0080C73925BA)]

interface IApeClass : IUnknown

{

HRESULT CreateApe([out, retval] IApe **ppApe);

HRESULT GetApe([in] long nApeID, [out, retval] IApe **ppApe);

[propget]

HRESULT AverageWeight([out, retval] long *plbs);

}

Получив это определение интерфейса, объект класса будет реализовывать методы IApeClass или путем создания новых экземпляров С++-класса Gorilla (в случае CreateApe), или преобразованием произвольно выбранного имени объекта (в данном случае типа integer) в отдельный экземпляр (в случае GetApe):

class GorillaClass : public IApeClass

{

public: IMPLEMENTUNKNOWNNODELETE(GorillaClass)

BEGININTERFACETABLE(GorillaClass)

IMPLEMENTSINTERFACE(IApeClass)

ENDINTERFACETABLE()

STDMETHODIMP CreateApe(Ape **ppApe)

{

if ((*ppApe = new Gorilla) == 0) return EOUTOFMEMORY;

(*ppApe)->AddRef();

return SOK;

}

STDMETHODIMP GetApe(long nApeID, IApe **ppApe)

{

// assume that a table of well-known gorillas is

// being maintained somewhere else

// допустим, что таблица для известных горилл

// поддерживается где-нибудь еще

extern Gorilla *grgWellKnownGorillas[];

extern int gnMaxGorillas;

// assert that nApeID is a valid index

// объявляем, что nApeID – допустимый индекс

*ррАре = 0;

if (nApeID > gnMaxGorillas || nApeID < 0) return EINVALIDARG;

// assume that the ID is simply the index into the table

// допустим, что ID – просто индекс в таблице

if ((*ppApe = grgWellKnownGorillas[nApeID]) == 0) return EINVALIDARG;

(*ppApe)->AddRef();

return SOK;

}

STDMETHODIMP getAverageWeight(long *plbs)

{

extern *grgWellKnownGorillas[];

extern int gnMaxGorillas;

*plbs = 0;

long lbs;

for (int i = 0; i < gnMaxGorillas; i++)

{

grgWellKnownGorillas[i]->getWeight(&lbs);

*plbs += lbs;

}

// assumes gnMaxGorillas is non-zero

// предполагается, что gnMaxGorillas ненулевой

*plbs /= gnMaxGorillas;

return SOK;

}

};

Отметим, что в этом коде предполагается, что внешняя таблица известных горилл уже поддерживается – или самими копиями Gorilla, или каким-нибудь другим посредником (agent).

 

Активация

Клиентам требуется механизм для поиска объектов класса. В силу динамической природы СОМ это может привести к загрузке библиотеки DLL или запуску обслуживающего процесса (server process). Эта процедура вызова объекта к жизни называется активацией объекта.

В СОМ имеется три модели активации, которые можно использовать для занесения объектов в память, чтобы сделать возможными вызовы методов. Клиенты могут попросить СОМ связать объект класса с данным классом. Кроме того, клиенты могут попросить, чтобы СОМ создала новые экземпляры классов, определенные с помощью CLSID. Наконец, клиенты могут попросить СОМ вызвать к жизни перманентный (persistent) объект, состояние которого определено как постоянное. Из этих трех моделей только первая (связывание с объектом класса) является абсолютно необходимой. Две другие модели являются просто оптимизациями обычно применяющихся способов активации. Дополнительные, определенные пользователем, модели активации могут быть реализованы в терминах одного (или более) из этих трех примитивов.

Каждая из описанных трех моделей активации пользуется услугами имеющегося в СОМ диспетчера управления сервисами SCM (Service Control Manager). SCM является основной точкой рандеву для всех запросов на активацию в каждой отдельной машине. Каждая хост-машина, поддерживающая СОМ, имеет свой собственный локальный SCM, который переадресовывает удаленные запросы на активацию на SCM удаленной машины, где этот запрос будет трактоваться как локальный запрос на активацию. SCM используется только для того, чтобы активировать объект и привязать к нему начальный указатель интерфейса. Как только объект активирован, SCM более не связан с вызовом методов клиента и объекта. Как показано на рис. 3.1, под Windows NT SCM реализован в службе RPCSS (Remote Procedure Call Service System – система сервиса удаленного вызова процедур). Службы SCM объявляются в программы как высокоуровневые типы моникеров и как низкоуровневые API-функции, причем все они реализованы в библиотеке СОМ (как это называется в Спецификации СОМ). Под Windows NT большая часть библиотеки СОМ реализована в OLE32.DLL. Для повышения эффективности библиотека СОМ может использовать локальный или кэшированный режим, чтобы избежать ненужных запросов службы RPCSS со стороны IPC (interprocess communication – межпроцессное взаимодействие).

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

Когда объект активирован внутри процесса, то в процесс клиента загружается та библиотека DLL, которая реализует методы объекта, и все данные-члены хранятся в адресном пространстве клиента. Так как не требуется никаких переключении процессов, то эффективность вызова методов чрезвычайно высока. Кроме того, клиентский поток может быть использован для прямого выполнения кода метода, при условии, что требования по организации поточной обработки (threading requirements) объекта соответствуют клиентским требованиям. Если у клиента и у объекта требования по организации поточной обработки совместимы, то также не нужно никаких переключении потоков. Если вызовы метода могут выполняться с использованием клиентского потока, после активации объекта не требуется участия никакой промежуточной среды времени выполнения, и цена вызова метода просто равна вызову виртуальной функции. Это обстоятельство делает СОМ, встроенный в процесс, особенно хорошо приспособленным для приложений, чувствительных к эффективности выполнения, так как вызов метода обходится не дороже, чем обычный вызов глобальной функции в DLL.

Когда объект активирован извне процесса (то есть в другом процессе на локальной или удаленной машине), то код, реализующий методы объекта, выполняется в процессе определенного сервера и все данные-члены объекта сохраняются в адресном пространстве процесса сервера. Чтобы позволить клиенту связываться с внепроцессным (out-of-process ) объектом, СОМ прозрачно (скрытно от клиента) возвращает ему «заместитель» (proxy ) во время активации. В главе 5 подробно обсуждается, что этот «заместитель» выполняется в клиентском потоке и переводит вызовы метода, преобразованные в RPC-запросы (Remote Procedure Call – удаленный вызов процедуры), в контекст исполнения сервера, где эти RPC-запросы затем преобразуются обратно в вызовы метода текущего объекта. Это делает вызов метода менее эффективным, так как при каждом обращении к объекту требуются переключение потока и переключение процесса. К преимуществам внепроцессной (то есть работающей не в клиентском процессе) активации относятся изоляция ошибок, распределение и повышенная безопасность. В главе 6 внепроцессная активация будет рассматриваться подробно.

 

Использование SCM

Напомним, что SCM поддерживает три примитива активации (связывание с объектами класса, связывание с экземплярами класса, связывание с постоянными экземплярами из файлов). Как показано на рис. 3.2, эти примитивы логически разделены на уровни. Примитивом нижнего уровня является связывание с объектом класса. Этот примитив также наиболее прост для понимания.

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

HRESULT CoGetClassObject(

[in] REFCLSID rclsid,

// which class object?

// Какой объект класса?

[in] DWORD dwClsCtx,

// locality?

//местонахождение?

[in] COSERVERINFO *pcsi,

// host/security info

//сведения о сервере и обеспечении безопасности

[in] REFIID riid,

// which interface?

// какой интерфейс?

[out, iidis(riid)] void **ppv);

// put it here!

// поместим его здесь!

Первый параметр в CoGetClassObject показывает, какой класс реализации запрашивается. Последний параметр – это ссылка на указатель интерфейса, с которым нужно связаться, а четвертый параметр – это просто IID , описывающий тип указателя интерфейса, на который ссылается последний параметр. Более интересные параметры – второй и третий, которые определяют, когда объект класса должен быть активирован.

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

enum tagCLSCTX { CLSCTXINPROCSERVER = 0х1,

// run -inprocess

// запуск в процесс

CLSCTXINPROCHANDLER = 0х2,

// see note

// смотрите сноску

CLSCTXLOCALSERVER = 0х4,

// run out-of-process

// запуск вне процесса

CLSCTXREMOTESERVER = 0х10

// run off-host

// запуск вне хост-машины

} CLSCTX;

Эти флаги могут быть подвергнуты побитному логическому сложению (bit-wise-ORed together), и в случае, когда доступен более чем один запрошенный CLSCTX, СОМ выберет наиболее эффективный тип сервера (это означает, что СОМ будет, когда это возможно, использовать наименее значимый бит битовой маски). Заголовочные файлы SDK также включают в себя несколько сокращенных макросов, которые сочетают несколько флагов CLSCTX , используемых во многих обычных сценариях:

#define CLSCTXINPROC (CLSCTXINPROCSERVER |

\ CLSCTXINPROCHANDLER)

#define CLSCTXSERVER (CLSCTXINPROCSERVER |

\ CLSCTXLOCALSERVER |

\ CLSCTXREMOTESERVER)

#define CLSCTXALL (CLSCTXINPROCSERVER |

\ CLSCTXINPROCHANDLER |

\ CLSCTXLOCALSERVER |

\ CLSCTXREMOTESERVER)

Заметим, что такие среды, как Visual Basic и Java, всегда используют CLSCTXALL, показывая тем самым, что подойдет любая доступная реализация.

Третий параметр CoGetClassObject – это указатель на структуру, содержащую информацию об удаленном доступе и безопасности. Эта структура имеет тип COSERVERINFO и позволяет клиентам явно указывать, какой машине следует активировать объект, а также как конфигурировать установки обеспечения безопасности, используемые при создании запроса на активацию объекта:

typedef struct COSERVERINFO

{

DWORD dwReserved1;

// reserved, must be zero

// зарезервировано, должен быть нуль

LPWSTR pwszName;

// desired host name, or null

// желаемое имя хост-машины или нуль

COAUTHINFO *pAuthInfo;

// desired security settings

// желаемые установки безопасности DWORD dwReserved2;

// reserved, must be zero

// зарезервировано, должен быть нуль

} COSERVERINFO;

Если клиент не указывает имя хоста (host name), а использует только флаг CLSCTXREMOTESERVER, то для определения того, какая машина будет активировать объект, СОМ использует информацию о конфигурации каждого CLSID. Если клиент передает явное имя хоста, то оно получит приоритет перед любыми ранее сконфигурированными именами хостов, о которых может знать СОМ. Если клиент не желает передавать явную информацию о безопасности или имя хоста в CoGetClassObject, можно применить нулевой указатель COSERVERINFO. 

Имея в наличии CoGetClassObject, клиент может дать запрос SCM на связывание указателя интерфейса с объектом класса:

HRESULT GetGorillaClass(IApeClass * &rpgc)

{

// declare the CLSID for Gorilla as a GUID

// определяем CLSID для Gorilla как GUID

const CLSID CLSIDGorilla =

{ 0x571F1680, 0xCC83, 0x11d0,

{ 0x8C, 0х48, 0х00, 0х80, 0xС7, 0х39, 0x25, 0xBA

} };

// call CoGetClassObject directly

// вызываем прямо CoGetClassObject

return CoGetClassObject(CLSIDGorilla, CLSCTXALL, 0, IIDIApeClass, (void**)&rpgc);

}

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

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

HRESULT FindAGorillaAndEatBanana(long nGorillaID)

{

IApeClass *pgc = 0;

// find the class object via CoGetClassObject

// находим объект класса с помощью CoGetClassObject

HRESULT hr = CoGetClassObject(CLSIDGorilla, CLSCTXALL, 0, IIDIApeClass, (void**)&pgc);

if (SUCCEEDED(hr))

{

IApe *pApe = 0;

// use the class object to find an existing gorilla

// используем объект класса для нахождения существующей гориллы

hr = pgc->GetApe(nGorillaID, &pApe);

if (SUCCEEDED(hr))

{

// tell the designated gorilla to eat a banana

// прикажем указанной горилле есть бананы

hr = pApe->EatBanana();

pApe->Release();

}

pgc->Release();

}

return hr;

}

Данный пример использует объект класса для того, чтобы Gorilla нашла именованный объект и проинструктировала его есть бананы. Чтобы этот пример работал, нужно, чтобы какой-нибудь внешний посредник дал вызывающему объекту имя какой-нибудь известной гориллы. Можно построить пример и таким образом, чтобы любая неизвестная горилла могла быть использована для удовлетворения запроса:

HRESULT CreateAGorillaAndEatBanana(void)

{

IApeClass *pgc = 0;

// find the class object via CoGetClassObject

// находим объект класса с помощью CoGetClassObject

HRESULT hr = CoGetClassObject(CLSIDGorilla, CLSCTXALL, 0, IIDIApeClass, (void**)&pgc);

if (SUCCEEDED(hr))

{

IApe *pApe = 0;

// use the class object to create a new gorilla

// используем объект класса для создания новой гориллы

hr = pgc->CreateApe(&pApe);

if (SUCCEEDED(hr))

{

// tell the new gorilla to eat a banana

// прикажем новой горилле есть бананы

hr = pApe->EatBanana();

pApe->Release();

}

pgc->Release();

}

return hr;

}

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

 

Классы и серверы

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

Если в запросе на активацию объекта указана внутрипроцессная активация, то вариант сервера на базе DLL должен быть доступен для загрузки в адресном пространстве клиента. Если же в запросе на активацию указаны внепроцессная или внехостовая активация, то для запуска серверного процесса на указанной хост-машине (она может совпадать с машиной клиента) будет использован исполняемый файл. СОМ поддерживает также выполнение DLL-серверов в суррогатных процессах (surrogate processes) с целью разрешить использование внепроцессной и внехостовой активации существующих внутрипроцессных серверов. Подробности того, как суррогатные процессы связаны с внепроцессной и внехостовой активацией, будут изложены в главе 6.

Чтобы клиенты могли активировать объекты, не беспокоясь о том, как упакован сервер или где он инсталлирован, в СОМ предусмотрена конфигурационная база данных, отображающая CLSID на тот сервер, который реализует этот класс. При использовании версий Windows NT 5.0 или выше основным местом расположения этой конфигурационной базы данных является директория NT (NT Directory). Эта директория является рассредоточенной защищенной базой данных, в которой хранится служебная информация об учетных записях пользователей, хост-машинах и прочее. С тем же успехом в директории NT можно хранить информацию и о СОМ-классах. Эта информация записывается в области директории, называемой СОМ Class Store (хранилище СОМ-классов). СОМ использует Class Store для перевода CLSID в файлы реализации (в случае локальных запросов на активацию) или в удаленные хост-имена (в случае удаленных запросов на активацию). Если запрос на активацию для CLSID сделан на данной машине, то в первую очередь опрашивается локальный кэш. Если в локальном кэше нет доступной конфигурационной информации, то СОМ посылает запрос в Class Store о том, чтобы реализация стала доступной из локальной машины. Это может просто означать добавление некоторой информации в локальный кэш, чтобы переадресовать запрос на другую хост-машину, или же это может привести к загрузке реализации класса на локальную машину и к запуску программы инсталляции. В любом случае, если класс зарегистрирован в Class Store, он доступен для запроса на активацию со стороны клиента в рамках ограничений безопасности.

Локальный кэш, упоминавшийся при обсуждении Class Store, официально называется системным реестром, или базой конфигурации системы (Registry). Реестр является иерархической базой данных, хранящейся в файлах на каждой машине, которую СОМ использует для преобразования CLSID в имена файлов (в случае локальной активации) или удаленные имена хостов (в случае удаленной активации). До Windows NT 5.0 реестр был единственным местом размещения конфигурационной информации СОМ. Быстрый поиск в реестре может быть осуществлен с помощью иерархических ключей (keys), имена которых представляют собой строки, разделенные обратными косыми чертами. Каждый ключ в реестре может иметь одно или несколько значений, которые могут иметь в своем составе строки, целые значения или двоичные данные. В реализации СОМ на Windows NT 4.0 большая часть ее конфигурационной информации записывается под именем

HKEYLOCALMACHINE\Software\Classes

в то время как большинство программ используют более удобный псевдоним

HKEYCLASSESROOT

Реализация СОМ на Windows NT 5.0 продолжает использовать HKEYCLASSESROOT для установок в рамках всей машины, но также разрешает каждому пользователю назначить свою конфигурацию CLSID для обеспечения большей безопасности и гибкости. Под Windows NT 5.0 СОМ вначале опрашивает

HKEYCURRENTUSER\Software\Classes 

прежде чем опрашивать HKEYCLASSESROOT. Для удобства записи часто используются аббревиатуры HKLM, HKCR и HKCU вместо HKEYLOCALMACHINE, HKEYCLASSESROOT и HKEYCURRENTUSER , соответственно. 

СОМ хранит информацию, относящуюся к CLSID всех машин, под ключом реестра HKCR\CLSID

В версии Windows NT 5.0 или выше СОМ ищет информацию о классах каждого пользователя под ключом HKCU\Software\Classes\CLSID

Под одним из этих ключей будет сохранен список локальных CLSID, для каждого CLSID – свой подключ. Например, класс Gorilla, использовавшийся ранее в этой главе, мог бы иметь по всей машине запись по подключу:

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}]

@="Gorilla"

Для обеспечения локальной активации объектов Gorilla запись для CLSID Gorilla в реестре должна иметь подключ, показывающий, какой файл содержит исполняемый код для методов класса. Если сервер упакован как DLL, то требуется такая запись:

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}\InprocServer32]

@="C:\ServerOfTheApes.dll"

Чтобы показать, что код упакован в исполняемом файле, требуется такая запись:

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}\LocalServer32]

@="С:\ServerOfTheApes.exe"

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

[HKCR\CLSID\{571F1680-CC83-11d0-8C48-0080C73925BA}\ProgID]

@="Apes.Gorilla.1"

Наоборот, для поддержки функции CLSIDFromProgID требуются следующие величины:

[HKCR\Apes.Gorilla.1] @="Gorilla" [HKCR\Apes.Gorilla.1\CLSID]

@="\{571F1680-CC83-11d0-8C48-0080C73925BA}

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

Все стандартно реализованные серверы СОМ поддерживают саморегистрацию. Для внутрипроцессного сервера это означает, что DLL должен экспортировать известные функции

STDAPI DllRegisterServer(void);

STDAPI DllUnregisterServer(void);

Отметим, что STDAPI является просто макросом, индицирующим, что функция возвращает НRESULT и использует стандартное соглашение СОМ по вызову глобальных функций. Эти подпрограммы должны быть явно экспортированы с использованием или файла определения модуля, или переключателей компоновщика, или директив компилятора. Эти подпрограммы используются хранилищем классов Class Store для конфигурирования локального кэша после загрузки файла на машину клиента. Кроме Class Store эти известные подпрограммы используются различными средами (например, Microsoft Transaction Server, ActiveX Code Download, а также различными инсталляционными программами) для инсталляции или деинсталляции серверов на хост-машинах. В Win32 SDK включена утилита REGSVR32.EXE, которая может инсталлировать или деинсталлировать внутрипроцессный сервер СОМ с использованием этих известных экспортированных функций.

Реализации внутрипроцессных серверов DllRegisterServer и DllUnregisterServer должны запросить реестр на добавление или удаление соответствующих ключей, преобразующих CLSID и ProgID сервера в файловые имена сервера. Хотя существуют различные способы реализации этих подпрограмм, наиболее гибким и эффективным из них является создание строковой таблицы, содержащей соответствующие ключи, названия величин, сами величины и простое перечисление всех записей в таблице, путем вызова RegSetValueEx для инсталляции и RegDeleteKey для деинсталляции. Чтобы осуществить регистрацию, основанную на этой технологии, сервер может просто задать массив строк размером Nx3 , где каждый ряд массива содержит строки для использования в качестве ключей, имена величин и величины:

const char *gRegTable[][3] = {

// format is { key, value name, value }

{

«CLSID\\{571F1680-CC83-11d0-8C48-0080C73925BA}», 0, «Gorilla»

},

{

"CLSID\\{571F1680-CC83-11d0-8C48-0080C73925BA}

\\InprocServer32",0, (const char*)-1

// rogue value indicating file name

// нестандартное значение, указывающее имя файла

},

{

«CLSID\\{571F1680-CC83-11d0-8C48-0080C73925BA}\\ProgID», 0, «Ареs.Gorilla.1»

},

{

«Apes.Gorillа.1», 0, «Gorilla»

},

{

«Apes.Gorilla.1\\CLSID», 0, «{571F1680-CC83-11d0-8C48-0080C73925BA}»

},

};

Имея эту таблицу, весьма несложно осуществить реализацию DllRegisterServer:

STDAPI DllRegisterServer(void)

{

HRESULT hr = SOK;

// look up server's file name

// ищем имя файла сервера

char szFileName[MAXPATH];

GetModuleFileNameA(ghinstDll, szFileName, MAXPATH);

// register entries from table

// регистрируем записи из таблицы

int nEntries = sizeof(gRegTable)/sizeof(*gRegTable);

for (int i = 0; SUCCEEDED(hr) && i < nEntries; i++)

{

const char *pszKeyName = gRegTable[i][0];

const char *pszValueName = gRegTable[i][1];

const char *pszvalue = gRegTable[i][2];

// map rogue value to module file name

// переводим нестандарное значение в имя файла модуля

if (pszValue == (const char*)-1) pszValue = szFileName;

HKEY hkey;

// create the key

// создаем ключ

long err = RegCreateKeyA(HKEYCLASSESROOT, pszKeyName, &hkey);

if (err == ERRORSUCCESS)

{

// set the value

// присваиваем значение

err = RegSetValueExA(hkey, pszVvalueName, 0, REGSZ, (const BYTE*) pszValue, (strlen(pszValue) + 1));

RegCloseKey(hkey);

}

if (err != ERRORSUCCESS)

{

// if cannot add key or value, back out and fail

// если невозможно добавить ключ или значение, то откат и сбой

DllUnregisterServer();

hr = SELFREGECLASS;

}

}

return hr;

}

Соответствующая DllUnregisterServer будет выглядеть так:

STDAPI DllUnregisterServer(void)

{

HRESULT hr = SOK;

int nEntries = sizeof(gRegTable)/sizeof(*gRegTable);

for (int i = nEntries – 1; i >= 0; i-)

{

const char *pszKeyName = gRegTable[i][0];

long err = RegDeleteKeyA(HKEYCLASSESROOT, pszKeyName);

if (err != ERRORSUCCESS) hr = SFALSE; }

return hr;

}

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

Так как СОМ преобразует CLSID в данный файл реализации, то для объявления в СОМ относящихся к серверу объектов класса необходимо использовать определенные стандартные методики. Для сервера, основанного на исполняемой программе, в СОМ предусмотрены явные API-функции для связывания объектов класса с их CLSID . Эти API-функции мы будем подробно обсуждать в главе 6. Для сервера, основанного на DLL, DLL должна экспортировать известную функцию, которая будет вызываться с помощью CoGetClassObject, когда потребуется объект класса. Эту функцию необходимо экспортировать с использованием файла определения модулей, причем она должна иметь следующий вид:

HRESULT DllGetClassObject(

[in] REFCLSID rclsid,

// which class object?

// какой объект класса?

[in] REFIID riid,

// which interface?

// какой интерфейс?

[out, iidis(riid)] void **ppv);

// put it here!

// разместить его здесь!

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

Рассмотрим сервер, реализующий три класса: Gorilla, Chimp и Orangutan. Сервер, возможно, будет содержать шесть отдельных классов C++: три из них создают экземпляры каждого класса, а другие три – объекты класса для каждого класса. В соответствии с этим сценарием, серверная реализация DllGetClassObject будет выглядеть следующим образом:

STDAPI DllGetClassObject(REFCLSID rclsid, REFIID riid, void **ppv)

{

// define a singleton class object for each class

// определяем одноэлементный объект класса

// для каждого класса

static GorillaClass sgorillaClass;

static OrangutanClass sorangutanClass;

static ChimpClass schimpClass;

// return interface pointers to known classes

// возвращаем указатели интерфейсов известных классов

if (rclsid == CLSIDGorilla) return sgorillaClass.QueryInterface(riid, ppv);

else if (rclsid == CLSIDOrangutan)

return sorangutanClass.QueryInterface(riid, ppv);

else if (rclsid == CLSIDChimp) return schimpClass.QueryInterface(riid, ppv);

// if we get to here, rclsid is a class we don't implement,

// so fail with well-known error code

// если мы добрались сюда, то rclsid – это класс, который

// мы не реализуем, поэтому сбой с известным кодом ошибки

*ppv = 0;

return CLASSECLASSNOTAVAILABLE;

}

Заметим, что приведенный код не заботится о том, какой интерфейс объявляется каждым из объектов класса. Он просто отправляет запрос QueryInterface соответствующему объекту класса.

Следующий псевдокод показывает, как API-функция CoGetClassObject устанавливает связь с серверным DllGetClassObject:

// pseudo-code from OLE32.DLL

// псевдокод из OLE32.DLL

HRESULT CoGetClassObject(REFCLSID rclsid, DWORD dwClsCtx, COSERVERINFO *pcsi , REFIID riid, void **ppv)

{

HRESULT hr = REGDBECLASSNOTREG;

*ppv = 0; if (dwClsCtx & CLSCTXINPROC)

{

// try to perform inproc activation

// пытаемся выполнить внутрипроцессную активацию

HRESULT (*pfnGCO)(REFCLSID, REFIID, void**) = 0;

// look in table of already loaded servers in this process

// просматриваем таблицу уже загруженных серверов внутри

// этого процесса pfnGCO = LookupInClassTable(rclsid, dwClsCtx);

if (pfnGCO == 0) {

// not loaded yet!

// еще не загружен!

// ask class store or registry for DLL name

// запрашиваем DLL-имя в хранилище классов или в реестре

char szFileName[MAXPATH];

hr = GetFileFromClassStoreOrRegistry(rclsid, dwClsCtx, szFileName);

if (SUCCEEDED(hr))

{

// try to load the DLL and scrape out DllGetClassObject

// пытаемся загрузить DLL и вытащить DllGetClassObject

HINSTANCE hInst = LoadLibrary(szFileName);

if (hInst == 0) return COEDLLNOTFOUND;

pfnGCO = GetProcAddress(hInst, «DllGetClassObject»);

if (pfnGCO == 0) return COEERRORINDLL;

// cache DLL for later use

// кэшируем DLL для дальнейшего использования InsertInClassTable(rclsid, dwClsCtx, hInst, pfnGCO);

}

}

// call function to get pointer to class object

// вызываем функцию для получения указателя на объект класса

hr = (*pfnGCO)(rclsid, riid, ppv);

}

if ((dwClsCtx & (CLSCTXLOCALSERVER | CLSCTXREMOTESERVER)) && hr == REGDBECLASSNOTREG)

{

// handle out-of-proc/remote request

// обрабатываем внепроцессный/удаленный запрос

}

return hr;

}

Отметим, что реализация CoGetClassObject является единственным местом, откуда вызывается DllGetClassObject . Чтобы укрепить это обстоятельство, компоновщики в модели СОМ выдадут предупреждение в случае, если входная точка DllGetClassObject экспортируется без использования ключевого слова private в соответствующем файле определения модулей:

// from APELIB.DEF

// из APELIB.DEF LIBRARY

APELIB EXPORTS DllGetClassObject private

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

 

Обобщения

В предыдущем примере интерфейс IApeClass рассматривался как интерфейс уровня класса, специфический для классов, которые объявляют интерфейс IАре из своих экземпляров. Этот интерфейс позволяет клиентам создавать новые объекты или находить существующие, но в любом случае результирующие объекты должны реализовывать интерфейс IАре . Если бы новый класс хотел разрешить клиентам создавать или находить объекты, несовместимые с IApe , то объект этого класса должен был бы реализовывать другой интерфейс. Поскольку создание и поиск объектов являются общими требованиями, которые большинство классов хотели бы поддерживать, СОМ определяет стандартные интерфейсы для моделирования поиска и создания объектов унифицированным образом (generically). Один стандартный интерфейс для поиска объектов назван IOleItemContainer:

// from oleidl.idl из oleidl.idl

[ object, uuid(0000011c-0000-0000-C000-000000000046) ]

interface IOleItemContainer : IOleContainer {

// ask for object named by pszItem

// запрашиваем объект, именованный

pszItem HRESULT Get0bject(

[in] LPOLESTR pszItem,

// which object? какой объект?

[in] DWORD dwSpeedNeeded,

// deadline

[in, unique] IBindCtx *pbc,

// binding info информация о связывании

[in] REFIID riid,

// which interface? какой интерфейс?

[out, iidis(riid)] void **ppv);

// put it here! разместим его здесь!

// remaining methods deleted for clarity

// остальные методы удалены для ясности

}

Отметим, что метод GetObject позволяет клиенту задавать тип результирующего интерфейсного указателя. Действительный класс результирующего объекта зависит от контекста и конкретной реализации IOleItemContainer . Следующий пример запрашивает объект класса Gorilla найти объект под именем «Ursus»:

HRESULT FindUrsus(IApe * &rpApe)

{

// bind a reference to the class object

// связываем ссылку с объектом класса

rpApe = 0;

IOleItemContainer *poic = 0;

HRESULT hr = CoGetClassObject(CLSIDGorilla, CLSCTXALL, 0, IIDIOleItemContainer, (void**)&poic);

if (SUCCEEDED(hr))

{

// ask Gorilla class object for Ursus

// запрашиваем объект класса Gorilla на поиск

Ursus hr = poic->GetObject(OLESTR(«Ursus»), BINDSPEEDINDEFINITE, 0, IIDIApe, (void**)&rpApe);

poic->Release();

}

return hr;

}

Хотя такое использование вполне допустимо, интерфейс IOleItemContainer был предназначен для работы в тандеме с моникером элемента (Item Moniker), который будет рассматриваться позже в данной главе.

В СОМ определен еще один стандартный интерфейс для создания объектов. Он называется IClassFactory:

// from unknwn.idl из unknwn.idl

[ object, uuid(00000001-0000-0000-C000-000000000046) ]

interface IClassFactory : IUnknown

{

HRESULT CreateInstance( [in] IUnknown *pUnkOuter, [in] REFIID riid, [out, iidis(riid)] void **ppv) ;

HRESULT LockServer([in] BOOL bLock);

}

Хотя экземпляры класса могли бы экспортировать интерфейс IClassFactory, данный интерфейс обычно экспортируется только объектами класса. Объекты класса не обязаны реализовывать IClassFactory, но, для единообразия, они часто делают это. В момент написания этой книги классы, которые будут встраиваться в среду Microsoft Transaction Server (MTS), должны реализовывать IClassFactory (фактически никакие другие интерфейсы объектов класса не будут распознаваться в MTS).

Интерфейс IClassFactory имеет два метода: LockServer и CreateInstance. Метод LockServer вызывается внутри СОМ во время запроса на внепроцессную активацию и подробно обсуждается в главе 6. Метод CreateInstance используется для запроса на создание объектом класса нового экземпляра класса. Как было в случае IApeClass::CreateApe, тип объекта, который будет подвергаться обработке, определяется объектом класса, которому клиент посылает запрос CreateInstance. Первый параметр CreateInstance используется в агрегировании СОМ и обсуждается в главе 4. Пока же, в рамках третьей главы, для простоты изложения положим этот параметр равным нулю. Второй и третий параметры CreateInstance позволяют методу возвращать клиенту динамически типизируемый указатель интерфейса.

Предполагая, что объект класса экспортирует интерфейс IClassFactory вместо IApeClass, клиенты должны использовать метод IClassFactory::CreateInstance для создания новых экземпляров:

HRESULT CreateAGorillaAndEatBanana()

{

IClassFactory *pcf = 0;

// find the class object находим объект класса

HRESULT hr = CoGetClassObject(CLSIDGorilla, CLSCTXALL, 0, IIDIClassFactory, (void **)&pcf);

if (SUCCEEDED(hr))

{

IApe *pApe = 0;

// use the class object to create a gorilla

// используем объект класса для создания gorilla

hr = pcf->CreateInstance(0, IIDIApe, (void**)&pApe);

// we're done with the class object, so release it

// мы закончили с объектом класса, поэтому освобождаем его

pcf->Release();

if (SUCCEEDED(hr))

{

// tell the new gorilla to eat a banana

// приказываем новой горилле есть банан

hr = pApe->EatBanana();

pApe->Release();

}

}

return hr;

}

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

Для того чтобы предыдущий пример работал корректно, объекту класса Gorilla следует реализовать

IClassFactory : class GorillaClass : public IClassFactory

{

public:

IMPLEMENTUNKNOWNNODELETE(GorillaClass)

BEGININTERFACETABLE(GorillaClass)

IMPLEMENTSINTERFACE(IClassFactory)

ENDINTERFACETABLE()

STDMETHODIMP CreateInstance(IUnknown *pUnkOuter, REFIID riid, void **ppv)

{

*ppv = 0;

if (pUnkOuter != 0)

// we don't support aggregation yet

// мы еще не поддерживаем агрегирование

return CLASSENOAGGREGATION;

// create a new instance of our C++ class Gorilla

// создаем новый экземпляр нашего С++-класса Gorilla

Gorilla *p = new Gorilla;

if (p == 0) return EOUTOFMEMORY:

// increment reference count by one

// увеличиваем счетчик ссылок на единицу

p->AddRef();

// store the resultant interface pointer into *ppv

// записываем результирующий указатель интерфейса в *ppv

HRESULT hr = p->QueryInterface(riid, ppv);

// decrement reference count by one, which will delete the

// object if QI fails

// уменьшаем на единицу счетчик ссылок,

// что уничтожит объект при отказе QI

p->Release();

// return result of Gorilla::QueryInterface

// возвращаем результат работы Gorilla::QueryInterface

return hr;

} 

STDMETHODIMP LockServer(BOOL bLock);

};

Реализация LockServer будет обсуждаться в этой главе позже. Отметим, что реализация CreateInstance, в первую очередь, создает новый объект C++ на базе класса Gorilla и запрашивает объект, поддерживает ли он нужный интерфейс. Если объект поддерживает требуемый интерфейс, то вызов QueryInterface инициирует вызов AddRef, и клиент в конечном счете выполнит соответствующий вызов Release. Если же произойдет отказ QueryInterface, то потребуется некоторый механизм для уничтожения созданного нового объекта. Предыдущий пример использует стандартную технологию «заключения в скобки» (bracketing) вызова QueryInterface между парой AddRef/Release. Если произошел сбой вызова QueryInterface, то вызов Release сбросит счетчик ссылок на нуль, запуская тем самым удаление объекта. Если же вызов QueryInterface прошел успешно, то вызов Release установит счетчик ссылок на единицу. Остающаяся ссылка принадлежит клиенту, который и выполнит последний вызов Release, когда объект более не нужен.

 

Оптимизации

Одно из преимуществ использования стандартного интерфейса для создания экземпляров (instantiation ) состоит в том, что СОМ может обеспечить более эффективную технологию реализации. Рассмотрим следующий код, который создает новый экземпляр класса Chimp:

HRESULT CreateChimp(/* [out] */ IApe * &rpApe)

{

extern const CLSID CLSID_Chimp;

rpApe = 0;

IClassFactory *pcf = 0;

HRESULT hr = CoGetClassObject(CLSID_Chimp, CLSCTX_ALL, 0, IID_IClassFactory, (void**)&pcf);

if (SUCCEEDED(hr))

{

hr = pcf->CreateInstance(0, IID_IApe, (void**)&rpApe);

pcf->Release();

}

return hr;

}

Этот код выполняет одну операцию: создание объекта Chimp. Заметим, что для выполнения одной операции понадобилось три вызова подопераций (suboperations) – CoGetClassObject, CreateInstance, Release. Если сервер загружен как внутрипроцессный, то эти три подоперации не обойдутся слишком дорого. Если, однако, сервер является внепроцессным или внехостовым, то каждая из этих подопераций потребует вызова между процессами клиента и сервера. Хотя СОМ использует очень эффективную передачу IPC/RPC (Interprocess Communication/Remote Procedure Call), каждая из этих подопераций потребует немалых исполнительных затрат. В идеале было бы лучше потребовать, чтобы СОМ перешел на серверный процесс один раз и, находясь там, использовал объект класса для вызова CreateInstance от имени клиента. Если объект класса используется только для реализации IClassFactory, то этот способ будет более эффективным, чем трехшаговый способ, показанный ранее. В СОМ имеется API-функция: CoCreateInstanceEx, относящаяся по своему назначению к той же категории, что CoGetClassObject и IClassFactory::CreateInstance – обеспечивающая создание новых объектов за одно обращение между процессами.

CoCreateInstanceEx дает клиенту возможность задать CLSID для определения, какой объект следует реализовать. В случае успешного выполнения СоСгеаteInstanceEx возвращает один или более указателей интерфейса, которые ссылаются на новый экземпляр заданного класса. При использовании CoCreateInstanceEx клиент никогда не видит промежуточный объект класса, который используется для создания экземпляра объекта. Чтобы клиенты могли вызывать CoCreateInstanceEx, никаких дополнительных функций серверу реализовывать не нужно. С точки зрения сервера все, что необходимо, – это объявить свои объекты классов, как требуется для CoGetClassObject. Реализация CoCreateInstanceEx для нахождения соответствующего объекта класса будет использовать ту же технологию, что и CoGetClassObject. Основное различие заключается в том, что после нахождения объекта CoCreateInstanceEx выполняет дополнительный вызов IClassFactory::CreateInstance, за которым могут последовать один или более вызовов QueryInterface, и все это во время выполнения процесса объекта класса. Можно получить значительную экономию на этапе выполнения, если запрос на активацию закрепить за определенным процессом.

Подобно CoGetClassObject, CoCreateInstanceEx позволяет клиенту задавать желаемые параметры CLSCTX и COSERVERINFO. Кроме того, CoCreateInstanceEx дает клиенту возможность запрашивать более одного указателя интерфейса на вновь создаваемый объект. Это делается путем предоставления клиенту возможности передавать массив структур MULTI_QI, который будет использован для вызова QueryInterface, новому экземпляру во время выполнения серверного процесса:

typedef struct tagMULTI_QI {

// which interface is desired?

// какой интерфейс требуется?

const IID *piid;

// null on input, will contain the pointer on output

// на входе нуль, на выходе будет содержать указатель

[iid_is(piid)] IUnknown *pItf;

// will contain the HRESULT from QueryInterface on output

// на выходе будет содержать HRESULT от QueryInterface

HRESULT hr;

}

MULTI_QI;

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

После постижения структуры MULTI_QI понять определение CoCreateInstanceEx уже нетрудно:

HRESULT CoCreateInstanceEx( [in] REFCLSID rclsid,

// what kind of object? – какого сорта объект?

[in] IUnknown *pUnkOuter,

// for aggregation – для агрегирования

[in] DWORD dwClsCtx,

// locality? – размещение?

[in] COSERVERINFO *pcsi,

// host/security info – информация о хосте/безопасности

[in] ULONG cmqi,

// how many interfaces? – сколько интерфейсов?

[out, size_is (cmqi)] MULTI_QI *prgmq

// where to put itfs – куда разместить интерфейсы );

Если все запрошенные интерфейсы доступны в новом объекте, то CoCreateInstanceEx возвращает S_OK. Если хотя бы один (но не все) из запрошенных интерфейсов недоступен, то CoCreateInstanceEx возвратит CO_S_NOTALLINTERFACES, индицируя частичный успех. Затем вызывающий объект должен исследовать индивидуальные HRESULT в каждой структуре MULTI_QI, чтобы определить, какие интерфейсы были доступны, а какие – нет. Если CoCreateInstanceEx не может создать объект или ни один из запрошенных интерфейсов не доступен, то CoCreateInstanceEx возвращает HRESULT с кодом серьезности ошибки SEVERITY_ERROR, который сообщит, почему произошел отказ в операции.

CoCreateInstanceEx чрезвычайно эффективен в случае, когда требуются интерфейсы нескольких типов. Рассмотрим дополнительное определение интерфейса:

[object,uuid(753A8F7C-A7FF-11d0-8C30-0080C73925BA)]

interface IEgghead : IUnknown

{

import «unknwn.idl»;

HRESULT ContemplateNavel(void);

}

Имея такое определение интерфейса, клиент может привязать оба типа указателей к новому шимпанзе за одно обращение:

void CreateChimpEatBananaAndThinkAboutIt(void)

{

// declare and initialize an array of MULTI_QI's

// объявляем и инициализируем массив MULTI_QI

MULTI_QI rgmqi[2] = { { &IID_IApe, 0, 0 }, { &IID_IEgghead, 0, 0 } };

HRESULT hr = CoCreateInstanceEx( CLSID_Chimp,

// make a new chimp – создаем нового шимпанзе

0,

// no aggregation – без агрегирования

CLSCTX_ALL,

// any locality – размещение любое

0,

// no explicit host/security info

// нет явной информации о хосте и безопасности

2,

// asking for two interfaces – запрашиваем 2 интерфейса

rgmqi);

// array of MULTI_QI structs – массив структур

MULTI_QI

if (SUCCEEDED(hr)) {

// hr may be CO_S_NOTALLINTERFACES, so check each result

// hresult может быть равен CO_S_NOTALLINTERFACES,

// поэтому проверяем каждый результат

if (hr == S_OK || SUCCEEDED(rgmqi[0].hr)) {

// it is safe to blindly cast the resultant ptr to the type

// that corresponds to the IID used to request the interface

// безопасно вслепую преобразовать результирующий

// указатель к типу, соответствующему тому IID,

// который использовался при запросе интерфейса

IАре *рАре = reinterpret_cast(rgmqi[0].pItf);

assert(pApe);

HRESULT hr2 = pApe->EatBanana();

assert(SUCCEEDED(hr2));

pApe->Release();

}

if(hr == S_OK || SUCCEEDED(rgmqi[1].hr)) {

IEgghead *peh = reinterpret_cast(rgmqi[1].pItf);

assert(peh);

HRESULT hr2 = peh->ContemplateNavel();

assert(SUCCEEDED(hr2));

peh->Release();

}

} }

Рисунок 3.3 показывает шаги, которые предпринимаются CoCreateInstanceEx для создания нового объекта. Важно отметить, что оба результирующих указателя будут указывать на один и тот же объект. Если нужны два различных объекта, то требуются и два отдельных вызова CoCreateInstanceEx.

Использование СоСrеateInstanceЕх достаточно просто, если нужен только один интерфейс:

HRESULT CreateChimpAndEatBanana(void)

{

// declare and Initialize a MULTI_QI

// определяем и инициализируем MULTI_QI

MULTI_QI mqi = { &IID_IApe, 0, 0 };

HRESULT hr = CoCreateInstanceEx( CLSID_Chimp,

// make a new chimp – создаем нового шимпанзе

0,

// по aggregation – без агрегирования CLSCTX_ALL,

// any locality – любое расположение

0,

// no explicit host/security Info

// нет явной информации о хосте/безопасности

1,

// asking for one interface – запрашиваем один интерфейс

&mqi);

// array of MULTI_QI structs – массив структур

MULTI_QI

if (SUCCEEDED(hr))

{

IApe *pApe = reinterpret_cast(mqi.pItf);

assert(pApe);

// use the new object – используем новый объект

hr = pApe->EatBanana();

// release the Interface pointer

// освобождаем указатель интерфейса

pApe->Release();

}

return hr;

}

Если нужен только один интерфейс и не передается COSERVERINFO, то СОМ предусматривает несколько более удобную версию CoCreateInstanceEx, именуемую CoCreateInstance:

HRESULT CoCreateInstance( [in] REFCLSID rclsid,

// what kind of object? – какой тип объекта?

[in] IUnknown *pUnkOuter,

// for aggregation – для агрегирования

[in] DWORD dwClsCtx,

// locality? – размещение?

[in] REFIID riid,

// what kind of interface – какой вид интерфейса

[out, iid_is(riid)] void **ppv);

// where to put itf – куда разместить интерфейс

Предыдущий пример становится намного проще, если применить CoCreateInstance

HRESULT CreateChimpAndEatBanana(void)

{

IАре *рАре = 0;

HRESULT hr = CoCreateInstance( CLSID_Chimp,

// make a new chimp – создаем нового шимпанзе

0,

// по aggregation – без агрегирования

CLSCTX_ALL,

// any locality – любое расположение

IID_IApe,

// what kind of itf – какой вид интерфейса

(void**)&pApe);

// where to put iff – куда поместить интерфейс

if (SUCCEEDED(hr)) {

assert(pApe);

// use the new object используем новый объект

hr = pApe->EatBanana();

// release the interface pointer

// освобождаем указатель интерфейса

pApe->Release();

}

return hr;

}

Оба предыдущих примера функционально эквивалентны. В сущности, реализация CoCreateInstance просто осуществляет внутренний вызов CoCreateInstanceEx:

// pseudo-code for implementation of CoCreateInstance API

// псевдокод для реализации API-функции

CoCreateInstance HRESULT

CoCreateInstance(REFCLSID rclsid, IUnknown *pUnkOuter, DWORD dwCtsCtx, REFIID riid, void **ppv)

{

MULTI_QI rgmqi[] = { &riid, 0, 0 };

HRESULT hr = CoCreateInstanceEx(rclsid, pUnkOuter, dwClsCtx, 0, 1, rgmqi);

*ppv = rgmqi[0].pItf;

return hr;

}

Хотя возможно выполнить запрос на удаленную активацию с использованием CoCreateInstance, отсутствие параметра COSERVERINFO не позволяет вызывающему объекту задать явное имя хоста. Вместо этого вызов CoCreateInstance и задание только флага CLSCTX_REMOTE_SERVER предписывает SCM использовать конфигурационную информацию каждого CLSID для выбора хост-машины, которая будет использоваться для активации объекта.

Рисунок 3.4 показывает, как параметры CoCreateInstanceEx преобразуются в параметры CoGetClassObject и IClassFactory::CreateInstance. Вопреки распространенному заблуждению, CoCreateInstanceEx не осуществляет внутренний вызов CoGetClassObject. Хотя между двумя этими методиками нет логических различий, реализация CoCreateInstanceEx будет более эффективной при создании одного экземпляра, так как в этом случае не будет лишних вызовов клиент-сервер, которые могли бы понадобиться, если бы была использована CoGetClassObject. Если, однако, будет создаваться большое число экземпляров, то клиент может кэшировать указатель объекта класса и просто вызвать IClassFactory::CreateInstance несколько раз. Поскольку IClassFactory::CreateInstance является всего лишь вызовом метода и не идет через SCM, он отчасти быстрее, чем вызов CoCreateInstanceEx. Порог, за которым становится более эффективным кэшировать объект класса и обходить CoCreateInstanceEx, будет изменяться в зависимости от эффективности IPC и RPC на используемых хост-машинах и сети.

 

Снова интерфейс и реализация

В предыдущих примерах активации со стороны клиента осуществлялись явные вызовы API-функций СОМ для активации. Часто может понадобиться много шагов для корректной связи с требуемым объектом (например, создать один тип объекта, затем запросить его для ссылки на другой объект, основанный на некоторой информации в запросе). Чтобы избавить клиентов от заботы об алгоритмах по поиску объектов или их созданию, СОМ поддерживает стандартный механизм назначения произвольных имен объектам, на которые они ссылаются. Этот механизм основан на использовании локаторных объектов (locator objects), которые инкапсулируют свой алгоритм связи, скрывая его за стандартным постоянным интерфейсом. Эти локаторы объектов формально называются моникерами и являются просто СОМ-объектами, экспортирующими интерфейс IMoniker. Интерфейс IMoniker является одним из наиболее сложных интерфейсов СОМ; тем не менее, он объявляет один метод, чрезвычайно важный для данной дискуссии, а именно BindToObject:

interface IMoniker : IPersistStream { HRESULT BindToObject([in] IBindCtx *pbc, [in, unique] IMoniker *pmkToLeft, [in] REFIID riid, [out, iid_is(riid)] void **ppv);

// remaining methods deleted for clarity

// остальные методы удалены для ясности

}

Напоминаем, что определения интерфейса являются абстрактными и достаточно неопределенными для того, чтобы допустить множество интерпретаций точной семантики каждого метода. Абстрактную семантику BindToObject можно сформулировать так: «запусти свой алгоритм поиска или создания объекта и возврати типизированный интерфейсный указатель на этот объект, когда он создан или найден». Когда клиент вызывает ВindToObject на моникер, у него нет точных представлений о том, как именно моникер превратит свою внутреннюю структуру в указатель на объект. Имея три различных моникера, можно использовать три совершенно различных алгоритма. Такая полиморфность поведения и делает идиому моникера столь действенной.

Клиенты получают моникеры одним из следующих способов. Клиент может получить моникер от какого-нибудь внешнего агента, такого, как результат вызова метода на некоем уже существующем объекте. Клиенты могут вызвать явную API-функцию, которая создает моникер определенного типа. Клиенты могут просто иметь строку текста, являющуюся «строкоподобным» состоянием моникера. Последний случай является наиболее интересным, так как он позволяет приложениям загружать и сохранять «имена объектов», используя внешние конфигурационные файлы или системный реестр, в текстовом виде (text-based). Если эта методика открыто документирована как часть конфигурационного состояния приложения, системные администраторы или опытные пользователи смогут переконфигурировать свое приложение, чтобы использовать альтернативную технологию для поиска объектов, которая могла быть или не быть предусмотрена разработчиком исходного приложения. Например, моникер, поддерживающий выравнивание нагрузки, может быть переконфигурирован для проведения иной стратегии выбора хост-машин простым изменением текстовой версии моникера, которая хранится в конфигурационном файле приложения.

Текстовое представление моникера формально называется отображаемым именем (display name). Интерфейс IMoniker объявляет метод GetDisplayName, который позволяет клиентам запрашивать моникер о его отображаемом имени. Более интересная задача – превратить произвольные отображаемые имена в моникеры. Эта задача довольно проблематичная, так как клиент не может просто сказать, какому виду моникера соответствует отображаемое имя. Такую работу выполняет MkParseDisplayName – вероятно, наиболее важная API-функция во всем СОМ.

MkParseDisplayName берет произвольное отображаемое имя и превращает его в моникер:

HRESULT MkParseDisplayName(

[in] IBindCtx *pbc,

// binding Info – информация о связывании

[in, string] const OLECHAR *pwszName,

// object name – имя объекта

[out] ULONG *pcchEaten,

// progress on error – сообщение об ошибке

[out] IMoniker **ppmk);

// the resultant moniker – результирующий моникер

Пространство имен моникеров является расширяемым, чтобы поддерживать новые типы моникеров. Синтаксический анализатор высокого уровня, использованный в MkParseDisplayName, исследует префикс отображаемого имени и пытается сопоставить его с зарегистрированным префиксом ProgID, который определяет, какому типу моникера соответствует данное отображаемое имя. Если префиксы совпадают, то создается новый моникер соответствующего типа и ему присваивается отображаемое имя для дальнейшего анализа. Поскольку моникеры имеют иерархическую структуру и могут быть композитными, то результирующий моникер в действительности может содержать два и более моникеров. Клиент может не заботиться об этой детали реализации. Клиент попросту использует для нахождения искомого объекта результирующий интерфейсный указатель IMoniker, который может указывать, а может не указывать на композитный моникер (composite moniker).

Напомним, что начальная точка входа в класс СОМ проходит через объект этого класса. Чтобы связаться с объектом класса, необходим моникер классового типа (Class Moniker). Это моникеры встроенного типа, предоставляемые моделью СОМ. Классовые моникеры поддерживают CLSID в качестве своего начального состояния и могут быть созданы либо с помощью явной API-функции СОМ CreateClassMoniker.

HRESULT CreateClassMoniker([in] REFCLSID rclsid, [out] IMoniker **ppmk);

либо путем передачи отображаемого имени от Class Moniker в MkParseDisplayName:

clsid:571F1680-CC83-11d0-8C48-0080C73925BA:

Отметим, что префикс «сlsid» является программным идентификатором ProgID для Class Moniker. Следующий код демонстрирует использование МkParseDisplayName для создания Class Moniker, который затем используется для связи с объектом класса Gorilla:

HRESULT GetGorillaClass(IApeClass * &rpgc)

{ rpgc = 0;

// declare the CLSID for Gorilla as a display name

// объявляем CLSID как отображаемое имя для Gorilla

const OLECHAR pwsz[] = OLESTR(«clsid:571F1680-CC83-11d0-8C48-0080C73925BA:»);

// create a new binding context for parsing

// and binding the moniker

// создаем новый связующий контекст

// для анализа и связывания моникера

IBindCtx *pbc = 0;

HRESULT hr = CreateBindCtx(0, &pbc);

if (SUCCEEDED(hr))

{

ULONG cchEaten; IMoniker *pmk = 0;

// ask СОМ to convert the display name to a moniker object

// запрашиваем СОМ преобразовать отображаемое имя

// в объект моникера

hr = MkParseDisplayName(pbc, pwsz, &cchEaten, &pmk);

if (SUCCEEDED(hr))

{

// ask the moniker to find or create the object that it

// refers to // запрашиваем моникер найти или создать объект,

// на который моникер ссылается

hr = pmk->BindToObject(pbc, 0, IID_IApeClass, (void**)&rpgc);

// we now have a pointer to the desired object, so release

// the moniker and the binding context

// теперь у нас есть указатель на желаемый объект, так что

// освобождаем моникер и связующий контекст

pmk->Release();

}

pbc->Release();

}

return hr;

}

Связующий контекст, который передается одновременно в MkParseDisplayName и IMoniker::BindToObject, является просто вспомогательным объектом, который позволяет дополнительным параметрам передаваться алгоритмам синтаксического анализа и связывания моникера. В случае нашего простого примера все, что требуется, – это новый связующий контекст в роли заполнителя (placeholder), который запрашивается путем вызова API-функции СОМ CreateBindCtx.

В Windows NT 4.0 введена API-функция, упрощающая вызовы MkParseDisplayName и IMoniker::BindToObject:

HRESULT CoGetObject( [in, string] const OLECHAR *pszName, [in, unique] BIND_OPTS *pBindOptions, [in] REFIID riid, [out, iid_is(riid)] void **ppv);

Эта API-функция реализована следующим образом:

// pseudo-code from OLE32.DLL

// псевдокод из OLE32.DLL

HRESULT CoGetObject(const OLECHAR *pszName, BIND_OPTS *p0pt, REFIID riid, void **ppv)

{

// prepare for failure

// подготовка на случай сбоя

*ppv = 0;

// create a bind context

// создаем контекст связывания

IBindCtx *pbc = 0;

HRESULT hr = CreateBindCtx(0, &pbc);

if (SUCCEEDED(hr))

{

// set bind options if provided

// устанавливаем опции связывания, если они требуются

if (pOpt) hr = pbc->SetBindOptions(pOpt);

if (SUCCEEDED(hr))

{

// convert the display name into a moniker

// преобразуем отображаемое имя в моникер

ULONG cch;

IMoniker *pmk = 0;

hr = MkParseDisplayName(pbc, pszName, &cch, &pmk);

if (SUCCEEDED(hr)) {

// ask the moniker to bind to the named object

// запрашиваем моникер связаться с именованным объектом

hr = pmk->BindToObject(pbc, 0, riid, ppv);

pmk->Release();

}

}

pbc->Release();

}

return hr;

}

При наличии этой функции создание новой гориллы сводится к простому нахождению объекта класса и вызову метода CreateInstance:

HRESULT CreateAGorillaAndEatBanana() {

IClassFactory *pcf = 0;

// declare the CLSID for Gorilla as a display name

// объявляем CLSID как отображаемое имя для Gorilla

const OLECHAR pwsz[] = OLESTR(«clsid:571F1680-CC83-11d0-8C48-0080C73925BA:»);

// find the class object via the gorilla's class moniker

// находим объект класса через gorilla's class moniker

HRESULT hr = CoGetObject(pwsz, 0, IID_IClassFactory, (void**)&pcf);

if (SUCCEEDED(hr))

{

IApe *pApe = 0;

// use the class object to create a gorilla

// используем объект класса для создания gorilla

hr = pcf->CreateInstance(0, IID_IApe, (void**)&pApe);

if (SUCCEEDED(hr)) {

// tell the new gorilla to eat a banana

// говорим новой горилле съесть банан

hr = pApe->EatBanana();

pApe->Release();

}

pcf->Release();

}

return hr;

}

Рисунок 3.5 иллюстрирует, какие объекты создаются или находятся посредством каждой операции.

Visual Basic предоставляет функциональные возможности API-функции CoGetObject через встроенную функцию GetObject. Следующий код на Visual Basic также создает новую gorilla и предписывает ей есть бананы:

Sub CreateGorillaAndEatBanana()

Dim gc as IApeClass

Dim ape as IApe

Dim sz as String sz = «clsid:571F1680-CC83-11d0-8C48-0080C73925BA:»

' get the class object for gorillas

' получаем объект класса для gorilla

Set gc = GetObject(sz)

' ask Gorilla class object to create a new gorilla

' запрашиваем объект класса Gorilla создать новую gorilla

Set ape = gc.CreateApe()

' ask gorilla to eat a banana

' просим gorilla есть бананы

ape.EatBanana

End Sub

Отметим, что версия этой функции на Visual Basic использует интерфейс IApeClass для обработки объекта. Это связано с тем, что Visual Basic не может использовать интерфейс IClassFactory из-за ограничений языка.

 

Моникеры и композиция

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

Следующее отображаемое имя показывает, как моникер элемента использован в тандеме с классовым моникером:

clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus

Отметим использование символа "!" для отделения отображаемого имени Class Moniker от имени элемента (item name) «Ursus». При анализе MkParseDisplayName сначала использует префикс "clsid " в качестве ProgID для контакта с реализацией Сlass Moniker. Затем MkParseDisplayName предложит реализации Class Moniker проанализировать часть строки – столько, сколько она сможет распознать. Это означает, что после того, как Сlass Moniker извлек свой GUID из строки, ее следующий фрагмент все еще нуждается в анализе: !Ursus

Поскольку это имя имеет смысл только в области действия объекта, именованного моникером слева от него, фактически MkParseDisplayName присваивает значение крайнему левому моникеру (моникеру классового типа) и запрашивает объект, который он именует (объект класса Gorilla) проанализировать оставшуюся часть строки. Для поддержки анализа отображаемых имен СОМ определяет стандартный интерфейс IParseDisplayName:

[ object,uuid(0000011a-0000-0000-C000-000000000046) ]

interface IParseDisplayName : IUnknown

{

// convert display name to a moniker

// преобразуем отображаемое имя в моникер

HRESULT ParseDisplayName( [in, unique] IBindCtx *pbc, [in] LPOLESTR pszDisplayName, [out] ULONG *pchEaten, [out] IMoniker **ppmkOut );

}

В случае отображаемого имени, использованного в этом примере, объекту класса Gorilla потребуется реализовать IParseDisplayName и преобразовать строку "!Ursus" в моникер, который MkParseDisplayName поставит справа от моникера классового типа. Поскольку требуется стандартный моникер элемента, то достаточно будет такой реализации:

STDMETHODIMP GorillaClass::ParseDisplayName(IBindCtx *pbc, LPOLESTR pszDisplayName, ULONG *pchEaten, IMoniker **ppmkOut)

{

// create an item moniker using explicit API function

// создаем отдельный моникер, используя явную API-функцию

HRESULT hr = CreateItemMoniker(OLESTR("!"), pszDisplayName + 1, ppmkOut);

// indicate how many characters were parsed

// показываем, сколько символов было проанализировано

if (SUCCEEDED(hr)) *pchEaten = wcslen(pszDisplayName);

else *pchEaten = 0; return hr;

}

Отметим, что в данном примере не делается попытки проверить правильность анализируемого имени. Здесь просто убирается начальный символ "!", и из оставшейся части отображаемого имени создается новый моникер элемента.

Так как было проанализировано два моникера, то MkParseDisplayName будет собирать эти моникеры вместе, используя групповой композитный моникер (generic composite moniker). Групповой композитный моникер просто удерживает два моникера вместе. Реализация группового композитного моникера BindToObject сначала связывает моникер справа, передавая ему указатель на моникер слева через параметр pmkToLeft. Это иллюстрируется следующим псевдокодом:

// pseudo-code from OLE32.0LL

// псевдокод из OLE32.DLL

STDMETHODIMP GenericComposite::BindToObject (IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv)

{

return m_pmkRight->BindToObject(pbc, m_pmkLeft, riid, ppv);

}

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

Ранее мы установили, что моникер элемента использует интерфейс IOleItemContainer для связывания интерфейсного указателя. Ниже приведен псевдокод для реализации моникера элемента ВindToObject:

// pseudo-code from OLE32.DLL

// псевдокод из OLE32.DLL

STDMETHODIMP ItemMoniker::BindToObject(

IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv)

{

// assume failure

// допускаем возможность сбоя

*ppv = 0;

if (pmkToLeft == 0)

//requires a scope – требуется область действия return

E_INVALIDARG;

// first bind moniker to left

// сначала привязываем моникер слева

IOleItemContainer *poic = 0;

HRESULT hr = pmkToLeft->BindToObject(pbc, 0, IID_IOleItemContainer, (void**)&poic);

if (SUCCEEDED(hr))

{

// cache the bound object in binding context

// кэшируем связанный объект в контексте связывания

pbc->RegisterObjectBound(poic);

// get bind speed from Bind Context

// получаем быстроту связывания из контекста связывания

DWORD dwBindSpeed = this->MyGetSpeedFromCtx(pbc);

// ask object for named sub-object

// запрашиваем объект об именованном подобъекте

hr = poic->GetObject(m_pszItem, dwBindSpeed, pbc, riid, ppv);

poic->Release();

}

}

Эта реализация означает, что такой код:

HRESULT GetUrsus(IApe *&rpApe)

{

const OLECHAR pwsz[] = OLESTR(«clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus»);

return CoGetObject(pwsz, 0, IID_IApe, (void**)&rpApe);

}

эквивалентен следующему:

HRESULT GetUrsus(IApe *&rpApe) {

IOleItemContainer *poic = 0;

HRESULT hr = CoGetClassObject(CLSID_Gorilla, CLSCTX_ALL,

0, IID_IOleItemContainer, (void**)&poic);

if (SUCCEEDED(hr)) {

hr = poic->GetObject(OLESTR(«Ursus»), BINDSPEED_INFINITE,

0, IID_IApe, (void**)&rpApe);

poic->Release();

}

return hr; }

Отметим, что уровень изоляции (indirection), обеспеченный использованием CoGetObject, позволяет клиенту менять стратегию связывания просто путем чтения различных отображаемых имен из файла конфигурации или из ключа реестра.

 

Моникеры и сохраняемость

Обсуждение моникеров не может быть полным без обсуждения файлового моникера (File Moniker). Напомним, что СОМ предусматривает три примитива активации: привязывание к объектам класса, привязывание к новым экземплярам класса и привязывание к постоянным объектам, хранящимся в файлах. В данной главе детально анализировались первые два из этих примитивов. Третий примитив основан на API-функции СОМ CoGetInstanceFromFile:

HRESULT CoGetInstanceFromFile( [in, unique] COSERVERINFO *pcsi,

// host/security info – информация о хосте/безопасности

[in, unique] CLSID *pClsid,

// explicit CLSID (opt) – явный CLSID (opt)

[in, unique] IUnknown *punk0uter,

// for aggregation – для агрегирования

[in] DWORD dwClsCtx,

// locality? – локализация?

[in] DWORD grfMode,

// file open mode – режим открытия файла

[in] OLECHAR *pwszName,

// file name of object – файловое имя объекта

[in] DWORD cmqi,

// how many interfaces? – сколько интерфейсов?

[out, size_is(cmqi)] MULTI_QI *prgmq

// where to put itfs – куда поместить интерфейсы

);

Эта функция принимает на вход имя файла, которое относится к постоянному состоянию (persistent state) объекта. CoGetInstanceFromFile удостоверяется в том, что объект исполняется, после чего возвращает один или несколько интерфейсных указателей на (ре)активированный объект. Чтобы выполнить эту работу, CoGetInstanceFromFile в первую очередь требуется определить CLSID данного объекта. CLSID требуется по двум причинам. Если объект не исполняется, то CLSID необходим СОМ для создания нового экземпляра, который будет инициализирован от постоянного (находящегося в файле) образа. Во-вторых, если вызывающий объект не указывает определенное хост-имя до запроса на активацию, то СОМ будет использовать CLSID для выяснения того, на какой машине следует активировать объект.

Если CLSID не передается явно вызывающим объектом, то CoGetInstanceFromFile извлекает CLSID из самого файла с помощью вызова API-функции СОМ GetClassFile:

HRESULT GetClassFile([in, string) OLECHAR *pwszFileName, [out] CLSID *pclsid);

Для определения типа объекта, содержащегося в файле, GetClassFile использует информацию из заголовка файла, а также информацию из реестра.

После того как определены класс и хост-машина, СОМ исследует ROT (Running Object Table – таблица исполняющихся объектов) на целевой хост-машине для того, чтобы выяснить, является ли объект уже активированным. Таблица ROT является инструментом SCM, который преобразует произвольные моникеры в экземпляры объектов, исполняющихся на локальной хост-машине. Ожидается, что постоянные объекты будут регистрировать себя в локальной ROT во время загрузки. Чтобы представить файловое имя постоянного объекта в качестве моникера, СОМ предусматривает стандартный тип моникера – файловый моникер, который оборачивает имя файла в интерфейс IMoniker. Файловые моникеры могут создаваться либо путем передачи файлового имени в МkParseDisplayName , либо вызовом явной API-функции CreateFileMoniker:

HRESULT CreateFileMoniker( [in, string] const OLECHAR *pszFileName, [out] IMoniker **ppmk);

Если постоянный объект уже зарегистрировал в ROT свой файловый моникер, то CoGetInstanceFromFile просто возвращает указатель на уже работающий объект. Если же объект в ROT не найден, то СОМ создает новый экземпляр файлового класса и инициализирует его из постоянного объекта с помощью метода IPersistFile::Load этого экземпляра:

[object, uuid(0000010b-0000-0000-C000-000000000046)]

interface IPersistFile : IPersist

{

// called by CoGetInstanceFromFile to initialize object

// вызывается функцией CoGetInstanceFromFile для

// инициализации объекта

HRESULT Load(

[in, string] const OLECHAR * pszFileName, [in] DWORD grfMode

);

// remaining methods deleted for clarity // остальные методы удалены для ясности

}

Реализация объекта отвечает за загрузку из файла всех постоянных элементов и за саморегистрацию в локальной таблице ROT – с целью убедиться, что для каждого файла в каждый момент может исполняться только один экземпляр:

STDMETHODIMP::Load(const OLECHAR *pszFileName, DWORD grfMode)

{

// read in persisted object state

// считываем сохраненное состояние объекта

HRESULT hr = this->MyReadStateFromFile(pszFile, grfMode);

if (FAILED(hr)) return hr;

// get pointer to ROT from SCM

// берем указатель на ROT от SCM

IRunningObjectTable *prot = 0;

hr = GetRunningObjectTable(0, &prot);

if (SUCCEEDED(hr))

{

// create a file moniker to register in ROT

// создаем файловый моникер для регистрации в ROT

IMoniker *pmk = 0;

hr = CreateFileMoniker(pszFileName, &pmk);

if (SUCCEEDED(hr))

{

// register self in ROT

// саморегистрация в ROT

hr = prot->Register(0, this, pmk, &m_dwReg);

pmk->Release();

}

prot->Release();

}

return hr;

}

Метод IPersistFile::Load нового созданного экземпляра будет вызван диспетчером SCM во время выполнения CoGetInstanceFromFile . В приведенном выше примере для получения указателя на интерфейс IRunningObjectTable в SCM используется API-функция СОМ GetRunningObjectTable. Этот интерфейс затем используется для регистрации своего моникера в ROT, так что последующие вызовы CoGetInstanceFromFile , использующие то же файловое имя, не будут создавать новые объекты, а вместо этого возвратят ссылки на этот объект.

Существование File Moniker обусловлено двумя причинами. Во-первых, он нужен, чтобы позволить объектам самим регистрироваться в ROT, чтобы их мог найти CoGetInstanceFromFile. Во-вторых, чтобы скрыть от клиента использование CoGetInstanceFromFile за интерфейсом IMoniker. Реализация File Moniker из BindToObject просто вызывает CoGetInstanceFromFile:

// pseudo-code from OLE32.DLL // псевдокод из OLE32.DLL

STDMETHODIMP FileMoniker::BindToObject(IBindCtx *pbc,

IMoniker *pmkToLeft,

REFIID riid, void **ppv) {

// assume failure – на случай сбоя

*ppv = О;

HRESULT hr = E_FAIL;

if (pmkToLeft == 0) {

// no moniker to left – слева моникеров нет

MULTI_QI mqi = { &riid, 0, 0 };

COSERVERINFO *pcsi;

DWORD grfMode;

DWORD dwClsCtx;

// these three parameters are attributes of the BindCtx

// эти три параметра являются атрибутами BindCtx

this->MyGetFromBindCtx(pbc, &pcsi, &grfMode, &dwClsCtx);

hr = CoGetInstanceFromFile(pcsi, 0, 0, dwClsCtx,

grfMode, this->m_pszFileName,

1, &mqi);

if (SUCCEEDED(hr))

*ppv = mqi.pItf;

} else {

// there's a moniker to the left – слева есть моникер

// ask object to left for IClassActivator

// or IClassFactory

// запрашиваем объект слева от IClassActivator или от

// IClassFactory

}

return hr; }

При таком поведении File Moniker следующая функция, вызывающая CoGetInstanceFromFile

HRESULT GetCornelius(IApe * &rpApe)

{

OLECHAR *pwszObject = OLESTR(\\\\server\\public\\cornelius.chmp);

MULTI_QI mqi = { &IID_IApe, 0, 0 };

HRESULT hr = CoGetInstanceFromFile(0, 0, 0, CLSCTX_SERVER, STCM_READWRITE, pwszObject, 1, &mqi);

if (SUCCEEDED(hr)) rpApe = mqi.pItf;

else rpApe = 0;

return hr;

}

может быть упрощена, если вместо этого использовать вызов CoGetObject:

HRESULT GetCornelius(IApe * &rpApe)

{

OLECHAR *pwszObject = OLESTR(\\\\server\\public\\cornelius.chmp);

return CoGetObject(pwszObject, 0, IID_IApe, (void**)&rpApe);

}

Как и в предыдущем случае, когда использовался Class Moniker, уровень изоляции, обеспеченный CoGetObject, позволяет клиенту задавать сколь угодно сложную стратегию активации, не меняя ни единой строки кода.

 

Время жизни сервера

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

void CoFreeUnusedLibraries(void);

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

Функция DllCanUnloadNow, которую экспортирует DLL каждого сервера, должна соответствовать следующей сигнатуре:

HRESULT DllCanUnloadNow(void);

Если DLL желает быть освобожденной, то она возвращает S_OK. Если DLL хочет остаться загруженной, то она возвращает S_FALSE. Серверные DLL должны оставаться загруженными по крайней мере до тех пор, пока сохраняются интерфейсные указатели на ее объекты. Это означает, что в DLL должен быть счетчик всех существующих ссылок на объекты. Чтобы упростить реализацию этого, большинство DLL содержат одну переменную для счетчика блокировок (lock count) и используют две функции для автоматического инкрементирования и декрементирования этого счетчика:

LONG g_cLocks = 0; void LockModule(void)

{ InterlockedIncrement(&g_cLocks); }

void UnlockModule(void)

{ InterlockedDecrement(&g_cLocks); }

При наличии этих подпрограмм реализация DllCanUnloadNow становится чрезвычайно простой:

STDAPI DllCanUnloadNow(void)

{ return g_cLocks == 0 ? S_OK : S_FALSE; }

Oстается только вызывать в подходящее время подпрограммы LockModule и UnlockModule.

Существуют две основные причины, которые должны оставлять DLL сервера загруженной: внешние ссылки на экземпляры объектов и объекты класса, а также невыполненные вызовы IClassFactory::LockServer. Вполне очевидно, как добавить поддержку DllCanUnloadNow в экземпляры и объекты классов. Объекты, расположенные в динамически распределяемой области памяти (такие, как экземпляры классов) просто инкрементируют счетчик блокировок сервера при первом вызове AddRef:

STDMETHODIMP_(ULONG) Chimp::AddRef(void)

{ if (m_cRef == 0) LockModule(); return InterlockedIncrement(&m_cRef); }

и декрементируют счетчик блокировок при заключительном вызове Release:

STDMETHODIMP_(ULONG) Chimp::Release (void)

{ LONG res = InterlockedDecrement(&m_cRef); if (res == 0)

{ delete this; UnlockModule(); }

return res; }

Поскольку объекты, не размещенные в динамически распределяемой области памяти (такие, как объекты классов), не содержат счетчика ссылок, при каждом вызове AddRef и Release нужно инкрементировать или декрементировать счетчик блокировок:

STDMETHODIMP_(ULONG) ChimpClass::AddRef(void) {

LockModule();

return 2;

}

STDMETHODIMP_(ULONG) ChimpClass::Release (void) {

UnlockModule();

return 1;

}

Объекты классов, которые реализуют IClassFactory, должны устанавливать свои серверные счетчики блокировок на вызовы IClassFactory::LockServer:

STDMETHODIMP ChimpClass::LockServer(BOOL bLock)

{

if (bLock) LockModule();

else UnlockModule();

return S_OK;

}

Как будет обсуждаться в главе 6, IClassFactory::LockServer создана в первую очередь для внепроцессных серверов, но она достаточно проста и для использования во внутрипроцессных серверах.

Следует заметить, что в протоколе CoFreeUnusedLibraries/DllCanUnloadNow неотъемлемо присутствует состояние гонки (race condition). Возможно, что один поток задач будет выполнять заключительное освобождение последнего экземпляра, экспортированного из DLL, в то время как второй поток будет выполнять подпрограмму CoFreeUnusedLibraries. В СОМ приняты все меры предосторожности, чтобы избежать этой ситуации. В частности, в реализацию СОМ под Windows NT 4.0 Service Pack 2 добавлена специальная возможность для борьбы с состоянием гонки. Версия Service Pack 2 библиотеки СОМ определяет, чтобы к DLL обращались из нескольких потоков, и вместо того, чтобы незамедлительно выгружать DLL изнутри CoFreeUnusedLibraries, СОМ ставит DLL в очередь DLL, подлежащих освобождению. Затем СОМ будет ждать неопределенное время, пока не разрешит этим неиспользуемым серверным DLL освободиться посредством последующего вызова CoFreeUnusedLibraries, подтверждающего, что никаких остаточных вызовов Release уже не исполняется. Это означает, что в многопоточных средах выгрузка DLL из своего клиента может осуществляться значительно дольше, чем можно ожидать.

 

Классы и IDL

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

[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)]

coclass Gorilla { interface IApe; interface IWarrior; }

IDL -определения коклассов (coclass) всегда появляются в контексте определения библиотеки (library definition). В IDL определения библиотек используются для группирования набора типов данных (например, интерфейсы, коклассы, определения типов) в логический блок или пространство имен. Все типы данных, появляющиеся в контексте определения библиотеки IDL, будут отмечены в результирующей библиотеке типов. Библиотеки типов используются вместо IDL-файлов такими средами, как Visual Basic и Java.

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

// apes.idl // bring in IDL definitions of ape interfaces

// введем IDL-определения интерфейсов обезьян

import «apeitfs.idl»;

[ uuid(753A8A80-A7FF-11d0-8C30-0080C73925BA),

// LIBID – идентификатор библиотеки version(1.0),

// version number of library – номер версии библиотеки

lcid(9),

// locale ID of library (english)

// код локализации библиотеки (english)

helpstring(«Library of the Apes»)

// title of library – заголовок библиотеки

]

library ApeLib { importlib(«stdole32.tlb»);

// bring in std defs. – вносим стандартные опредепения

[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)] coclass Gorilla {

[default] interface IApe;

interface IWarrior; }

[uuid(753A8A7E-A7FF-11d0-8C30-0080C73925BA)] coclass Chimpanzee {

[default] interface IApe;

interface IEgghead; }

[uuid(753A8A7F-A7FF-11d0-8C30-O080C73925BA)] coclass Orangutan {

[default] interface IApe;

interface IKeeperOfTheFaith; } }

Атрибут [default] показывает, какой из интерфейсов наиболее близко представляет внутренний тип класса. В тех языках, которые распознают этот атрибут, [default] позволяет программисту объявлять ссылки объекта, используя только имя кокласса СОМ:

Dim ursus as Gorilla

Исходя из IDL-определения для Gorilla, данный оператор эквивалентен следующему:

Dim ursus as IApe

поскольку IApe является интерфейсом по умолчанию для класса Gorilla. В любом случае программист мог вызывать методы EatBanana и SwingFromTree с переменной ursus. Если атрибут [default] не указан, то он неявно добавляется к первому интерфейсу в определении coclass.

Имея указанное выше библиотечное определение IDL, результирующий заголовочный файл apes.h будет использовать препроцессор С для включения файла apesitfs.h. Этот файл apesitfs.h будет содержать определения абстрактных базовых классов для четырех интерфейсов СОМ IApe, IWarrior, IKeeperOfTheFaith и IEgghead. Кроме того, файл apes.h будет содержать объявления GUID для каждого класса:

extern "С" const CLSID CLSID_Gorilla;

extern "С" const CLSID CLSID_Chimpanzee;

extern "С" const CLSID CLSID_Orangutan;

Соответствующий файл apes_i.с будет содержать определения этих CLSID. Сгенерированная библиотека типов apes.tlb будет содержать описания каждого из интерфейсов и классов, что позволит программисту на Visual Basic написать следующее:

Dim ape As IApe

Dim warrior as IWarrior

Set ape = New Gorilla

' ask СОМ for a new gorilla

' запрашиваем СОМ о новой

gorilla Set warrior = ape

А вот так выглядит Java-версия того же самого кода:

IАре аре;

IWarrior warrior;

аре = new Gorilla();

// no cast needed for [default]

// никаких приведений не требуется для [default] ???

warrior = (IWarrior)ape;

Оба этих фрагмента кода предписывают виртуальной машине использовать CLSID_Gorilla для сообщения CoCreateInstanceEx о том, какой тип объекта нужно создать.

В предыдущем IDL на каждый из интерфейсов IApe, IWarrior, IEgghead и IKeeperOfTheFaith есть ссылки из определения библиотеки. По этой причине их определения присутствуют в генерируемой библиотеке типов, несмотря та то, что они определены вне области действия определения библиотеки. В действительности любые типы данных, используемые как параметры или как базовые интерфейсы для данных интерфейсов, будут в то же время присутствовать в генерируемой библиотеке. Существует хорошая практика – определять оператор с реализацией библиотеки в отдельном IDL-файле, который импортирует все необходимые определения интерфейсов из внешнего IDL-файла, содержащего только описания интерфейсов. Такая практика является обязательной в больших проектах со многими IDL-файлами, так как для IDL-файла, содержащего определение библиотеки, недопустимо импортировать другой IDL-файл, который также содержит определение библиотеки. Путем разделения определений библиотеки по отдельным IDL-файлам можно корректно импортировать интерфейсы, используемые библиотекой, в другие проекты, не беспокоясь о множественных определениях библиотеки. Если не использовать этот способ, то существует только одна возможность импортировать определение интерфейса из IDL-файла, содержащего определение библиотеки, – использовать директиву importlib:

// humans.idl

// apeitfs.idl DOESN'T have a library statement, so import

// apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем

import «apeitfs.idl»;

[ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring(«Humans that need apes»)

// «Люди, нуждающиеся в обезьянах»

]

library HumanLib {

importlib(«stdole32.tlb»);

// bring in std defs. – вносим стандартные определения

// Dogs.idl DOES have a library definition, so importlib

// its corresponding type library

// Dogs.idl ИМЕЕТ определение библиотеки, поэтому

// импортируем библиотеку соответствующего типа

importlib(«dogs.tlb»);

[uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)]

coclass DogApe {

interface IDog;

interface IApe;

} }

В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.

 

Эмуляция классов

Часто случается, что разработчики классов желают развернуть новые версии уже существующих классов, чтобы исправить дефекты или расширить функциональные возможности. Полезно придать этим новым реализациям новые идентификаторы класса CLSID , чтобы клиенты могли четко различать, какая версия им нужна. В качестве примера посмотрим, что происходит, когда развертывается новая версия класса. Если для идентификации нового класса используется новый CLSID, (например, CLSID_Chimp2), то клиентам, определенно желающим использовать новую версию, следует использовать новый CLSID во время активации: // new client – новый клиент

IАре *рАре = 0; hr = CoCreateInstance(CLSID_Chimp2, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);

Использование второго CLSID гарантирует, что клиенты не получат случайно старую версию класса Chimp . В то же время старые клиенты делают запросы на активацию с применением старого CLSID:

// old client – старый клиент

IАре *рАре = 0;

hr = CoCreateInstance(CLSID_Chimp, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);

Чтобы продолжать поддержку старых клиентов, разработчику Chimp необходимо сохранить в реестре исходный CLSID для удовлетворения этих запросов на активацию. Если изменилась семантика класса, то необходимо, чтобы исходный сервер также оставался доступным для этих клиентов. Однако бывает, что семантика просто расширяется. В этом случае предпочтительнее просто переадресовать запросы на активацию от старых клиентов на создание экземпляров нового класса.

Чтобы дать возможность разработчику новой версии класса прозрачно удовлетворять запросы на активацию для других CLSID , в СОМ введено понятие эмуляции классов (class emulation). Эмуляция классов позволяет разработчику компонента указать, что старый CLSID заменен новым, альтернативным CLSID, эмулирующим семантику исходного класса. Это позволяет прежним клиентам, делающим запросы на активацию с использованием прежнего CLSID, получать экземпляры нового усовершенствованного класса. Для индикации того, что у класса имеется новая альтернативная версия, в СОМ существует такая API-функция:

HRESULT CoTreatAsClass([in] REFCLSID rclsidOld, [in] REFCLSID rclsidNew);

Пусть Сhimp2 является новой версией класса Chimp, тогда следующий код проинформирует СОМ, что необходимо переадресовать запросы на активацию Chimp на запросы на активацию Chimp2:

// cause Chimp activation calls to activate Chimp2

// заставим запросы на активацию Chimp активизировать Chimp2

HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_Chimp2);

Эта API-функция добавляет следующий ключ реестра (registry key)

[HKCR\CLSID\{CLSID_Chimp}\TreatAs] @={CLSID_Chimp2}

Вызов CoTreatAsClass c CLSID_NULL в качестве второго параметра удаляет настройку TreatAs:

// cause Chimp activation calls to activate Chimps

// заставим запросы на активацию Chimp

// активизировать Chimps

HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_NULL);

Этот запрос восстанавливает исходную реализацию класса в состояние, предшествующее эмуляции. Клиенты могут запросить установку эмуляции данного класса, используя API-функцию CoGetTreatAsClass:

HRESULT CoGetTreatAsClass ([in] REFCLSID rclsidOld, [out] REFCLSID *pclsidNew);

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

 

Категории компонентов

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

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

Категория компонентов есть группа логически родственных СОМ-классов, которые разделяют общий ID категории, или CATID. Идентификаторы категории CATID – это GUID, записанные в реестре как атрибуты класса. Каждый класс может иметь два подключа: Implemented Categories и Required Categories (реализованные категории и нужные категории). Представим, что есть две категории компонентов: Simians и Mammals (приматы и млекопитающие). Каждая из этих двух категорий будет иметь уникальный CATID (CATID_Simians и CATID_Mammals соответственно). Допустим, что класс Chimp является членом каждой из этих категорий, и тогда для Chimp ключ реестра Implemented Categories будет содержать в себе каждый GUID как отдельный подключ:

[HKCR\CLSID\{CLSID_Chimp}\Implemented Categories\{CATID_Mammals}]

[HKCR\CLSID\{CLSID_Chimp}\Implemented Categories\{CATID_Simians}]

Эти элементы реестра обычно добавляются во время саморегистрации. Каждая известная категория компонентов в системе имеет запись в разделе реестра HKEY_CLASSES_ROOT\Component Categories

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

[HKCR\Component Categories\{CATID_Mammals}] 409="Bears live young"

[HKCR\Component Categones\{CATID_Simians}] 409="Eats Bananas"

Отметим, что в этом примере используется величина 409, являющаяся кодом локализации, или локальным идентификатором языка LCID (locale identifier), для U.S.English. Другая местная специфика может поддерживаться путем добавления дополнительных именованных величин.

Классы также могут указать, что они требуют от клиента функциональное назначение определенного типа. Обычно такая поддержка принимает вид узловых интерфейсов (site interfaces), которые клиент предоставляет активированному объекту. Для того, чтобы разделить эти предоставляемые клиентом сервисы на категории, не зависящие от отдельного интерфейса, СОМ позволяет классам объявлять второй тип категорий ID; он может использоваться клиентами для гарантии того, что они не активировали компонент, который не могут должным образом принять. Рассмотрим следующие две категории сервисов, предоставляемых клиентом: CATID_HasOxygen и CATID_HasWater. Поскольку для выживания шимпанзе необходимы кислород и вода, разработчик Chimp должен объявить, что эти две категории сервисов, предоставляемых клиентом, необходимы для активации. Это делается с помощью подключей из Required Categories:

[HKCR\CLSID\{CLSID_Chimp}\Required Categories\{CATID_HasOxygen}]

[HKCR\CLSID\{CLSID_Chimp}\Required Categories\{CATID_HasWater}]

Кроме того, ID этих двух категорий следует внести в реестр под ключом HKEY_CLASSES_ROOT\Component Categories

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

Элементы категорий компонентов могут быть зарегистрированы либо с помощью явных функций реестра, либо с использованием предлагаемого СОМ менеджера категорий компонентов (component category manager). Этот менеджер категорий компонентов объявляется в СОМ как создаваемый СОМ-класс (CLSID_StdComponentCategoriesMgr), который реализует интерфейс ICatRegister для регистрации информации о категории и интерфейс ICatInformation для запроса информации о категории. Интерфейс ICatRegister позволяет библиотекам DLL сервера легко добавлять в реестр необходимые элементы:

[object, uuid(0002E012-0000-0000-C000-000000000046)]

interface ICatRegister : IUnknown {

// description info for a category

// описательная информация для категории

typedef struct tagCATEGORYINFO

{ CATID catid; LCID lcid; OLECHAR szDescription[128]; }

CATEGORYINFO;

// register cCts category descriptions

// регистрируем описания категории cCts

HRESULT RegisterCategories([in] ULONG cCts,

[in, size_is(cCts)] CATEGORYINFO rgCatInfo[]);

// unregister cCategories category descriptions

// отменяем регистрацию описаний категории

cCategories HRESULT UnRegisterCategories([in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]);

// indicate a class implements one or more categories

// показываем, что класс реализует одну или более категорий

HRESULT RegisterClassImplCategories([in] REFCLSID rclsid,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]);

// deindicate a class implements one or more categories

// перестаем показывать, реализует класс одну или более категорий

HRESULT UnRegisterClassImplCategories([in] REFCLSID rclsd,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]);

// indicate a class requires one or more categories

// показываем, что класс требует одну или более категорий

HRESULT RegisterClassReqCategories([in] REFCLSID rclsid,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]):

// deindicate a class requires one or more categories

// перестаем показывать, требует ли класс одну или более категорий

HRESULT UnRegisterClassReqCategones([in] REFCLSID rclsid,

[in] ULONG cCategories,

[in, size_is(cCategories)] CATID rgcatid[]); }

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

В случае примера с Chimp следующий код зарегистрирует правильную информацию о каждой категории:

// get the standard category manager

// получим стандартный менеджер категорий

ICatRegister *pcr = 0; HRESULT hr = CoCreateInstance(

CLSID_StdComponentCategoriesMgr, 0,

CLSCTX_ALL, IID_ICatRegister, (void**)&pcr); if (SUCCEEDED(hr)) {

// build descriptions of each category

// формируем описания каждой категории

CATECORYINFO rgcc[4];

rgcc[0].catid = CATID_Simian;

rgcc[1].catid = CATID_Mammal;

rgcc[2].catid = CATID_HasOxygen;

rgcc[3].catid = CATID_HasWater;

rgcc[0].lcid = rgcc[1].lcid = rgcc[2].lcid = rgcc[3].lcid = 0х409;

wcscpy(rgcc[0].szDescription, OLESTR(«Eats Bananas»));

wcscpy(rgcc[1].szDescription, OLESTR(«Bears live young»));

wcscpy(rgcc[2].szDescription, OLESTR(«Provides Oxygen»));

wcscpy(rgcc[3].szDescription, OLESTR(«Provides Water»));

// register information regarding categories

// регистрируем информацию о категориях

pcr->RegisterCategories(4, rgcc);

// note that Chimps are Simians and mammals

// отметим, что Chimps (шимпанзе) являются Simian

// (обезьянами) и Mammal (млекопитающими)

CATID rgcid[2];

rgcid[0] = CATID_Simian;

rgcid[1] = CATID_Mammal;

pcr->RegisterClassImplCategories(CLSID_Chimp, 2, rgcid);

// note that Chimps require Oxygen and Water

// отметим, что Chimps (шимпанзе) нуждаются

// в кислороде (Oxygen) и воде (Water)

rgcid[0] = CATID_HasOxygen;

rgcid[1] = CATID_HasWater;

pcr->RegisterClassReqCategories(CLSID_Chimp, 2, rgcid);

pcr->Release(); }

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

Кроме того, стандартный менеджер категорий позволяет приложениям запрашивать реестр найти информацию о категориях. Эта функциональная возможность предоставляется через интерфейс ICatInformation:

[object, uuid(0002E013-0000-0000-C000-000000000046)]

interface ICatInformation : IUnknown

{

// get list of known categories

// получаем список известных категорий

HRESULT EnumCategories([in] LCID lcid, [out] IEnumCATEGORYINFO** ppeci);

// get description of a particular category

// получаем описание определенной категории

HRESULT GetCategoryDesc([in] REFCATID rcatid, [in] LCID lcid, [out] OLECHAR ** ppszDesc);

// get list of classes compatible with specified categories

// получаем список классов, совместимых с указанными категориями

HRESULT EnumClassesOfCategories(

[in] ULONG cImplemented,

// -1 indicates ignore

// (-1) означает игнорировать

[in,size_is(cImplemented)] CATID rgcatidImpl[], [in] ULONG cRequired,

// -1 indicates ignore

// (-1) означает игнорировать

[in,size_is(cRequired)] CATID rgcatidReq[], [out] IEnumCLSID** ppenumClsid);

// verify class is compatible with specified categories

// проверяем, совместим ли класс с указанными категориями

HRESULT IsClassOfCategories([in] REFCLSID rclsid,

[in] ULONG cImplemented,

[in,size_is(cImplemented)] CATID rgcatidImpl[],

[in] ULONG cRequired,

[in,size_is(cRequired)] CATID rgcatidReq[]);

// get list of class's implemented categories

// получаем список реализованных категорий класса

HRESULT EnumImplCategoriesOfClass([in] REFCLSID rclsid,

[out] IEnumCATID** ppenumCatid);

// get list of class's required categories

// получаем список категорий, необходимых классу

HRESULT EnumReqCategoriesOfClass([in] REFCLSID rclsid,

[out] IEnumCATID** ppenumCatid);

}

Большинство этих методов возвращают свои курсоры на списки идентификаторов категории или класса. Эти указатели называются нумераторами (enumerators ) и подробно описываются в главе 7.

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

// get the standard category manager // получаем стандартный менеджер категорий

ICatInformation *pci = 0; HRESULT hr = CoCreateInstance(

CLSID_StdComponentCategoriesMgr, 0,

CLSCTX_ALL, IID_ICatInformat1on, (void**)&pci); if (SUCCEEDED(hr)) {

// get the classes that are Simians (ignore required cats)

// получаем классы, являющиеся Simian

// (игнорируем требуемые категории)

IEnumCLSID *pec = 0;

CATID rgcid[1];

rgcid[0] = CATID_Simian;

hr = pci->EnumClassesOfCategories(1, rgcid, -1, 0, &pec);

if (SUCCEEDED(hr)) {

// walk list of CLSIDs 64 at a time

// просматриваем список CLSID no 64 за проход

enum { MAX = 64 };

CLSID rgclsid[MAX];

do {

ULONG cActual = 0;

hr = pec->Next(MAX, rgclsid, &cActual);

if (SUCCEEDED(hr)) {

for (ULONG i = 0; i < cActual; i++)

DisplayClass(rgclsid[i]);

}

}

while (hr == S_OK);

pec->Release();

}

pci->Release(); }

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

Рассмотрим следующий вызов EnumClassesOfCategories:

CATID rgimpl[1]; rgimpl[0] = CATID_Simians;

CATID rgreq[3]; rgreq[0] = CATID_HasWater;

rgreq[1] = CATID_HasOxygen; rgreq[2] = CATID_HasMilk;

hr =pci->EnumClassesOfCategories(1, rgimpl, 3, rgreq, &pec);

Результирующий список классов будет содержать всех приматов (Simians), которые не требуют от среды клиента ничего, кроме кислорода (Oxygen), воды (Water) и молока (Milk). Класс Chimp, зарегистрированный ранее, мог бы быть совместимым классом, так как он реализует специфицированную категорию Simian и требует подмножество специфицированных категорий, использованных в запросе.

Заключительным, причем спорным, аспектом категорий компонентов является представление о классе по умолчанию для категории. СОМ допускает регистрацию CATID в качестве CLSID под ключом реестра HKEY_CLASSES_ROOT\CLSID

Для преобразования CATID в CLSID по умолчанию используется средство TreatAs , введенное эмуляцией. Для указания того, что класс Gorilla является классом по умолчанию для Simian, необходимо добавить следующий ключ реестра:

[HKCR\CLSID\{CATID_Simian}\TreatAs] @={CLSID_Gorilla}

Это простое соглашение позволяет клиентам просто использовать CATID там, где ожидаются CLSID:

// create an instance of the default Simian class

// создаем экземпляр класса Simian, принятого по умолчанию

hr = CoCreateInstance(CATID_Simian, 0, CLSCTX_ALL, IID_IApe, (void**)&pApe);

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

 

Где мы находимся?

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

 

В главе 2 обсуждались основы интерфейсов СОМ вообще и интерфейс IUnknown в частности. Было дано понятие о том, что путем наследования дополнительным интерфейсам объекты могут выставлять более одного вида функциональных возможностей. Был также продемонстрирован механизм, с помощью которого клиенты могут опрашивать объекты, чтобы найти среди них доступные функциональные возможности. Этот механизм – QueryInterface (Интерфейс запросов) – был выделен как версия С++-оператора преобразования типа dynamic_cast, не зависящая от языка программирования и от компилятора.

В предыдущей главе было показано, что QueryInterface можно реализовать непосредственно, используя статические преобразования типа для того, чтобы ограничить область действия указателя this на объект типом интерфейса, который запрашивается клиентом. На физическом уровне этот способ означает просто преобразование идентификаторов интерфейса в объект с помощью соответствующего смещения, то есть способ, который применяется любым компилятором C++ при реализации dynamic_cast.

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

 

Снова IUnknown

IUnknown не имеет реализации по умолчанию, которая являлась бы частью интерфейса системного вызова СОМ. Заголовочные файлы SDK не содержат базовых классов, макросов или шаблонов, предусматривающих реализации QueryInterface, AddRef и Release, которые должны использоваться во всех программах на С или C++. Вместо этого Спецификация СОМ (Component Object Model Specification) предоставляет очень точные правила относительно допущений, которые клиенты и объекты могут делать относительно этих трех методов. Этот набор правил формирует протокол IUnknown и позволяет каждому разработчику объекта преобразовать три указанных метода IUnknown во все, что имеет смысл для его или ее объекта.

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

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

import «unknwn.idl»;

[object, uuid(CD538340-A56D-11d0-8C2F-0080C73925BA)]

interface IVehicle : IUnknown {

HRESULT GetMaxSpeed([out, retval] long *pMax); }

[object, uuid(CD53834l-A56D-11d0-8C2F-0080C73925BA)]

interface ICar : IVehicle {

HRESULT Brake(void); }

[object, uuid(CD538342-A56D-11d0-8C2F-0080C73925BA)]

interface IPlane : IVehicle {

HRESULT TakeOff(void); }

[object, uuid(CD538343-A56D-11d0-8C2F-0080C73925BA)]

interface IBoat : IVehicle {

HRESULT Sink(void); }

СОМ использует стандартную технологию для визуального представления объектов. Эта технология находится в рамках принципа СОМ отделения интерфейса от реализации и не раскрывает никаких деталей реализации объекта, кроме списка выставляемых им интерфейсов. Эта технология также визуально усиливает многие из правил IUnknown. Рисунок 4.1 показывает стандартное представление класса CarBoatPlane, который реализует все только что определенные интерфейсы. Заметим, что единственный вывод, который можно сделать из этого рисунка, таков: если не произойдет катастрофического сбоя, объекты CarBoatPlane будут выставлять пять интерфейсов: IBoat, IPlane, ICar, IVehicle и IUnknown.

Первое правило IUnknown, подлежащее исследованию, – это требование, чтобы QueryInterface был симметричным, транзитивным и рефлексивным (Symmetric/Transitive/Reflexive). Эти требования определяют отношения между всеми интерфейсными указателями объекта и начинают определять понятие идентификации (identity) объектов СОМ. Подобно всем правилам IUnknown, эти требования должны исполняться всегда, за исключением катастрофических сбоев, теми, кто хочет считаться действительным объектом СОМ.

 

QueryInterface симметрична

Спецификация СОМ требует, чтобы, если запрос QueryInterface на интерфейс B удовлетворяется через интерфейсный указатель типа A, то запрос QueryInterface на интерфейс A того же самого объекта через результирующий интерфейсный указатель типа В всегда был успешным. Это значит, что если верно QI(A)->B, то также должно быть верным QI(QI(A)->B)->A

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

void AssertSymmetric(ICar *pCar) { if (pCar)

{

IPlane *pPlane = 0;

// request a second type of interface

// запрашиваем второй тип интерфейса

HRESULT hr = pCar->QueryInterface(IID_IPlane, (void**)&pPlane);

if (SUCCEEDED(hr)) { ICar *pCar2 = 0;

// request original type of interface

// запрашиваем исходный тип интерфейса

hr = pPlane->QueryInterface(IID_ICar, (void**)&pCar2);

// if the following assertion fails, pCar

// did not point to a valid СОМ object

// если следующее утверждение не будет правильным,

// то pCar не укажет на правильный СОМ-объект

assert(SUCCEEDED(hr));

pCar2->Release();

}

pPlane->Release();

}

}

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

 

QueryInterface транзитивна

Спецификация СОМ требует также, чтобы, если запрос QueryInterface на интерфейс В удовлетворяется через интерфейсный указатель типа A, а второй запрос QueryInterface на интерфейс C удовлетворяется через указатель типа В , то запрос QueryInterface на интерфейс C через исходный указатель типа A был бы также успешным. Это означает, что если верно QI(QI(A)->B)->C, то должно быть верным и QI(A)->C

Это условие иллюстрируется рис. 4.3 и означает, что утверждение, приведенное в нижеследующем коде, должно всегда быть верным:

void AssertTransitive(ICar *pCar)

{

if (pCar)

{

IPlane *pPlane = 0;

// request intermediate type of interface

// запрос промежуточного типа интерфейса

HRESULT hr = pCar->QueryInterface(IID_IPlane, (void**)&pPlane);

if (SUCCEEDED(hr))

{

IBoat *pBoat1 = 0;

// request terminal type of interface

// запрос конечного типа интерфейса

hr = pPlane->QueryInterface(IID_IBoat, (void**)&pBoat1);

if (SUCCEEDED(hr))

{

IBoat *pBoat2 = 0;

// request terminal type through the original pointer

// запрос конечного типа через исходный указатель

hr = pCar->QueryInterface(IID_IBoat, (void**)&pBoat2);

// if the following assertion fails, pCar

// did not point to a valid СОМ object

// если следующее утверждение неверно, то pCar

// не указывал на корректный СОМ-объект

assert(SUCCEEDED(hr));

pBoat2->Release();

}

pBoat1->Release();

}

pPlane->Release();

}

}

Из транзитивности QueryInterface следует, что все интерфейсы, которые выставляет объект, равноправны и не требуют, чтобы их вызывали в какой-то определенной последовательности. Если бы это было не так, то клиентам пришлось бы заботиться о том, какой указатель на объект использовать для различных запросов QueryInterface. Из транзитивности и симметричности QueryInterface следует, что любой интерфейсный указатель на объект выдаст тот же самый ответ «да/нет» на любой запрос QueryInterface. Единственная ситуация, не охватываемая транзитивностью и симметричностью, это повторные запросы одного и того же интерфейса. Эта ситуация требует, чтобы QueryInterface был и рефлективным.

 

QueryInterface рефлективна

Спецификация СОМ требует, чтобы запрос QueryInterface через интерфейсный указатель всегда достигал цели, если запрошенный тип соответствует типу указателя, с помощью которого произведен запрос. Это означает, что QI(A)->A всегда должен быть верным.

Это требование проиллюстрировано рис. 4.4 и в следующем фрагменте кода:

void AssertReflexive(ICar *pCar)

{

if (pCar)

{

ICar *pCar2 = 0;

// request same type of interface

// запрос интерфейса того же типа

HRESULT hr = pCar->QueryInterface(IID_ICar, (void**)&pCar2);

// if the following assertion fails, pCar

// did not point to a valid СОМ object

// если следующее утверждение неверно, то pCar

// не указывает на корректный объект СОМ

assert(SUCCEEDED(hr));

pCar2->Release();

}

}

Из этого кода следует, что все реализации ICar должны быть способны удовлетворить дополнительные запросы QueryInterface для ICar через интерфейсный указатель ICar. Если бы это не соблюдалось, то было бы невозможно передавать жестко типизированные интерфейсы через параметры базового типа без невосполнимой потери исходного типа:

extern void GetCar(ICar **ppcar);

extern void UseVehicle(IVehicle *pv);

ICar *pCar;

GetCar(&pCar);

UseVehicle(pCar);

// ICar-ness is syntactically lost

// ICar-ность синтаксически потеряна

void UseVehicle(IVehicle *pv)

{

ICar *pCar = 0;

// try to regain syntactic ICar-ness

// пытаемся восстановить синтаксическую ICar-ность

HRESULT hr = pv->QueryInterface(IID_ICar, (void**)&pCar);

}

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

Из того, что QueryInterface является симметричным, рефлексивным и транзитивным, следует, что любой интерфейсный указатель на объект должен выдавать тот же самый ответ «да/нет» на данный запрос QueryInterface. Это позволяет клиентам рассматривать иерархию типов объекта как простой граф, все вершины которого непосредственно соединены друг с другом (и с самими собой) с помощью открытых (explicit) ребер. На рис. 4.5 изображен такой граф. Отметим, что в любую вершину графа можно попасть из любой другой вершины, пройдя вдоль только одного ребра.

 

Объекты имеют статический тип

Один из выводов, который можно сделать из трех требований QueryInterfасе , состоит в том, что множество интерфейсов, поддерживаемых объектом, не может изменяться во времени. Спецификация СОМ четко требует, чтобы этот вывод был верен для всех объектов. Из этого требования следует, что иерархия типов объекта является статичной, несмотря на тот факт, что для определения множества поддерживаемых типов данных клиенты должны опрашивать объекты динамически. Если объект отвечает «да» на запрос интерфейса типа А, то он должен отвечать «да», начиная с этой точки. Если объект отвечает «нет» на запрос интерфейса типа А , то он должен отвечать «нет», начиная с этой точки. Фраза «начиная с этой точки» (from that point on) буквально переводится как «до тех пор, пока есть хотя бы один внешний указатель интерфейса на объект». Обычно это соответствует жизненному циклу базового объекта C++, но язык Спецификации СОМ обладает достаточной свободой, чтобы предоставить разработчикам определенную гибкость (например, иерархия типов глобальной переменной может изменяться, когда все указатели освобождены).

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

void AssertStaticType(IUnknown *pUnk, REFIID riid)

{

IUnknown *pUnk1 = 0,

*pUnk2 = 0;

HRESULT hr1 = pUnk->QueryInterface(riid, (void**)&pUnk1);

HRESULT hr2 = pUnk->QueryInterface(riid, (void**)&pUnk2);

// both requests for the same interface should

// yield the same yes/no answer

// оба запроса того же самого интерфейса

// должны получить тот же самый ответ да/нет

assert(SUCCEEDED(hr1) == SUCCEEDED(hr2));

if (SUCCEEDED(hr1)) pUnk1->Release();

if (SUCCEEDED(hr2)) pUnk2->Release();

}

Это требование означает, что в СОМ запрещены следующие программные технологии:

Использование временной информации при решении вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс IMorning (утро) только до 12:00).

Использование переменной информации о состоянии при решении вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс INotBusy (не занят), только если количество внешних интерфейсных указателей меньше десяти).

Использование маркера доступа (security token) вызывающего объекта для решения, удовлетворять или нет запрос QueryInterface . Как будет объяснено в главе 6, на самом деле это не обеспечивает никакой реальной безопасности из-за протокола передачи (wire protocol ), используемого СОМ.

Использование успешного захвата динамических ресурсов для решения вопроса о том, удовлетворять или нет запрос QueryInterface (например, выдавать интерфейс IHaveTonsOfMemory (у меня тонны памяти) только при успешном выполнении malloc(4096*4096)).

Эта последняя методика может быть до некоторой степени смягчена, если разработчик объекта желает поупражняться с выражением спецификации СОМ «barring catastrophic failure» (за исключением катастрофического сбоя).

Эти ограничения не означают, что два объекта одного и того же класса реализации не могут давать различные ответы «да/нет» при запросе одного и того же интерфейса. Например, класс может реализовать показанные ранее интерфейсы ICar, IBoat и IPlane , но может разрешить только одному интерфейсу быть использованным в каком-то определенном объекте. Эти ограничения также не означают, что объект не может использовать постоянную или временную информацию для решения вопроса о том, дать ли исходное «да» или «нет» для данного интерфейса. В примере для класса, который разрешает только один из трех интерфейсов, следующая идиома была бы вполне допустимой:

class СВР : public ICar, public IPlane, public IBoat

{

enum TYPE { CAR, BOAT, PLANE, NONE };

TYPE m_type;

CBP(void) : m_type(NONE) { }

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)

{

if (md == IID_ICar)

{

// 1st QI Initializes type of object

// первая QI инициализирует тип объекта

if (m_type == NONE) m_type = CAR;

// only satisfy request if this object is a car

// удовлетворяем запрос, только если данный объект

// является car (автомобилем)

if (m_type == CAR) *ppv = static_cast(this);

else return (*ppv = 0), E_NOINTERFACE;

}

else if (md == IID_IBoat)

{

// similar treatment for IBoat and IPlane

// IBoat и IPlane обрабатываются сходным образом

}

};

Из требования, чтобы множество поддерживаемых интерфейсов было статичным, следует простой вывод, что разработчикам объектов не разрешается создавать конструкции, состоящие из одного объекта, который дает два различных ответа «да/нет» на запрос определенного интерфейса. Одна из причин того, что иерархия типов объекта должна оставаться неизменной на всем протяжении своего жизненного цикла, состоит в том, что СОМ не гарантирует отправления всех клиентских запросов QueryInterface такому объекту в случае, когда к нему имеется удаленный доступ. Неизменность иерархии типов позволяет «заместителям» на стороне клиента (client-side proxies) кэшировать результаты QueryInterface во избежание чрезмерных обменов клиент-объект. Такая оптимизация очень важна для эффективности СОМ, но она разрушает конструкции, использующие QueryInterface для передачи динамической семантической информации вызывающему объекту.

 

Единственность и идентификация

Предыдущий раздел был посвящен запросам QueryInterface, которые представляют собой ответы типа «да/нет» вызывающим объектам. QueryInterface действительно возвращает S_OK (да) или E_NOINTERFACE (нет). Впрочем, когда QueryInterface возвращает S_OK, то он также возвращает объекту интерфейсный указатель. Для СОМ значение этого указателя чрезвычайно важно, так как оно позволяет клиентам определить, действительно ли на один и тот же объект указывают два интерфейсных указателя.

 

QueryInterface и IUnknown

Свойство рефлективности QueryInterface гарантирует, что любой интерфейсный указатель сможет удовлетворить запросы на IUnknown, поскольку все интерфейсные указатели неявно принадлежат к типу IUnknown. Спецификация СОМ имеет немного больше ограничений при описании результатов запросов QueryInterface именно на IUnknown. Объект не только должен отвечать «да» на запрос, он должен также возвращать в ответ на каждый запрос в точности одно и то же значение указателя. Это означает, что в следующем коде оба утверждения всегда должны быть верны:

void AssertSameObject(IUnknown *pUnk)

{

IUnknown *pUnk1 = 0,

*pUnk2 = 0;

HRESULT hr1 = pUnk->QueryInterface(IID_IUnknown, (void **)&pUnk1);

HRESULT hr2 = pUnk->QueryInterface(IID_IUnknown, (void **)&pUnk2);

// QueryInterface(IUnknown) must always succeed

// QueryInterface(IUnknown) должно всегда быть успешным

assert(SUCCEEDED(hr1) && SUCCEEDED(hr2));

// two requests for IUnknown must always yield the

// same pointer values

// два запроса на IUnknown должны всегда выдавать

// те же самые значения указателя

assert(pUnk1 == pUnk2);

pUnk1->Release();

pUnk2->Release();

}

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

bool IsSameObject(IUnknown *pUnk1, IUnknown *pUnk2)

{ assert(pUnk1 && pUnk2);

bool bResult = true;

if (pUnk1 != pUnk2)

{

HRESULT hr1, hr2; IUnknown *p1 = 0, *p2 = 0;

hr1 = pUnk1->QueryInterface(IID_IUnknown, (void **)&p1);

assert(SUCCEEDED(hr1));

hr2 = pUnk2->QueryInterface(IID_IUnknown, (void **)&p2);

assert(SUCCEEDED(hr2));

// compare the two pointer values, as these

// represent the identity of the object

// сравниваем значения двух указателей,

// так как они идентифицируют объект

bResult = (р1 == р2); p1->Release();

p2->Release();

}

return bResult;

}

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

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

class CarBoatPlane : public ICar, public IBoat, public IPlane

{

public:

// IUnknown methods – методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods – методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods – методы

ICar STDMETHODIMP Brake(void);

// IBoat methods – методы

IBoat STDMETHODIMP Sink(void);

// IPlahe methods – методы

IPlane STDMETHODIMP TakeOff(void); };

Ниже приведена стандартная реализация QueryInterface в CarBoatPlane:

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast(this);

else if (riid == IID_IVehicle) *ppv = static_cast(this);

else if (riid == IID_ICar) *ppv = static_cast(this);

else if (riid == IID_IBoat) *ppv = static_cast(this);

else if (riid == IID_IPlane) *ppv = static_cast(this);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

Для того чтобы быть объектом СОМ, реализация CarBoatPlane QueryInterface должна полностью придерживаться правил IUnknown , приведенных в данной главе.

Класс CarBoatPlane выставляет интерфейсы только типа ICarIPlane, IBoat, IVehicle и IUnknown . Каждая таблица vtbl CarBoatPlane будет ссылаться на единственную реализацию QueryInterface, показанную выше. К каждому поддерживаемому интерфейсу можно обращаться через эту реализацию QueryInterface, так что невозможно найти два несимметричных интерфейса, то есть не существует двух интерфейсов A и B, для которых неверно следующее:

If QI(A)->B Then QI(QI(A)->B)->A

Если следовать той же логике, то поскольку все пять интерфейсов принадлежат к одной и той же реализации QueryInterface, не существует трех интерфейсов А, В и С , для которых неверно следующее:

If QI(QI(A)->B)->C Then QI(A)->C

Наконец, поскольку реализация QueryInterface всегда удовлетворяет запросы на пять возможных интерфейсных указателей, которые могут поддерживаться клиентом, то следующее утверждение должно быть верным для каждого из пяти поддерживаемых интерфейсов:

QI(A)->A

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

Реализация также корректно выполняет правило СОМ об идентификации, возвращая только одно значение указателя при запросе IUnknown:

if (riid == IID_IUnknown) *ppv = static_cast(this);

Если бы реализация QueryInterface возвращала различные указатели vptr для каждого запроса:

if (riid == IID_IUnknown)

{

int n = rand() % 3;

if (n == 0) *ppv = static_cast(this);

else if (n == 1) *ppv = static_cast(this);

else if (n == 2) *ppv = static_cast(this);

}

то реализация была бы корректной только в терминах чисто С++-отношений типа (то есть все три интерфейса были бы совместимы по типу с запрошенным типом IUnknown). Эта реализация, однако, не является допустимой с точки зрения СОМ, поскольку правило идентификации для QueryInterface было нарушено.

 

Множественные интерфейсы и имена методов

Множественное наследование является очень эффективной и простой технологией для реализации интерфейсов СОМ в классе C++. Это требует написания очень короткого явного кода, так как большая часть работы компилятора и компоновшика заключается в построении соответствующих СОМ указателей vptr и таблиц vtbl. Если имя метода появляется более чем в одном базовом классе с идентичными типами параметров, то компилятор и компоновщик заполняют каждый элемент vtbl таким образом, чтобы он указывал на одну реализацию метода в классе. Этот режим применяется к таким методам, как QueryInterface, AddRef и Release, так как все интерфейсы СОМ начинаются с этих методов, и все же разработчику класса требуется написать каждый метод только один раз (и это хорошо). Этот же режим применяется и к методам любых интерфейсов, где происходит повтор имени и сигнатуры. Здесь есть одна возможная ловушка множественного наследования.

Иерархия транспортных интерфейсов из этой главы содержит конфликт имен. В интерфейсе ICar (автомобиль) имеется метод, названный GetMaxSpeed (развить максимальную скорость). В интерфейсах IBoat (лодка) и IPlane (самолет) также имеются методы, именуемые GetMaxSpeed с идентичной сигнатурой. Это означает, что при использовании множественного наследования разработчик класса пишет метод GetMaxSpeed один раз, а компилятор и компоновщик инициализируют таблицы vtbl , совместимые с ICar, IBoat и IPlane так, чтобы они указывали только на эту реализацию.

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

struct IXCar : public ICar {

// add new non-clashing method as pure virtual

// добавляем новый неконфликтный метод как чисто виртуальный

virtual HRESULT STDMETHODCALLTYPE GetMaxCarSpeed(long *pval) = 0;

// implement clashing method by upcalling

// non-clashing implementation in derived class

// реализуем конфликтный метод путем вызова

// неконфликтной реализации в производном классе

STDMETHODIMP GetMaxSpeed(long *pval)

{ return GetMaxCarSpeed(pval); }

};

Допуская, что интерфейсы IBoat и IPlane подвергнуты подобной операции, можно реализовывать различные версии GetMaxSpeed простым наследованием от расширенных версий интерфейсов и переопределением неконфликтных версий каждого метода GetMaxSpeed:

class CarBoatPlane: public IXCar, public IXBoat, public IXPlane

{

public:

// Unknown methods – методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods – методы IVehicle

// do not override GetMaxSpeed!

// не подменяем GetMaxSpeed!

// ICar methods – методы ICar

STDMETHODIMP Brake(void);

// IBoat methods – методы IBoat

STDMETHODIMP Sink(void);

// IXPlane methods – методы IXPlane

STDMETHODIMP TakeOff(void);

// upcalled from IXCar::GetMaxSpeed

// вызвано из IXCar::GetMaxSpeed

STDMETHODIMP GetMaxCarSpeed(long *pval);

// upcalled from IXBoat::GetMaxSpeed

// вызвано из IXBoat::GetMaxSpeed

STDMETHODIMP GetMaxBoatSpeed(long *pval);

// called from IXPlane::GetMaxSpeed

// вызвано из IXPlane::GetMaxSpeed

STDMETHODIMP GetMaxPlaneSpeed(long *pval);

}

Рисунок 4.6 иллюстрирует представление этого класса и форматы таблиц vtbl. Отметим, что конфликтный метод GetMaxSpeed не реализован в этом классе. Поскольку каждый из базовых классов CarBoatPlane подменяет этот чисто виртуальный метод, то CarBoatPlane не нуждается в создании своей собственной реализации. Действительно, если бы в CarBoatPlane нужно было подменить GetMaxSpeed, то одна его реализация этого метода подменила бы версии, вызываемые из каждого базового класса, аннулировав результат использования IXCar, IXBoat и IXPlane. В силу этой проблемы данная технология годится только в тех ситуациях, когда можно быть уверенным, что класс реализации (или любые возможные производные классы) никогда не станет подменять конфликтный метод.

Другой способ обеспечения множественных реализации конфликтных методов состоит в том, чтобы усилить правила IUnknown . Спецификация СОМ не требует, чтобы объект был реализован как класс C++. Хотя существует весьма естественное соответствие между объектами СОМ и классами C++, базирующимися на множественном наследовании, это всего лишь одна из возможных технологий реализации. Для создания объекта СОМ может быть использована любая программная технология, производящая таблицы vtbl в нужном формате и удовлетворяющая правилам СОМ для QueryInterface. Один стандартный метод разрешения конфликтов имен состоит в реализации интерфейсов с конфликтующими именами как отдельных классов C++ и последующей компоновке целевого класса C++ из экземпляров этих отдельных классов. Для гарантии того, что каждый из этих составных элементов данных появится во внешнем мире как единый объект СОМ, часто назначается одна главная реализация QueryInterface, которой каждый составной элемент данных будет передавать функции. Следующий код демонстрирует эту технологию:

class CarPlane

{

LONG m_cRef;

CarPlane(void) : m_cRef(0) {}

public:

// Main IUnknown methods

// Главные методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

private:

// define nested class that implements ICar

// определяем вложенный класс, реализующий

ICar struct XCar : public ICar

{

// get back pointer to main object

// получаем обратный указатель на главный объект

inline CarPlane* This();

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Brake(void);

};

// define nested class that implements IPlane

// определяем вложенный класс, реализующий IPlane

struct XPlane : public IPlane {

// Get back pointer to main object

// получаем обратный указатель на главный объект

inline CarPlane* This();

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP TakeOff(void);

};

// declare instances of nested classes

// объявляем экземпляры вложенных классов

XCar m_xCar;

XPlane m_xPlane;

};

Использование вложенных классов не является обязательным, но оно подчеркивает, что эти подчиненные классы не имеют смысла вне контекста класса CarPlane. Рисунок 4.7 показывает двоичное размещение этого класса и размещения соответствующих vtbl .

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

STDMETHODIMP CarPlane::XCar::GetMaxSpeed(long *pn) {

// set *pn to max speed for cars

// устанавливаем *pn для максимальной скорости автомобилей

}

STDMETHODIMP CarPlane::XPlane::GetMaxSpeed(long *pn) {

// set *pn to max speed for planes

// устанавливаем *pn для максимальной скорости самолетов

}

Тот факт, что две реализации GetMaxSpeed встречаются в различных определениях вложенных классов, позволяет определить метод дважды и к тому же гарантирует то, что таблицы vtbl, соответствующие ICar и IPlane, будут иметь различные элементы для GetMaxSpeed.

Необходимо также отметить, что хотя класс CarPlane, находящийся на верхнем уровне, реализует методы IUnknown, он не наследует никакому производному от IUnknown классу. Вместо этого объекты CarPlane имеют элементы данных, которые наследуют интерфейсам СОМ. Это значит, что вместо того, чтобы использовать static_cast для вхождения в объект и нахождения определенного указателя vptr, реализация QueryInterface в CarPlane должна возвратить указатель на тот элемент данных, который реализует запрашиваемый интерфейс:

STDMETHODIMP CarPlane::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast(&m_xCar);

else if (riid == IID_IVehicle) *ppv = static_cast (&m_xCar);

else if (riid == IID_ICar) *ppv = static_cast(&m_xCar);

else if (riid == IID_IPlane) *ppv = static_cast(&m_xPlane);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)(*ppv))->AddRef();

return S_OK;

}

Для обеспечения идентификации объекта каждый из элементов данных CarPlane должен или воспроизвести этот код в своей собственной реализации QueryInterface, или просто передать управление главной функции QueryInterface в CarPlane. Чтобы осуществить это, необходим механизм перехода к главному объекту со стороны функции-члена составного элемента данных. Определение класса CarPlane::XCar содержит встроенную подпрограмму, которая использует фиксированные смещения для вычисления указателя this главного объекта от указателя this составного элемента данных.

inline CarPlane CarPlane::XCar::This(void)

{

return (CarPlane*)((char*)this

// ptr to composite – указатель на композит – offsetof (CarPlane, m_xCar)); }

inline CarPlane CarPlane::XPlane::This(void)

{

return (CarPlane*)((char*)this

// ptr to composite – указатель на композит

– offsetof(CarPlane, m_xPlane));

}

Такая технология вычисления обратного указателя (back-pointer) компактна и чрезвычайно эффективна, так как не требует явных элементов данных для нахождения главного объекта внутри реализации метода элемента данных. При наличии таких алгоритмов вычисления обратного указателя реализация композитного QueryInterface становится тривиальной:

STDMETHODIMP CarPlane::XCar::QueryInterface(REFIID r, void**p)

{

return This()->QueryInterface(r, p);

}

STDMETHODIMP CarPlane::XPlane::QueryInterface(REFIID r, void**p)

{

return This()->QueryInterface(r, p);

}

Такая же передача this потребуется для AddRef и Release для получения обобщенного представления о времени жизни объекта в случае составных (композитных) элементов данных.

Технология, основанная на использовании композиции для реализации интерфейсов, требует значительно больше кода, чем при простом множественном наследовании. Кроме того, качество генерированного кода, вероятно, не лучше (а возможно, и хуже), чем в случае множественного наследования. Из того факта, что классу CarPlane не понадобилось наследовать ни одному интерфейсу СОМ, следует, что композиция является разумной технологией для внесения СОМ в старые библиотеки классов. Например, MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) использует эту технологию. Причиной применения композиции при реализации новых классов является получение отдельных реализации метода, определенного одинаково более чем в одном интерфейсе. К счастью, стандартные интерфейсы, определяемые СОМ, очень редко создают такие конфликты, а те немногие, которые создают, почти всегда преобразуются в семантически эквивалентные функции. Для разрешения коллизий, подобных тем, что произошли в сценарии с GetMaxSpeed , композиция, вероятно, и не требуется, так как в первом приближении для преобразования двойников в уникальные объекты достаточно использования промежуточных классов. Эта методика проста, эффективна и фактически не требует дополнительного кода. Основная причина использования композиции в новом коде заключается в том, что нужно обеспечить подсчет ссылок в каждом интерфейсе.

Иногда желательно разместить ресурсы в объекте на базе уже использующихся интерфейсов. В то же время из использования множественного наследования для реализации интерфейсов СОМ следует, что в каждой таблице vtbl будет использована только одна реализация AddRef и Release. Хотя можно выявить первый запрос на заданный интерфейс и разместить ресурсы по требованию:

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IBoat)

{

// allocate resource the first time through

// размещаем ресурсы при первом проходе

if (m_pTonsOfMemory == 0) m_pTonsOfMemory = new char[4096 * 4096];

*ppv = static_cast(this);

}

else if

…

}

не существует способа определить момент, когда больше нет внешних указателей интерфейса IBoat, так как вызов Release, который клиент делает через интерфейс IBoat, неотличим от вызова Release, сделанного через любой другой интерфейс объекта. В обычной ситуации именно это и нужно, но в данном случае вызовы AddRef и Release через интерфейсы IBoat необходимо рассматривать иначе. Если бы интерфейс IBoat был реализован с использованием композиции, то он имел бы свои собственные уникальные реализации AddRef и Release, в которых он мог бы поддерживать свой собственный счетчик ссылок, отличный от счетчика главного объекта:

class CarBoatPlane : public ICar, public IPlane

{

LONG m_cRef;

char *m_pTonsOfMemory;

CarBoatPlane (void) : m_cRef(0),

m_pTonsOfMemory (0) {}

public:

// IUnknown methods – методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods – методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods – методы ICar

STDMETHODIMP Brake(void);

// IPlane methods – методы IPlane

STDMETHODIMP TakeOff(void);

// define nested class that implements IBoat

// определяем вложенный класс, реализующий IBoat

struct XBoat : public IBoat {

// get back pointer to main object

// получаем обратный указатель на главный объект

inline CarBoatPlane* This();

LONG m_cBoatRef;

// per-interface ref count

// счетчик ссылок на каждый интерфейс

XBoat(void) : m_cBoatRef(0) {}

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Sink(void);

};

XBoat m_xBoat; };

Реализация AddRef и Release из IBoat могут теперь следить за числом ссылок типа IBoat и высвободить ресурсы, когда они больше не нужны:

STDMETHODIMP_(ULONG) CarBoatPlane::XBoat::AddRef()

{

ULONG res = InterlockedIncrement(&m_cBoatRef);

if (res == 1)

{

// first AddRef – первый AddRef

// allocate resource and forward AddRef to object

// размещаем ресурсы и пересылаем AddRef на объект

This()->m_pTonsOfMemory = new char[4096*4096];

This()->AddRef(); }

return res; }

STDMETHODIMP_(ULONG) CarBoatPlane::XBoat::Release()

{

ULONG res = InterlockedDecrement(&m_cBoatRef);

if (res == 0) {

// last Release – последний Release

// free resource and forward Release to object

// освобождаем ресурсы и пересылаем Release на объект

delete [] This()->m_pTonsOfMemory;

This()->Release();

} return res; }

Чтобы эта методика работала, все пользующиеся интерфейсными указателями должны придерживаться требований спецификации СОМ: функция Release должна вызываться через указатель, посредством которого вызывается соответствующая функция AddRef. Поэтому правильной концовкой QueryInterface будет следующая:

((IUnknown*)(*ppv))->AddRef();

// use exact ptr

// используем точный указатель return S_OK;

вместо такого:

AddRef();

// just call this->AddRef

// только вызов

this->AddRef return S_OK;

Первый вариант гарантирует, что если клиент пишет следующий правильный код

IBoat *pBoat = 0;

HRESULT hr = pUnk->QueryInterface(IID_IBoat, (void**)&pBoat);

if (SUCCEEDED(hr))

{ hr = pBoat->Sink(); pBoat->Release(); }

то для AddRef и для Release обязательно будет использовано одно и то же значение указателя.

Можно осуществлять композицию в контексте управляемой таблицами реализации QueryInterface. При наличии семейства макросов препроцессора, показанного в предыдущей главе, достаточно всего одного дополнительного макроса, чтобы определить, что вместо базового класса используется элемент данных, и второго макроса, чтобы реализовать методы IUnknown в композите:

class CarBoatPlane : public ICar, public IPlane

{ public: struct XBoat : public IBoat

{

// composite QI/AddRef/Release/This()

// композит из QI/AddRef/Release/This()

IMPLEMENT_COMPOSITE_UNKNOWN(CarBoatPlane, XBoat, m_xBoat) STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Sink(void);

};

XBoat m_xBoat;

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

// IPlane methods

// методы IPlane

STDMETHODIMP TakeOff(void);

// standard heap-based QI/AddRef/Release

// стандартные расположенные в «куче» QI/AddRef/Release

IMPLEMENT_UNKNOWN(CarBoatPlane)

BEGIN_INTERFACE_TABLE(CarBoatPlane)

IMPLEMENTS_INTERFACE_AS(IVehicle, ICar)

IMPLEMENTS_INTERFACE(ICar)

IMPLEMENTS_INTERFACE(IPlane)

// macro that calculates offset of data member

// макрос, вычисляющий смещение элемента данных

IMPLEMENTS_INTERFACE_WITH_COMPOSITE(IBoat, XBoat, m_xBoat)

END_INTERFACE_TABLE() };

В приведенном выше определении класса опущены только определения методов объекта вне QueryInterfасе, AddRef и Release. Два новых макроса, использованных в определении класса, определяются следующим образом:

// inttable.h

// (book-specific header file)

// (заголовочный файл, специфический для данной книги)

#define COMPOSITE_OFFSET(ClassName, BaseName, \

MemberType, MemberName) \

(DWORD(static_cast(\

reinterpret_cast(0x10000000 + \

offsetof(ClassName, MemberName)))) – 0х10000000)

#define IMPLEMENTS_INTERFACE_WITH_COMPOSITE(Req,\

MemberType, MemberName) \

{ &IID_##Req,ENTRY_IS_OFFSET, COMPOSITE_OFFSET(_IT,\

Req, MemberType, MemberName) },

// impunk.h

// (book-specific header file)

// (заголовочный файл, специфический для данной книги)

#define IMPLEMENT_COMPOSITE_UNKNOWN(OuterClassName,\

InnerClassName, DataMemberName) \

OuterClassName *This() \

{ return (OuterClassName*)((char*)this – \

offsetof(OuterClassName, DataMemberName)); }\

STDMETHODIMP QueryInterface(REFIID riid, void **ppv)\

{ return This()->QueryInterface(riid, ppv); }\

STDMETHODIMP_(ULONG) AddRef(void) \

{ return This()->AddRef(); }\

STDMETHODIMP_(ULONG) Release(void) \

{ return This()->Release(); }

Эти макросы препроцессора просто дублируют фактические реализации QueryInterface, AddRef и Release , использованные в композиции.

 

Динамическая композиция

Если для реализации интерфейса в классе C++ используется множественное наследование или композиция, то в каждом объекте этого класса будут содержаться служебные данные (overhead) указателя vptr размером в четыре байта на каждый поддерживаемый интерфейс (принимая, что sizeof (void*) == 4). Если число интерфейсов, экспортируемых объектом, невелико, то эти служебные данные не играют важной роли, особенно в свете преимуществ, предоставляемых программной моделью СОМ. Если, однако, число поддерживаемых интерфейсов велико, то размер служебных данных vptr может вырасти до такой степени, что часть объекта, не связанная с СОМ, будет казаться маленькой по сравнению с ними. При использовании каждого из этих интерфейсов все время без служебных данных не обойтись. Если же, однако, эти интерфейсы не будут использоваться никогда или использоваться в течение короткого времени, то можно воспользоваться лазейкой в Спецификации СОМ и оптимизировать vptr некоторых неиспользуемых объектов.

Вспомним правило, гласящее, что все запросы QueryInterface на объект относительно IUnknown должны возвращать точно такое же значение указателя. Именно так в СОМ обеспечивается идентификация объектов. В то же время Спецификация СОМ определенно разрешает возвращать другие значения указателей в ответ на запросы QueryInterface относительно любых других типов интерфейсов, кроме IUnknown. Это означает, что для нечасто используемых интерфейсов объект может динамически выделять память для vptr по требованию, не заботясь о возврате того же самого динамически выделенного блока памяти каждый раз, когда запрашивается какой-либо интерфейс. Эта технология временного (transient) размещения композитов впервые была описана в «белой книге» Microsoft Поваренная книга для программистов СОМ (Microsoft white paper The СОМ Programmer's Cookbook), написанной Криспином Госвеллом (Crispin Goswell) (). В этой «белой книге» такие временные интерфейсы называются отделяемыми (tearoff).

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

1) главный объект динамически размещает отделяемый интерфейс вместо того, чтобы иметь элемент данных экземпляра, и

2) отделяемый композит должен содержать явный обратный указатель на главный объект, так как технология фиксированного смещения, используемая в композиции, здесь не работает, поскольку отделяемый интерфейс изолирован от основного объекта. Следующий класс реализует IBoat как отделяемый интерфейс:

class CarBoat : public ICar

{

LONG m_cRef;

CarBoat (void): m_cRef(0) {}

public:

// IUnknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pMax);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

// define nested class that implements IBoat

// определяем вложенный класс, реализующий IBoat

struct XBoat : public IBoat

{

LONG m_cBoatRef;

// back pointer to main object is explicit member

// обратный указатель на главный объект – явный член

CarBoat *m_pThis;

inline CarBoat* This()

{

return m_pThis;

}

XBoat(CarBoat *pThis);

~XBoat(void);

STDMETHODIMP QueryInterface(REFIID, void**);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pval);

STDMETHODIMP Sink(void);

};

// note: no data member of type Xboat

// заметим: нет элементов данных типа Xboat

};

Для QueryInterface главного объекта необходимо динамически разместить новый отделяемый интерфейс – каждый раз, когда запрашивается IBoat:

STDMETHODIMP CarBoat::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IBoat)

*ppv = static_cast(new XBoat(this));

else if (riid == IID_IUnknown)

*ppv = static_cast(this);

: 

:

:

Каждый раз при получении запроса на интерфейс IBoat размещается новый отделяемый интерфейс. Согласно стандартной практике QueryInterface вызова AddRef посредством результирующего указателя: ((IUnknown*)*ppv)->AddRef();

AddRef будет обрабатывать непосредственно из QueryInterface только отделяемый интерфейс. Важно то, что главный объект остается в памяти столько времени, сколько существует отделяемый интерфейс. Простейший путь обеспечить это – заставить сам отделяемый интерфейс представлять неосвобожденную ссылку. Это можно реализовать в разработчике и деструкторе отделяемого интерфейса:

CarBoat::XBoat::XBoat(CarBoat *pThis) : m_cBoatRef(0), m_pThis(pThis)

{

m_pThis->AddRef();

}

CarBoat::XBoat::~XBoat(void)

{

m_pThis->Release();

}

Как и в случае с композицией, методу QueryInterface отделяемого интерфейса требуется идентифицировать объект, делегируя освобождение функции главного объекта. Однако отделяемый интерфейс может выявлять запросы на тот интерфейс (интерфейсы), который он сам реализует, и просто возвращать указатель, обработанный AddRef, себе самому:

STDMETHODIMP CarBoat::XBoat::QueryInterface(REFIID riid, void**ppv)

{

if (riid != IID_IBoat) return This()->QueryInterface(riid, ppv);

*ppv = static_cast(this);

reinterpret_cast(*ppv)->AddRef();

return S_OK;

}

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

STDMETHODIMP_(ULONG) CarBoat::XBoat::AddRef (void)

{

return InterlockedIncrement(&m_cRef);

}

STDMETHODIMP_(ULONG) CarBoat::XBoat::Release(void)

{

ULONG res = InterlockedDecrement(&m_cBoatRef);

if (res == 0) delete this;

// dtor releases main object

// деструктор освобождает главный объект

return res;

}

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

На первый взгляд, отделяемые интерфейсы кажутся лучшей из всех возможностей. Когда интерфейс не используется, то на его служебные данные отводится нуль байт объекта. Когда же интерфейс используется, объект косвенно тратит 4 байта на служебные данные отделяемого интерфейса. Подобное впечатление базируется на нескольких обманчивых предположениях. Во-первых, затраты на работающий отделяемый интерфейс составляют отнюдь не только 4 байта памяти для его vptr. Отделяемому интерфейсу требуются также обратный указатель и счетчик ссылок. Во-вторых, несмотря на возможность использования специального распределителя памяти (custom memory allocator ), отделяемому интерфейсу потребуется по крайней мере 4 дополнительных байта на выравнивание и/или заполнение заголовков динамически выделенной памяти, используемых С-библиотекой для реализации malloc/operator new . Это означает, что объект действительно экономит 4 байта, когда интерфейс не используется. Но когда интерфейс используется, отделяемый интерфейс тратит как минимум 12 байт, если подключен специальный распределитель памяти, и 16 байт, если, по умолчанию, подключен оператор new. Если интерфейс запрашивается редко, то такая оптимизация имеет смысл, особенно если клиент освобождает этот интерфейс вскоре после получения. Если же клиент хранит отделяемый интерфейс в течение всего времени жизни объекта, то преимущества отделяемого интерфейса теряются.

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

Узнав обо всех подводных камнях отделяемых интерфейсов, задаешь себе логичный вопрос: "В каких же случаях отделяемые интерфейсы являются подходящими?" Не существует безусловного ответа; в то же время отделяемые интерфейсы очень хороши для поддержки большого числа взаимно исключающих интерфейсов. Рассмотрим случай, в котором в дополнение к трем транспортным интерфейсам, показанным ранее, имеются интерфейсы ITruck (грузовик), IMonsterТruck (грузовик-монстр), IMotorcycle (мотоцикл), IBicycle (велосипед), IUnicycle (уницикл), ISkateboard (скейтборд) и IHelicopter (вертолет), причем все они наследуют IVehicle. Если бы производящий транспортный класс хотел поддерживать любой из этих интерфейсов, но только по одному из них для каждого заданного экземпляра, то для осуществления этого отделяемые интерфейсы были бы прекрасным способом при условии, что главный объект кэшировал бы указатель на первый отделяемый интерфейс. Определение класса главного объекта выглядело бы примерно так:

class GenericVehicle : public IUnknown

{

LONG m_cRef;

IVehicle *m_pTearOff;

// cached ptr to tearoff

// кэшированный указатель на отделяемый интерфейс

GenericVehicle(void) : m_cRef(0), m_pTearOff(0) {}

// IUnknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release (void);

// define tearoff classes

// определяем классы отделяемых интерфейсов

class XTruck : public ITruck { … };

class XMonsterTruck : public IMonsterTruck { … };

class XBicycle : public IBicycle { … };

:

:

:

};

В этом классе в случае, когда не используется ни один из интерфейсов, объект платит за пустой кэшированный указатель только четырьмя дополнительными байтами. Когда приходит запрос QueryInterfасе на один из десяти транспортных интерфейсов, то память выделена для нового отделяемого интерфейса один раз и кэширована для более позднего использования:

STDMETHODIMP GenericVehicle::QueryInterface(REFIID riid ,void **ppv)

{ if (riid == IID_IUnknown) *ppv = static_cast(this);

else if (riid == IID_ITruck) { if (m_pTearOff == 0)

// no tearoff yet, make one

// отделяемого интерфейса еще нет, создаем один

m_pTearOff = new XTruck(this);

if (m_pTearOff)

// tearoff exists, let tearoff QI

// отделяемый интерфейс существует, пусть это QI

return m_pTearOff->QueryInterface(riid, ppv);

else

// memory allocation failure

// ошибка выделения памяти

return (*ppv = 0), E_NOINTERFACE;

}

else if (riid == IID_IMonsterTruck)

{

if (in_pTearOff == 0)

// no tearoff yet, make one

// отделяемого интерфейса еще нет, создаем один

m_pTearOff = new XMonsterTruck(this);

if (m_pTearOff)

// tearoff exists, let tearoff QI

// отделяемый интерфейс существует, пусть это QI

return m_pTearOff->QueryInterface(riid, ppv);

else

// memory allocation failure

// ошибка выделения памяти

return (*ppv = 0), E_NOINTERFACE;

}

else …

:

:

:

}

На основе показанной здесь реализации QueryInterface на каждый объект будет приходиться по большей части по одному отделяемому интерфейсу. Это значит, что в случае отсутствия запросов на транспортные интерфейсы объект будет тратить в сумме 12 байт (vptr IUnknown + счетчик ссылок + кэшированный указатель на отделяемый интерфейс). Если транспортный интерфейс запрошен, то объект будет тратить в сумме от 24 до 28 байт (исходные 12 байт + наследующий Vehicle vptr + счетчик ссылок + обратный указатель на главный объект + (необязательно) служебная запись malloc (memory allocation – выделение памяти)).

Если бы в данном случае отделяемые интерфейсы не использовались, то определение класса выглядело бы примерно так:

class GenericVehicle : public ITruck, public IHelicopter, public IBoat, public ICar, public IMonsterTruck, public IBicycle, public IMotorcycle, public ICar, public IPlane, public ISkateboard { LONG m_cRef;

// IUnknown methods – методы IUnknown

:

:

:

};

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

 

Двоичная композиция

Композиция и отделяемые интерфейсы – это две технологии на уровне исходного кода, предназначенные для реализации объектов СОМ на C++. Обе эти технологии требуют, чтобы разработчик объекта имел определения для каждого класса композита или отделяемого интерфейса в исходном коде C++, для возможности обработать подобъект, прежде чем возвратить его посредством QueryInterface. Для ряда ситуаций это очень разумно. В некоторых случаях, однако, было бы удобнее упаковать многократно используемую реализацию одного или большего числа интерфейсов в двоичный компонент, который мог бы обрабатываться через границы DLL, не нуждаясь в исходном коде подкомпонента. Это позволило бы более широкой аудитории повторно использовать подкомпонент, избегая слишком тесной связи с ним, как в случае повторного использования на уровне исходного кода (этот случай описан в главе 1). Однако если компонент повторного использования представляет собой двоичный композит или отделяемый интерфейс, то он должен участвовать в общей идентификации объекта.

Для полного охвата проблем, относящихся к унифицированию идентификации через границы компонентов, рассмотрим следующую простую реализацию ICar:

class Car : public ICar

{

LONG m_cRef; Car(void) : m_cRef(0) {} STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void); STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pn);

STDMETHODIMP Brake(void); };

STDMETHODIMP Car::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast(this);

else if (riid == IID_IVehicle) *ppv = static_cast(this);

else if (riid == IID_ICar) *ppv = static_cast(this);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

// car class object's IClassFactory::CreateInstance

// интерфейс IClassFactory::CreateInstance

// объекта класса car

STDMETHODIMP CarClass::CreateInstance(IUnknown *pUnkOuter, REFIID riid, void **ppv)

{

Car *pCar = new Car;

if (*pCar) return (*ppv = 0), E_OUTOFMEMORY;

pCar->AddRef();

HRESULT hr = pCar->QueryInterface(riid, ppv);

pCar->Release(); return hr;

}

Этот класс просто использует фактические реализации QueryInterface, AddRef и Release.

Рассмотрим второй класс C++, который пытается использовать реализацию Car как двоичный композит:

class CarBoat : public IBoat

{

LONG m_cRef;

Unknown *m_pUnkCar;

CarBoat(void);

virtual ~CarBoat(void);

STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(long *pn);

STDMETHODIMP Sink(void);

};

Для эмуляции композиции разработчику пришлось бы создать подобъект Car, а деструктору – освободить указатель на подобъект:

CarBoat::CarBoat (void) : m_cRef(0)

{

HRESULT hr = CoCreateInstance(CLSID_Car, 0, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkCar);

assert(SUCCEEDED(hr));

}

CarBoat::~CarBoat(void)

{

if (m_pUnkCar) m_pUnkCar->Release();

}

Интересная проблема возникает в реализации QueryInterface:

STDMETHODIMP CarBoat::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast(this);

else if (riid == IID_IVehicle) *ppv = static_cast(this);

else if (riid == IID_IBoat) *ppv = static_cast(this);

else if (riid == IID_ICar)

// forward request…

// переадресовываем запрос…

return m_pUnkCar->QueryInterface(riid, ppv);

else return (*ppv = 0), E_NOINTERFACE; ((IUnknown*)*ppv)->AddRef();

return S_OK;

}

Поскольку объект Car не имеет понятия о том, что он является частью идентификационной единицы (identity) другого объекта, то он будет причиной неуспеха любых запросов QueryInterface для IBoat. Это означает, что

QI(IBoat)->ICar

пройдет успешно, а запрос

QI(QI(IBoat)->ICar)->IBoat

потерпит неудачу, так как полученная QueryInterface будет несимметричной. Вдобавок запросы QueryInterface о IUnknown через интерфейсные указатели ICar и IBoat вернут различные значения, а это означает, что будет идентифицировано два различных объекта. Из подобных нарушений протокола IUnknown следует, что объекты CarBoat попросту не являются действительными объектами СОМ.

Идея составления объекта из двоичных композитов звучит красиво. Действительно, Спецификация СОМ четко и подробно указывает, как реализовать эту идею в стандартной и предсказуемой манере. Технология выставления клиенту двоичного подкомпонента непосредственно через QueryInterface называется СОМ-агрегированием. СОМ-агрегирование является лишь набором правил, определяющих отношения между внешним объектом (агрегирующим) и внутренним (агрегируемым). СОМ-агрегирование – это просто набор правил IUnknown, позволяющих более чем одному двоичному компоненту фигурировать в качестве идентификационной единицы (identity) СОМ.

Агрегирование СОМ несомненно является главной движущей силой для повторного использования в СОМ. Намного проще приписывать объекту значения и использовать его методы в реализации методов других объектов. Только в редких случаях кто-то захочет выставлять интерфейсы другого объекта непосредственно клиенту как часть той же самой идентификационной единицы. Рассмотрим следующий сценарий:

class Handlebar : public IHandlebar { … };

class Wheel : public IWheel {};

class Bicycle : public IBicycle

{

IHandlebar * m_pHandlebar;

IWheel *m_pFrontWheel;

IWheel *m_pBackWheel;

}

Было бы опрометчиво для класса Вicycle объявлять интерфейсы IHandlebar (велосипедный руль) или IWheel (колесо) в собственном методе QueryInterface. QueryInterface зарезервирован для выражения отношений «является» (is-a), а велосипед (bicycle) очевидно не является колесом (wheel) или рулем (handlebar). Если разработчик Bicycle хотел бы обеспечить прямой доступ к этим сторонам объекта, то интерфейс IBicycle должен был бы иметь для этой цели аксессоры определенных свойств:

[object, uuid(753A8A60-A7FF-11d0-8C30-0080C73925BA)] interface IBicycle : IVehicle

{

HRESULT GetHandlebar([out,retval] IHandlebar **pph);

HRESULT GetWheels([out] IWheel **ppwFront, [out] IWheel **ppwBack);

}

Реализация Bicycle могла бы тогда просто возвращать указатели на свои подобъекты:

STDMETHODIMP Bicycle::GetHandlebar(IHandlebar **pph)

{

if (*pph = m_pHandlebar) (*pph)->AddRef();

return S_OK;

}

STDMETHODIMP Bicycle::GetWheels(IWheel **ppwFront, IWheel **ppwBack)

{

if (*ppwFront = m_pFrontWheel) (*ppwFront)->AddRef();

if (*ppwBack = m_pBackWheel) (*ppwBack)->AddRef();

return S_OK;

}

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

Несмотря на этот пример, все же остаются сценарии, где желательно обеспечить реализацию интерфейса, которая могла бы быть внедрена в идентификационную единицу другого объекта. Чтобы осуществить это, в СОМ-агрегировании требуется, чтобы внутренний объект (агрегируемый) уведомлялся во время его создания, что он создается как часть идентификационной единицы другого объекта. Это означает, что создающая функция (creation function), обычно используемая для создания объекта, требует один дополнительный параметр: указатель IUnknown на идентификационную единицу, которой агрегирующий объект должен передать функции в ее методы QueryInterface, AddRef и Release. Покажем определение метода CreateInstance интерфейса IClassFactory:

HRESULT CreateInstance([in] Unknown *pUnkOuter, [in] REFIID riid, [out, iid_is(riid)] void **ppv);

Этот метод (и соответствующие API-функции CoCreateInstanceEx и CoCreateInstance) перегружен с целью поддержки создания автономных (stand-alone ) объектов и агрегатов. Если вызывающий объект передает нулевой указатель и качестве первого параметра CreateInstance (pUnkOuter ), то результирующий объект будет автономной идентификационной единицей самого себя. Если же вызывающий объект передает в качестве первого параметра ненулевой указатель, то результирующий объект будет агрегатом с идентификационной единицей, ссылка на которую содержится в pUnkOuter. В случае агрегации агрегат должен переадресовывать все запросы QueryInterface, AddRef и Release непосредственно и безусловно на pUnkOuter. Это необходимо для обеспечения идентификации объекта.

Имея прототип функции, приведенный выше, класс CarBoat после небольшой модификации будет удовлетворять правилам агрегации:

CarBoat::CarBoat(void) : m_cRef(0)

{

// need to pass identity of self to Create routine

// to notify car object it 1s an aggregate

// нужно передать свою идентификацию подпрограмме

// Create для уведомления объекта car, что он – агрегат

HRESULT hr = CoCreateInstance(CLSID_Car, this, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkCar);

assert(SUCCEEDED(hr));

}

Реализация CarBoat QueryInterface просто переадресовывает запрос ICar внутреннему агрегату:

STDMETHODIMP CarBoat::QueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast(this);

else if (riid == IID_ICar)

// forward request…

// переадресовываем запрос…

return m_pUnkCar->QueryInterface(riid, ppv);

else if (riid == IID_IBoat)

:

:

:

Теоретически это должно работать, так как агрегат будет всегда переадресовывать любые последующие запросы QueryInterface обратно главному объекту, проводя таким образом идентификацию объекта.

В предыдущем сценарии метод CreateInstance класса Car возвращает внешнему объекту указатель интерфейса, наследующего IUnknown. Если бы этот интерфейсный указатель должен был просто делегировать вызовы функций интерфейсу IUnknown внешнего объекта, то невозможно было бы: 1) уведомить агрегат, что он больше не нужен; 2) запросить интерфейсные указатели при выделении их клиентам главного объекта. На деле результатом приведенной выше реализации QueryInterface будет бесконечный цикл, поскольку внешний объект делегирует функции внутреннему, который делегирует их обратно внешнему.

Для решения этой проблемы необходимо сделать так, чтобы начальный интерфейсный указатель, который возвращается внешнему объекту, не делегировал вызовы реализации IUnknown внешнего объекта. Это означает, что объекты, поддерживающие СОМ– агрегирование, должны иметь две реализации IUnknown. Делегирующая, то есть передающая функции, реализация переадресовывает все запросы QueryInterface, AddRef и Release внешней реализации. Это и есть реализация по умолчанию, на которую ссылаются таблицы vtbl всех объектов, и это именно та версия, которую видят внешние клиенты. Объект должен также иметь неделегирующую реализацию IUnknown, которая выставляется только агрегирующему внешнему объекту.

Имеется несколько возможностей обеспечить две различные реализации IUnknown от одного объекта. Самый прямой путь – это использование композиции и элемента данных для реализации неделегирующих методов IUnknown. Ниже показана реализация Car, поддающаяся агрегации:

class Car : public ICar

{

LONG m_cRef;

IUnknown *m_pUnk0uter;

public: Car(IUnknown *pUnk0uter);

// non-delegating IUnknown methods

// неделегирующие методы

IUnknown STDMETHODIMP InternalQueryInterface(REFIID, void **);

STDMETHODIMP (ULONG) InternalAddRef(void);

STDMETHODIMP_(ULONG) InternalRelease(void);

// delegating IUnknown methods

// делегирующие методы IUnknown

STDMETHODIMP QueryInterface(REFIID, void **);

STDMETHODIMP_(ULONG) AddRef(void);

STDMETHODIMP_(ULONG) Release(void);

STDMETHODIMP GetMaxSpeed(*long *pn);

STDMETHODIMP Brake(void);

// composite to map distinguished IUnknown vptr to

// non-delegating InternalXXX routines in main object

// композит для преобразования определенного vptr IUnknown

// в неделегирующие подпрограммы InternalXXX в главном

// объекте

class XNDUnknown : public IUnknown

{ Car* This()

{

return (Car*)((BYTE*)this – offsetof(Car, m_innerUnknown));

}

STDMETHODIMP QueryInterface(REFIID r, void**p)

{

return This()->InternalQueryInterface(r,p);

}

STDMETHODIMP_(ULONG) AddRef(void)

{

return This()->InternalAddRef();

}

STDMETHODIMP_(ULONG) Release(void)

{

return This()->InternalRelease();

}

};

XNDUnknown m_innerUnknown;

// composite instance

// экземпляр композита };

Двоичное размещение этого объекта показано на рис. 4.8. Методы делегирования класса чрезвычайно просты:

STDMETHODIMP Car::QueryInterface(REFIID riid, void **ppv) { return m_pUnkOuter->QueryInterface(riid, ppv); }

STDMETHODIMP_(ULONG) Car::AddRef(void) { return m_pUnkOuter->AddRef(); }

STDMETHODIMP_(ULONG) Car::Release (void) { return m_pUnkOuter->Release(); }

Эти подпрограммы являются версиями, которые будут заполнять таблицы vtbl всех интерфейсов объекта, так что какой бы интерфейс клиент ни получил, методы IUnknown всегда передают функции основной идентификационной единице объекта.

Для того чтобы объект можно было использовать в обоих сценариях – агрегирования и автономном – разработчик объекта должен установить свой элемент данных m_pUnkOuter так, чтобы в случае автономного режима он указывал на собственный неделегирующий IUnknown:

Car::Car(IUnknown *pUnkOuter)

{

if (pUnkOuter)

// delegate to pUnkOuter

// делегируем в pUnkOuter

m_pUnkOuter = pUnkOuter;

else // delegate to non-delegating self

// делегируем неделегирующему себе m_pUnkOuter = &m_innerUnknown;

}

Разработчик обеспечивает то, что в обоих случаях m_pUnkOuter указывает на нужную для данного объекта реализацию QueryInterface, AddRef и Release.

Обычные неделегирующие реализации QueryInterface, AddRef и Release являются вполне правильными и предсказуемыми:

STDMETHODIMP Car::InternalQueryInterface(REFIID riid, void **ppv)

{

if (riid == IID_IUnknown) *ppv = static_cast(&m_innerUnknown);

else if (riid = IID_IVehicle) *ppv = static_cast(this);

else if (riid == IID_ICar) *ppv = static_cast(this);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

STDMETHODIMP_(ULONG) Car::InternalAddRef(void)

{

return InterlockedIncrement(&m_cRef);

}

STDMETHODIMP_(ULONG) Car::InternalRelease(void)

{

ULONG res = InterlockedDecrement(&m_cRef);

if (res == 0) delete this;

return res;

}

Единственной отличительной особенностью этих трех методов (кроме их имен) является то, что InternalQueryInterface при запросе IUnknown возвращает указатель на неделегирующую Unknown. Это просто требование Спецификации СОМ, которого следует придерживаться.

И наконец, подпрограмму создания Car требуется модифицировать для поддержки агрегирования:

STDMETHODIMP CarClass::CreateInstance(IUnknown *punk0uter, REFIID riid, void **ppv)

{

// verify that aggregator only requests IUnknown as

// initial interface

// проверяем, что агрегатор только запрашивает IUnknown как

// начальный интерфейс

if (pUnkOuter != 0 && riid != IID_IUnknown)

return (*ppv = 0), E_INVALIDARG;

// create new object/aggregate

// создаем новый объект или агрегат Car

*р = new Car(pUnkOuter);

if (!p) return (*ppv = 0), E_OUTOFMEMORY;

// return resultant pointer

// возвращаем результирующий указатель

p->InternalAddRef();

HRESULT hr = p->InternalQueryInterface(riid, ppv);

p->InternalRelease();

return hr;

}

Отметим, что здесь используются неделегирующие версии QueryInterface, AddRef и Release. Если создается автономная идентификационная единица, то это, конечно, допустимо. Если же создается агрегат, то необходимо убедиться, что AddRef обработал внутренний, а не внешний объект. Отметим также, что внешний объект в качестве начального интерфейса должен запросить IUnknown. Все это регламентировано Спецификацией СОМ. Если бы внешний объект мог запрашивать произвольный начальный интерфейс, то внутреннему объекту пришлось бы хранить два дублирующих набора указателей vptr: один набор делегировал бы свои реализации QueryInterface, AddRef и Release, а другой – нет. При допущении в качестве начального интерфейса одного IUnknown разработчик объекта может выделить только один vptr, который будет действовать как неделегирующий IUnknown.

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

Еще одна проблема при программировании агрегирования может возникнуть, когда необходимо связать между собой внутренний и внешний объекты. Для того чтобы организовать связь внутреннего объекта с внешним, нужно вызвать QueryInterface посредством управляющего IUnknown. Однако этот запрос QueryInterface вызовет AddRef через результирующий указатель, который имеет обыкновение без спросу обрабатывать внешний объект с помощью AddRef. Если бы внутренний объект хранил этот указатель в качестве элемента данных, то возник бы цикл, поскольку внутренний объект уже неявно обработал внешний объект с помощью AddRef. Это означает, что внутренний объект должен избрать одну из двух стратегий. Внутренний объект может получать и освобождать указатель по потребности, храня его ровно столько времени, сколько это необходимо:

STDMETHODIMP Inner::MethodX(void)

{

ITruck *pTruck = 0;

// outer object will be AddRefed after this call…

// после этого вызова внешний объект будет обработан

// с помощью AddRef…

HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&pTruck);

if (SUCCEEDED(hr))

{

pTruck->ShiftGears();

pTruck->HaulDirt();

// release reference to outer object

// освобождаем ссылку на внешний объект pTruck->Release();

}

}

Второй способ заключается в том, чтобы получить указатель один раз во время инициализации и освободить соответствующий внешний объект немедленно после получения.

HRESULT Inner::Initialize(void)

{

// outer object will be AddRefed after this call…

// после этого вызова внешний объект будет обработан

// с помощью AddRef…

HRESULT hr = m_pUnkOuter->QueryInterface(IID_ITruck, (void**)&m_pTruck);

// release reference to outer object here and DO NOT

// release it later in the object's destructor

// освобождаем здесь ссылку на внешний объект и

// НЕ ОСВОБОЖДАЕМ ее потом в деструкторе объекта

if (SUCCEEDED(hr)) m_pTruck->Release();

}

Этот способ работает, поскольку время жизни внутреннего объекта является точным подмножеством времени жизни внешнего объекта. Это означает, что m_pTruck будет теоретически всегда указывать на существующий объект. Конечно, если внешний объект реализовал ITruck как отделяемый интерфейс, то все предыдущее неверно, так как вызов Release уничтожит этот отделяемый интерфейс.

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

Outer::Outer(void)

{

++m_cRef;

// protect against delete this

// защищаем против удаления this

CoCreateInstance(CLSID_Inner, this, CLSCTX_ALL, IID_IUnknown, (void**)&m_pUnkInner);

–m_cRef;

// allow delete this

// позволяем удалить this }

Данная методика стабилизации предотвращает преждевременное разрушение, когда внутренний объект освобождает указатели, которые он, быть может, получил в свой код инициализации. Эта методика настолько общепринята, что большинство СОМ-оболочек программирования включают в себя явный метод перекрытия (overridable), который работает внутри области действия пары инкремент/декремент. В MFC (Microsoft Foundation Classes – библиотека базовых классов Microsoft) этот метод называется CreateAggregates, в ATL – FinalConstruct.

Поскольку показанные выше методики реализации агрегируемого объекта не требуют никаких дополнительных базовых классов, кроме классов C++, то альтернативная форма макроса IMPLEMENT_UNKNOWN может прозрачно реализовать раздвоенную реализацию IUnknown. Определение исходного класса:

class Car : public ICar

{

Car(void);

IMPLEMENT_UNKNOWN(Car)

BEGIN_INTERFACE_TABLE(Car)

IMPLEMENTS_INTERFACE(ICar)

IMPLEMENTS_INTERFACE(IVehicle)

END_INTERFACE()

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pn);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

};

просто переводится в следующее:

class Car : public ICar

{

Car(void);

//indicate that aggregation is required

// показываем, что требуется агрегирование

IMPLEMENT_AGGREGATABLE_UNKNOWN(Car)

BEGIN_INTERFACE_TABLE(Car)

IMPLEMENTS_INTERFACE(ICar)

IMPLEMENTS_INTERFACE(IVehicle)

END_INTERFACE()

// IVehicle methods

// методы IVehicle

STDMETHODIMP GetMaxSpeed(long *pn);

// ICar methods

// методы ICar

STDMETHODIMP Brake(void);

};

Встроенное расширение макроса IMPLEMENT_AGGREGATABLE_UNKNOWN включено в код, приложенный к этой книге.

 

Включение

Не все классы способны к агрегированию. Для того чтобы выставить неагрегируемые классы как часть индивидуальности другого объекта, необходимо, чтобы внешние объекты явно передавали вызовы методов внутренним объектам. Эта технология СОМ часто называется включением (containment).

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

 

Где мы находимся?

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

 

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

 

Снова интерфейс и реализация

Некоторые разработчики всесторонне используют многопоточные программные технологии и способны написать удивительно изощренный программный продукт с использованием примитивов синхронизации потоков, доступных из операционной системы. Другие разработчики больше сконцентрированы на решении вопросов, специфических для их области, и не утруждают себя написанием нудного потоко-безопасного кода. Третьи разработчики имеют особые ограничения по организации потоков, связанные с тем, что многие системы с управлением окнами (включая Windows) имеют очень строгие правила взаимодействия потоков и оконных примитивов. Еще один класс разработчиков может широко использовать старую библиотеку классов, которая неприязненно относится к потокам и не может допустить какого бы то ни было многопоточного обращения. У всех четырех типов разработчиков должна быть возможность использования объектов друг друга без перестраивания их потоковой стратегии, чтобы приспособиться ко всем возможным сценариям. Чтобы облегчить прозрачное использование объекта безотносительно к его осведомленности о потоках, СОМ рассматривает ограничения на параллелизм объектов как еще одну деталь реализации, о которой клиенту не нужно беспокоиться. Чтобы освободить клиента от ограничений параллелизма и реентерабельности (повторной входимости), в СОМ имеется весьма формальная абстракция, которая моделирует связь объектов с процессами и потоками. Эта абстракция носит название апартамент (apartment) . Апартаменты определяют логическое группирование объектов, имеющих общий набор ограничений по параллелизму и реентерабельности. Каждый объект СОМ принадлежит к ровно одному апартаменту: один апартамент, однако, может быть общим для многих объектов. Апартамент, к которому относится объект, безоговорочно является частью идентификационной уникальности объекта.

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

Поток одновременно выполняется в одном и только одном апартаменте. Для того чтобы поток мог использовать СОМ, он должен сначала войти в апартамент. Когда поток входит в апартамент, СОМ размещает информацию об апартаменте в локальной записи потока (TLS – thread local storage), и эта информация связана с потоком до тех пор, пока поток не покинет апартамент. СОМ обеспечивает доступ к объектам только для тех потоков, которые выполняются в апартаменте данного объекта. Это означает, что если поток выполняется в том же процессе, что и объект, то потоку может быть запрещено обращаться к объекту, даже если память, которую занимает объект, полностью видима и доступна. В СОМ определен HRESULT (RPC_E_WRONG_THREAD), который возвращают некоторые системные объекты при прямом обращении из других апартаментов. Объекты, определенные пользователем, также могут возвращать этот HRESULT; однако лишь немногие разработчики желают пройти столь долгий путь для обеспечения правильного использования своих объектов.

В версии СОМ под Windows NT 4.0 определяется два типа апартаментов: многопоточные апартаменты (МТА – multithreaded apartments) и однопоточные апартаменты (STA – singlethreaded apartments). В каждом процессе может быть не больше одного МТА; однако процесс может содержать несколько STA. Как следует из этих названий, в МТА может выполняться одновременно несколько потоков, а в STA – только один поток. Точнее, только один поток может когда-либо выполняться в данном STA; что означает не только то, что к объектам, находящимся в STA, никогда нельзя будет обратиться одновременно, но также и то, что только один определенный поток может когда-либо выполнять методы объекта. Эта привязка (affinity) к потоку позволяет разработчикам объекта надежно сохранять промежуточное состояние между вызовами метода в локальной памяти потока TLS (thread local storage), а также сохранять блокировки (locks), требующие поточной привязки (например, критические секции Win32 и семафоры (mutexes)).

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

В будущей реализации СОМ будет, возможно, введен третий тип апартамента – апартамент, арендованный потоками (RTA – rentalthreaded apartment). Подобно МТА, RTA позволяет входить в апартамент более чем одному потоку. Но, в отличие от МТА , когда поток входит в RTA, он вызывает блокировку всего апартамента (apartment-wide lock) (то есть он как бы арендует апартамент), которая запрещает другим потокам одновременно входить в апартамент. Эта блокировка апартамента снимается, когда поток покидает RTA , что позволяет войти следующему потоку. В этом отношении RTA подобен МТА , за исключением того, что все вызовы методов осуществляются последовательно. Это обстоятельство делает RTA значительно удобнее для классов, относительно которых неизвестно, являются ли они потокобезопасными. Хотя все вызовы в STA также осуществляются сериями, объекты на основе RTA отличаются тем, что в них нет привязки потоков; то есть внутри RTA могут выполняться любые потоки, а не только тот исходный поток, который создал апартамент. Эта свобода от привязки к потоку делает объекты на базе RTA более гибкими и эффективными, чем объекты на основе STA, так как любой поток потенциально может сделать вызов объекта, просто войдя в RTA объекта. На момент написания этого текста еще окончательно не определились детали создания апартаментов RTA и входа в них. За подробностями вы можете обратиться к документации по SDK .

Когда поток впервые создается операционной системой как результат вызова CreateProcess или CreateThread, этому новообразованному потоку не сопоставлен ни один апартамент. Перед тем как использовать СОМ, новый поток должен войти в какой-либо апартамент путем вызова одной из приведенных далее API-функций.

В Windows NT 5.0 это будет изменено. За подробностями обращайтесь к документации по SDK.

HRESULT CoinitializeEx(void *pvReserved, DWORD dwFlags);

HRESULT Coinitialize(void *pvReserved);

HRESULT OleInitialize(vo1d *pvReserved);

Для всех трех только что описанных API-функций первый параметр зарезервирован и должен равняться нулю.

CoInitializeEx является API-функцией самого низкого уровня и позволяет вызывающему объекту определять, в какой тип апартамента нужно войти. Для того чтобы войти в МТА всего процесса, вызывающий объект должен использовать флаг COINIT_MULTITHREADED:

HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);

Для входа во вновь соаданный STA вызывающий объект должен выставить флаг COINIT_APARTMENTTHREADED:

HRESULT hr = CoInitializeEx(0, COINIT_APARTMENTTHREADED);

Каждый поток в процессе, который вызывает CoInitializeEx с применением COINIT_MULTITHREADED, выполняется в том же самом апартаменте. Каждый поток, который вызывает CoInitiаlizeEx с применением COINIT_APARTMENTTHREADED, выполняется в отдельном апартаменте, в который не могут входить никакие другие потоки. CoInitialize – это традиционная подпрограмма, которая просто вызывает CoInitializeEx с флагом COINIT_APARTMENTTHREADED. Olelnitialize сначала вызывает CoInitialize, а затем инициализирует несколько подсистем из OLE-приложений, таких как OLE Drag and Drop и OLE Clipboard. Если не предполагается использовать эти службы более высокого уровня, то в общем случае предпочтительнее использовать CoInitialize или CoInitializeEx.

Каждая из этих трех API-функций может быть вызвана больше одного раза на поток. Первый вызов каждого потока возвратит S_ОК. Последующие вызовы просто повторно войдут в тот же апартамент и возвратят S_FALSE. На каждый успешный вызов CoInitialize или CoInitializeEx из того же потока нужно вызвать CoUninitialize. На каждый успешный вызов OleInitialize из того же потока нужно вызвать OleUninitialize. Эти подпрограммы деинициализации (uninitialization) имеют очень простые сигнатуры:

void CoUninitialize(void);

void OleUninitialize(void);

Если все эти подпрограммы перед прекращением потока или процесса не вызваны, это может задержать восстановление ресурсов. Когда поток входит в апартамент, недопустимо изменять типы апартамента с использованием CoInitiаlizeEx. При попытках сделать это HRESULT будет содержать RPC_E_CHANGED_MODE. Однако, если поток полностью покинул апартамент посредством CoUninitialize, он может войти в другой апартамент путем повторного вызова CoInitializeEx.

 

Объекты, интерфейсы и апартаменты

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

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

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

Разработчики объектов выбирают типы апартаментов, в которых могут выполняться их объекты. В главе 6 будет рассмотрено, что внепроцессные серверы явно задают тип своих апартаментов посредством вызова CoInitializeEx с соответствующим параметром. Для внутрипроцессных серверов необходим другой подход, так как CoInitializeEx уже вызывалась клиентом во время создания объекта. Для того чтобы внутрипроцессные серверы могли контролировать тип своих апартаментов, в СОМ каждому CLSID разрешается задавать свою собственную потоковую модель (threading model), которая объявляется в локальном реестре с использованием переменной под названием ThreadingModel:

[HKCR\CLSID\ {96556310-D779-11d0-8C4F-0080C73925BA}\InprocServer32]

@="C:\racer.dll"

ThreadingModel="Free"

Каждый CLSID в DLL может иметь индивидуальную ThreadingModel. Под Windows NT 4.0 СОМ допускает четыре возможных значения ThreadingModel для CLSID . Значение ThreadingModel="Both" указывает на то, что класс может выполняться как в МТА, так и в STA. Значение ThreadingModel="Free" указывает, что класс может выполняться только в МТА. Значение ThreadingModel="Apartment" указывает, что класс может выполняться только в STA. Отсутствие ThreadingModel означает, что класс может выполняться только в главном STA. Главный STA определяется как первый STA, который должен быть инициализирован в процессе.

Если апартамент клиента совместим с моделью организации поточной обработки идентификатора класса CLSID , то все запросы на внутрипроцессную активацию для этого CLSID будут обрабатывать объект непосредственно в апартаменте клиента. Это, безусловно, наиболее эффективный сценарий, так как не требуется никаких промежуточных заместителей. Если же апартамент клиента несовместим с моделью организации поточной обработки, указанной в CLSID, то запросы на внутрипроцесспую активацию для таких CLSID будут приводить к скрытому созданию объекта в отдельном апартаменте, а клиенту будет возвращен заместитель. В случае, когда STA -клиенты активируют классы с ThreadingModel="Free", объект класса (и последующие его экземпляры) будут выполняться в МТА. В случае, когда MTA–клиенты активируют классы с ThreadingModel="Apartment", объект класса (и последующие его экземпляры) будут выполняться в STA , созданном СОМ. В случае, когда клиенты любого типа активируют классы на основе главного STA, объект класса (и последующие его экземпляры) будут выполняться в главном STA процесса. Если же клиент окажется потоком главного STA, то будет осуществлен прямой доступ к объекту. В противном случае клиенту будет возвращен заместитель. Если в процессе нет ни одного STA (то есть если ни один поток не вызвал CoInitiаlizeEx с флагом COINIT_APARTMENTTHREADED), тогда СОМ создаст новый STA с тем, чтобы он стал главным STA для процесса.

Разработчики классов, не предусматривающие модель организации поточной обработки для своих классов, могут большей частью игнорировать проблемы, связанные с потоками, так как доступ к их библиотекам DLL будет осуществляться только из одного потока, а именно из главного STA–потока. Те разработчики, которые предусматривают для своих классов поддержку любой явной модели организации поточной обработки, косвенно свидетельствуют, что каждый из множественных апартаментов в процессе (который может быть многопоточным) может содержать экземпляры класса. Поэтому разработчик должен защитить любые ресурсы, которые совместно используются более чем одним экземпляром класса, от параллельного доступа. Это означает, что все глобальные и статические переменные должны быть защищены с помощью соответствующего примитива синхронизации потоков. Для внутрипроцессного сервера СОМ глобальный счетчик блокировок, отслеживающий время жизни сервера, должен быть защищен с помощью InterlockedIncrement / InterlockedDecrement, как показано в главе 3. Любое другое специфическое для сервера состояние также должно быть защищено.

Разработчики, обозначающие свои классы ThreadingModel= «Apartment», указывают на то, что экземпляры этих классов могут быть доступны только из одного потока в течение всей жизни объекта. Следонательно, нет необходимости защищать режим экземпляра, а нужно защищать только режим, общий для нескольких экземпляров класса, о чем упоминалось ранее. Разработчики, обозначающие свои классы ThreadingModel="Free" или ThreadingModel="Both" устанавливают для экземпляров своего класса режим работы в МТА, что означает, что единовременно возможен доступ только к одному экземпляру класса. Поэтому разработчики должны защищать все ресурсы, используемые одним экземпляром, от параллельного доступа. Это относится не только к общим статическим переменным, но также к элементам данных экземпляра. Для объектов, расположенных в динамически распределяемой области памяти, это означает, что элемент данных, отвечающий за счетчик ссылок, должен быть защищён с помощью InterlockedIncrement/InterlockedDecrement, как было показано в главе 2. Любое другое состояние экземпляра класса также должно быть защищено.

На первый взгляд, совершенно не понятно, зачем существует ThreadingModel="Free", поскольку требования для работы в МТА выглядят как расширенный набор требований соответствия STA. Если разработчик объекта планирует рабочие потоки, которым необходим доступ к объекту, то очень полезно предотвратить создание объекта в каком-либо STA. Дело в том, что рабочие потоки не могут входить в STA, где живет объект, и поэтому вынуждены работать в другом апартаменте. Если класс обозначен ThreadingModel="Both" и запрос на активацию исходит от STA -потока, то объект будет существовать в STA. Это означает, что рабочие потоки (которые будут работать в МТА) должны обращаться к объекту через межапартаментные вызовы методов, значительно менее эффективные, нежели внутриапартаментные вызовы. Тем не менее, если класс помечен как ThreadingModel="Free", то любые запросы на активацию со стороны STA вызовут создание нового экземпляра в МТА, где любые рабочие потоки смогут иметь прямой доступ к объекту. Это означает, что при вызове клиентом, размещенным в STA, методов такого объекта, эффективность будет сниженной, в то время как рабочие потоки будут обрабатываться с большей эффективностью. Это является приемлемым компромиссом, если рабочие потоки будут обращаться к объекту чаще, чем действующий клиент из STA. Было бы весьма соблазнительно смягчить правила СОМ и записать, что не будет ошибкой прямо обращаться к некоторым объектам из более чем одного апартамента. Однако в общем случае это неверно, особенно для объектов, которые используют другие объекты для своей работы.

 

Межапартаментный доступ

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

По умолчанию удаленный вызов метода использует имеющийся в СОМ протокол передачи ORPC (Object Remote Procedure Call – вызов объектом удаленной процедуры). СОМ ORPC является упрощенным протоколом MS-RPC (протокол вызова удаленной процедуры Microsoft), производным от DCE (Distributed Computing Environment – распределенная вычислительная среда). MS-RPC является независимым от протокола механизмом связи, который можно расширять с целью поддержки новых транспортных протоколов (посредством динамически загружаемых транспортных DLL) и новых пакетов аутентификации (посредством динамически загружаемых библиотек поставщика поддержки безопасности Security Support Provider DLL ). СОМ использует наиболее эффективный на доступных транспортных протоколов в зависимости от подобия и типов импортирующего и экспортирующего апартаментов. При связи вне хост-машины СОМ предпочитает UDP (User Datagram Protocol – протокол передачи дейтаграмм пользователя), хотя и поддерживает большинство общеупотребительных сетевых протоколов. При локальной связи СОМ использует один из нескольких транспортных протоколов, каждый из которых оптимален для определенного типа апартаментов.

СОМ осуществляет передачу интерфейсных указателей через границы апартаментов с помощью особой технологии, именуемой маршалингом (marshaling), тo есть расположением в определенном порядке, выстраиванием. Маршалинг интерфейсного указателя – это преобразование его в передающийся байтовый поток, содержимое которого единственным образом идентифицирует объект и его собственный апартамент. Этот байтовый поток является маршалированным состоянием (marshaled state) интерфейсного указателя и дает возможность любому апартаменту импортировать интерфейсный указатель и осуществлять вызовы метода на объект. Отметим, что поскольку СОМ имеет дело исключительно с интерфейсными указателями, а не с самими объектами, это состояние маршалинга не представляет собой состояние объекта, а скорее преобразованное в последовательную форму (serialized) состояние не зависящей от апартаментов ссылки на объект. Такие маршалированные объектные ссылки просто содержат информацию об установлении связи, которая совершенно не зависит от состояния объекта.

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

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

typedef enum tagMSHCTX

{

MSHCTX_INPROC = 4,

// in-process/same host

// внутрипроцессный/тот же хост

MSHCTX_LOCAL = 0,

// out-of-process/same host

// внепроцессный/тот же хост

MSHCTX_NOSHAREDMEM = 1,

// 16/32 bit/same host

// 16/32-битный/тот же хост

MSHCTX_DIFFERENTMACHINE = 2

// off-host

// внехостовый

} MSHCTX;

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

typedef enum tagMSHLFLAGS

{

MSHLFLAGS_NORMAL,

// marshal once, unmarshal once

// маршалируем один раз, демаршалируем один раз

MSHLFLAGS_TABLESTRONG,

// marshal опсе, unmarshal many

// маршалируем один раз. демаршалируем много раз

MSHLFLAGS_TABLEWEAK,

// marshal once, unmarshal many

// маршалируем один раз, демаршалируем много раз

MSHLFLAGS_NOPING = 4,

// suppress dist. garbage collection

// подавляем ненужный набор дистанций

} MSHLFLAGS;

Нормальный (normal) маршалинг, иногда его называют еще маршалингом вызовов (call marshaling), означает, что маршалированная объектная ссылка должна быть демаршалирована только один раз, а если нужны дополнительные заместители, то требуются дополнительные вызовы CoMarshalInterface. Табличный (table) маршалинг означает, что маршалированная объектная ссылка может быть демаршалирована нуль и более раз без требования дополнительных вызовов CoMarshalInterface. Подробности табличного маршалинга будут описаны далее в этой главе.

Чтобы разрешить маршалинг интерфейсных указателей на различные носители, функция CoMarshalInterface преобразует интерфейсный указатель в последовательную форму через интерфейс типа IStream , предоставляемый вызывающим объектом. Интерфейс IStream моделирует произвольное устройство ввода-вывода и выставляет методы Read и Write . Функция CoMarshalInterface просто вызывает метод Write на предоставленный вызывающим объектом интерфейс типа IStream , не интересуясь тем, куда эти фактические байты будут записаны. Вызывающие объекты могут получить обертку IStream на необработанную (raw ) память, вызвав API-функцию CreateStreamOnHGlobal :

HRESULT CreateStreamOnHGlobal(

[in] HGLOBAL hglobal,

// pass null to autoalloc

// передаем нуль для автовыдепения памяти

[in] BOOL bFreeMemoryOnRelease,

[out] IStream **ppStm);

С использованием семантики IStream следующий фрагмент кода:

void UseRawMemoryToPrintString(void)

{

void *pv = 0;

// alloc memory

// выделяем память

pv = malloc(13);

if (pv != 0) {

// write a string to the underlying memory

// пишем строку в основную память

memcpy(pv, «Hello, World», 13);

printf((const char*)pv);

// free all resources

// освобождаем все ресурсы free (pv);

}

}

эквивалентен такому фрагменту кода, использующему интерфейс IStream вместо memcpy:

void UseStreamToPrintString(void)

{

IStream *pStm = 0;

// alloc memory and wrap behind an IStream interface

// выделяем память и затем заворачиваем ее в интерфейс

IStream HRESULT hr = CreateStreamOnHGlobal(0, TRUE, &pStm);

if (SUCCEEDED(hr)) {

// write a string to the underlying memory

// записываем строку в память

hr = pStm->Write(«Hello. World», 13, 0);

assert (SUCCEEDED (hr));

// suck out the memory

// извлекаем память

HGLOBAL hglobal = 0;

hr == GetHglobalFromStream(pStm, &hglobal);

assert(SUCCEEDED(hr));

printf((const char*)GlobalLock(hglobal));

// free all resources

// освобождаем все ресурсы

GlobalUnlock(hglobal); pStm->Release();

}

}

API-функция GetHGlobalFromStream позволяет вызывающему объекту получать дескриптор (handle ) памяти, выделенной функцией CreateStreamOnHGlobal. Использование HGLOBAL сложилось исторически и никоим образом не означает использование разделяемой памяти.

После осмысления всех типов параметров API-функции CoMarshalInterface она выглядит достаточно просто:

HRESULT CoMarshalInterface(

[in] IStream *pStm,

// where to write marshaled state

// куда записывать маршалированное состояние

[in] REFIID riid, // type of ptr being marshaled

// тип маршалируемого указателя

[in, iid_is(riid)] IUnknown *pItf,

// pointer being marshaled

// маршалируемый указатепь

[in] DWORD dwDestCtx,

// MSHCTX for destination apt.

// MSHCTX для апартамента адресата

[in] void *pvDestCtx,

// reserved, must be zero

// зарезервирован, должен равняться нулю

[in] DWORD dwMshlFlags

// normal, vs. table marshal

// нормальный маршалинг против табличного

);

Следующий код маршалирует интерфейсный указатель в блок памяти, пригодный для передачи по сети в любой апартамент:

HRESULT WritePtr(IRacer *pRacer, HGLOBAL& rhglobal)

{ IStream *pStm = 0; гhglobal = 0;

// alloc and wrap block of memory

// выделяем и заворачиваем блок памяти

HRESULT hr = CreateStreamOnHGlobal(0, FALSE, &pStm);

if (SUCCEEDED(hr)) {

// write marshaled object reference to memory

// записываем в память маршалированную объектную ссылку

hr = CoMarshalInterface(pStm, IID_Iracer, pRacer, MSHCTX_DIFFERENTMACHINE, 0, MSHLFLAGS_NORMAL);

// extract handle to underlying memory

// извлекаем дескриптор памяти

if (SUCCEEDED(hr)) hr = GetHGlobalFromStream(pStm, &rhglobal);

pStm->Release();

}

return hr;

}

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

Для того чтобы декодировать маршалированную объектную ссылку, созданную в предыдущем фрагменте кода, в нормальный интерфейсный указатель, импортирующему апартаменту необходимо вызвать API-функцию CoUnmarshalInterface :

HRESULT CoUnmarshalInterface(

[in] IStream *pStm,

// where to read marshaled state

// откуда читать маршалированное состояние

[in] REFIID riid, // type of ptr being unmaгshaled

// тип демаршалируемого указателя

[out, iid_is(riid)] void **ppv

// where to put unmarshaled ptr

// куда поместить демаршалированный указатель

);

CoUnmarshalInterface просто читает преобразованную в последовательную форму объектную ссылку и возвращает указатель на исходный объект, к которому есть легальный доступ в апартаменте вызывающего потока. Если импортирующий апартамент отличается от того апартамента, который изначально экспортировал интерфейс, то результирующий указатель будет указателем на заместитель. Если по какой-то причине вызов CoUnmarshalInterface осуществлен из исходного апартамента, где располагается объект, то в этом случае будет возвращен указатель на сам объект и не будет создано никакого заместителя. Следующий код переводит маршалированную объектную ссылку в нормальный указатель интерфейса:

HRESULT ReadPtr(HGLOBAL hglobal, IRacer * &rpRacer) {

IStream *pStm = 0; rpRacer = 0;

// wrap block of existing memory passed on input

// заключаем в оболочку блок существующей памяти,

// переданный на вход

HRESULT hr = CreateStreamOnHGlobal(hglobal, FALSE, &pStm);

if (SUCCEEDED(hr)) {

// get a pointer to the object that is legal in this apt.

// получаем указатель на объект, легальный в этом апартаменте

hr = CoUnmarshalInterface(pStm, IID_Iracer, (void**)&rpRacer);

pStm->Release();

}

return hr;

}

Результирующий заместитель будет реализовывать каждый из экспортируемых объектом интерфейсов путем переадресации запросов методов в апартамент объекта.

До появления выпуска СОМ под Windows NT 4.0 формат маршалированной объектной ссылки не был документирован. Для того чтобы позволить сторонним участникам создавать сетевые продукты, совместимые с СОМ, этот формат был документирован для открытого использования в 1996 году и представлен на рассмотрение как проект стандарта для Интернета. На рис. 5.2 показан формат маршалированной объектной ссылки. Заголовок маршалированной объектной ссылки начинается с изысканной сигнатуры «MEOW» (мяу), а поле флагов указывает на выбранную технологию маршалинга (например, стандартный (standard), специальный (custom)), а также IID интерфейса, содержащегося в ссылке. В случае стандартного маршалинга подзаголовок объектной ссылки показывает, сколько внешних ссылок представляет данная маршалированная ссылка.

Этот счетчик внешних ссылок является частью распределенного протокола «сборки мусора» (garbage collection) СОМ и не полностью совпадает со счетчиком ссылок AddRef/Release, который может быть реализован объектом. Интересным элементом объектной ссылки является кортеж (tuple) OXID/OID/IPID, который единственным образом идентифицируют интерфейсный указатель. Каждому апартаменту в сети во время его создания присваивается уникальный Идентификатор Экспортера Объектов (Object Exporter Identifier – OXID). Этот OXID используется для нахождения сетевой или IPC -адресной информации при первом соединении заместителя с объектом. Идентификатор Объекта (Object Identifier – OID) единственным образом определяет идентификационную единицу СОМ в сети и использует CoUnmarshalInterface для поддержания правил идентификации СОМ для заместителей. Идентификатор Интерфейсного Указателя (Interface Pointer Identifier – IPID) единственным образом определяет интерфейсный указатель в апартаменте и помещается в заголовок каждого последующего запроса метода. IPID используется для эффективной диспетчеризации запросов ORPC на нужный интерфейсный указатель в апартаменте объекта.

Хотя OXID представляют интерес как логические идентификаторы, сами по себе они бесполезны, так как заместителям нужен какой-нибудь механизм IРС или сетевой протокол для связи с апартаментом объекта. Для перевода OXID в полностью квалифицированные адреса сети или IPC в каждой хост-машине, поддерживающей СОМ, существует специальная служба распознавателя OXID (OXID Resolver – OR). Под Windows NT 4.0 OR является частью службы RPCSS. Когда апартамент инициализируется впервые, СОМ назначает OXID и регистрирует его с помощью локального OR. Это означает, что каждый OR знает обо всех работающих апартаментах локальной системы. Кроме того, OR следит за каналом локального IPC-порта для каждого апартамента. Когда CoUnmarshalInterface требуется соединить новый заместитель с апартаментом объекта, то для преобразования OXID в действительный адрес сети или IРС используется локальный OR. Если демаршалированный указатель встречается на той же машине, где находится апартамент объекта, то OR просто ищет OXID в своей локальной OXID -таблице и возвращает локальный IPC-адрес. Если же демаршалированный указатель встречается не на той машине, на которой находится объект, то локальный OR сначала проверяет, встречался ли данный OXID ранее, для чего смотрит в специальном кэше, где хранятся недавно распознанные OXID удаленного доступа. Если OXID ранее не встречался, то он передает запрос OR на хост-машину объекта, используя RPC. Отметим, что маршалированная объектная ссылка содержит адрес хост-машины объекта в формате, подходящем для целого ряда сетевых протоколов, так что OR с демаршалированной стороны знает, куда направлять запрос.

Чтобы распознавать распределенные OXID, служба OR на каждой хост-машине ждет удаленные запросы на распознавание OXID на известном адресе (порт 135 для TCP и UDP) для каждого поддерживаемого сетевого протокола. Когда запрос на распознавание OXID получен из сети, опрашивается локальная таблица OXID. Запрос на распознавание покажет, какие сетевые протоколы поддерживает машина клиента. Если запрошенный процесс из апартамента еще не начал использовать один из запрошенных протоколов, то OR свяжется с СОМ-библиотекой в апартаменте объекта, используя локальный IРС, и инициирует использование запрошенного протокола в процессе объекта. Как только это произойдет, OR занесет новый сетевой адрес апартамента в локальную таблицу OXID. После записи новый сетевой адрес возвращается к OR демаршалирующей стороны, где он кэшируется, чтобы предотвратить дополнительные сетевые запросы на часто используемые апартаменты. Может показаться странным, что контрольное считывание полностью квалифицированных сетевых адресов в ссылке маршалировапного объекта не выполняется сразу. Но уровень косвенности, который допускают не зависящие от протокола идентификаторы апартаментов (OXID), разрешает процессу на основе СОМ откладывать использование сетевых протоколов до тех пор, пока они не потребуются. Это особенно важно, поскольку СОМ может иметь дело с множеством различных протоколов (не только TCP), и требовать от каждого процесса слежения за запросами с использованием всех поддерживаемых протоколов было бы чрезвычайно неэффективно. Фактически, если СОМ-процесс никогда не экспортирует указатели внехостовым клиентам, он никогда не потратит вообще никаких сетевых ресурсов.

 

Вспомогательные средства для внутрипроцессного маршалинга

Хотя фрагменты кода для WritePtr и ReadPtr из предыдущего раздела достаточно просто реализовать, большинство явных вызовов CoMarshalInterface будут использоваться для передачи интерфейсного указателя от одного потока к другому в том же самом процессе. Для упрощения этой задачи в СОМ предусмотрены две оберточные функции (wrapper functions), которые реализуют нужный стандартный код вокруг CoMarshalInterface и CoUnmarshalInterface. API-функция СОМ CoMarshalInterThreadInterfaceInStream

HRESULT CoMarshalInterThreadInterfaceInStream( [in] REFIID riid, [in, iid_is(riid)] IUnknown *pItf, [out] IStream **ppStm );

обеспечивает простую обертку вокруг CreateStreamOnHGlobal и CoMarshalInterface, как показано ниже:

// from OLE32.DLL (approx.)

// из OLE32.DLL (приблизительно)

HRESULT CoMarshalInterThreadInterfaceInStream( REFIID riid, IUnknown *pItf, IStream **ppStm) {

HRESULT hr = CreateStreamOnHGlobal(0, TRUE, ppStm);

if (SUCCEEDED(hr))

hr = CoMarshalInterface(*ppStm, riid, pItf, MSHCTX_INPROC, 0, MSHLFLAGS_NORMAL);

return hr;

}

В СОМ предусмотрена также обертка вокруг CoUnmarshalInterface:

HRESULT CoGetInterfaceAndReleaseStream( [in] IStream *pStm, [in] REFIID riid, [out, iid_is(riid)] void **ppv );

которая является очень тонкой оберткой вокруг CoUnmarshalInterface:

// from OLE32.DLL (approx.)

// из OLE32.DLL (приблизительно)

HRESULT CoGetInterfaceAndReleaseStream( IStream *pStm, REFIID riid, void **ppv)

{

HRESULT hr = CoUnmarshalInterface(pStm, riid, ppv);

pStm->Release();

return hr;

}

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

Следующий фрагмент кода мог бы быть применен для передачи интерфейсного указателя в другой апартамент того же процесса с использованием глобальной переменной для хранения промежуточной маршалированной объектной ссылки:

HRESULT WritePtrToGlobalVarable(IRacer *pRacer)

{

// where to write the marshaled ptr

// куда записывать маршалированный указатель

extern IStream *g_pStmPtr;

// thread synchronization for read/write

// синхронизация потока для чтения/записи

extern HANDLE g_heventWritten;

// write marshaled object reference to global variable

// записываем маршалированную объектную ссыпку

// в глобальную переменную

HRESULT hr = CoMarshalInterThreadInterfaceInStream( IID_IRacer, pRacer, &g_pStmPtr);

// signal other thread that ptr is now available

// подаем сигнал другому процессу о том, что указатель

// теперь доступен

SetEvent (g_heventWritten); return hr; }

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

HRESULT ReadPtrFromGlobalVariable(IRacer * &rpRacer) {

// where to write the marshaled ptr

// куда записывать маршалированный указатель

extern IStream *g_pStmPtr;

// thread synchronization for read/write

// синхронизация потока для чтения/записи extern

HANDLE g_heventWritten;

// wait for other thread to signal that ptr is available

// ожидаем другой поток, чтобы дать сигнал о том. что

// указатель доступен

WaitForSingleObject(g_heventWritten, INFINITE);

// read marshaled object reference from global variable

// читаем маршалированную объектную ссылку из глобальной переменной

HRESULT hr = CoGetInterfaceAndReleaseStream( g_pStmPtr, IID_IRacer. (void**) &rpRacer);

// MSHLFLAGS_NORMAL means no more unmarshals are legal

// MSHLFLAGS_NORMAL означает, что больше не может быть

// извлечено никаких демаршалированных указателей

g_pStmPtr = 0;

return hr;

}

Данный код требуется при передаче указателя от одного апартамента к другому. Отметим, что при передаче указателя от потока, выполняющегося в МТА или RTA, к другому потоку, выполняющемуся в том же апартаменте, не требуется никаких вызовов маршалинга. Тем не менее, обычной практикой для программы записи (writer) интерфейсного указателя является вызов AddRef до передачи копии в поток программы считывания (reader). Когда поток читающей программы выполняется с использованием указателя, ему, конечно, необходимо будет вызвать Release .

Отметим, что в приведенном коде программа считывания устанавливает в нуль глобальную переменную g_pStmPtr после демаршалинга. Это сделано потому, что объектная ссылка была маршалирована с флагом MSHLFLAGS_NORMAL и может быть демаршалирована только один раз. Во многих сценариях это не является проблемой. В некоторых других сценариях, однако, желательно маршалировать указатель из одного потока и иметь несколько рабочих потоков, в которых можно демаршалировать интерфейсный указатель по мере необходимости. Если все рабочие потоки выполняются в МТА, то это не является проблемой, поскольку нужно выполнить демаршалинг только в одном потоке – от имени всех потоков, выполняющихся в МТА. Если, однако, рабочие потоки выполняются в произвольных апартаментах, то этот подход не сработает, поскольку тогда придется независимо демаршалировать объектную ссылку в каждом рабочем потоке. Большинство разработчиков в этом случае обращаются к флагу MSHLFLAGS_TABLESTRONG, надеясь на однократный маршалинг и столько демаршалингов, сколько необходимо (по одному разу на апартамент). К сожалению, табличный маршалинг (в отличие от обычного маршалинга) не поддерживается в случае, если исходный указатель является заместителем, что случается часто, особенно в распределенных приложениях. Для разрешения этой проблемы в выпуске СОМ Service Pack 3 под Windows NT 4.0 вводится Глобальная интерфейсная таблипа (Global Interface Table – GIT).

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

[uuid(00000146-0000-0000-C000-000000000046), object, local ]

interface IGlobalInterfaceTable : IUnknown {

// marshal an Interface into the GIT

// маршалируем интерфейс в GIT

HRESULT RegisterInterfaceInGlobal ( [in, iid_is(riid)] IUnknown *pItf, [in] REFIID riid, [out] DWORD *pdwCookie);

// destroy the marshaled object reference

// уничтожаем маршалированную объектную ссылку

HRESULT RevokeInterfaceFromGlobal ( [in] DWORD dwCookle);

// unmarshal an interface from the GIT

// демаршалируем интерфейс из GIT

HRESULT GetInterfaceFromGlobal ( [in] DWORD dwCookie, [in] REFIID riid, [out, iid_is(riid)] void **ppv); }

Клиенты получают доступ к GIT для своего процесса, вызывая CocreateInstance с использованием класса CLSID_StdGlobalInterfaceTable. Каждый вызов CoCreateInstance с применением этого CLSID возвращает указатель на одну и ту же GIT в процессе. Так же как к интерфейсу IStream, возвращенному CoMarshalInterThreadInterfaceInStream, к интерфейсным указателям на GIT можно обратиться из любого апартамента без обязательного маршалинга.

Для того чтобы сделать интерфейсный указатель доступным для всех апартаментов процесса, апартамент, содержащий этот интерфейсный указатель, должен зарегистрировать его в GIT путем вызова метода RegisterInterfaceInGlobal. GIT вернет вызывающей программе DWORD, который представляет глобальный указатель для всех апартаментов процесса. Этот DWORD может быть использован из любого апартамента процесса для демаршалинга нового заместителя путем вызова метода GetInterfaceFromGlobal. Этот же DWORD можно использовать для повторного демаршалинга заместителей до тех пор, пока вызов RevokeInterfaceFromGlobal не объявит глобальный интерфейсный указатель недействительным. Приложения, использующие эту глобальную интерфейсную таблицу (GIT ), обычно связывают один интерфейсный указатель на весь процесс при запуске:

IGlobalInterfaceTable *g_pGIT = 0; HRESULT Init0nce(void) {

assert(g_pGIT == 0);

return CoCreateInstance(CLSID_StdGlobalInterfaceTable, 0, CLSCDX_INPROC_5ERVER, IID_IGlobalInterfaceTable, (void**)&g_pGIT);

}

Когда глобальная интерфейсная таблица является доступной, передача интерфейсного указателя в другой апартамент сводится к простой регистрации указателя в глобальной интерфейсной таблице:

HRESULT WritePtrToGlobalVariable(IRacer *pRacer) {

// where to write the marshaled ptr

// куда записывать маршалированный указатель extern

DWORD g_dwCookie;

// thread synchronization

// синхронизация потока extern HANDLE g_heventWritten;

// write marshaled object reference to global variable

// записываем маршалированную объектную ссыпку в глобальную переменную

HRESULT hr = g_pGIT->RegisterInterfaceInGlobal( pRacer, IID_IRacer, &g_dwCookie);

// signal other thread that ptr is now available

// сообщаем другому потоку о доступности указателя SetEvent(g_heventWritten); return hr; }

Следующий код корректно демаршалирует объектную ссылку и может вызываться из любого апартамента одного и того же процесса:

HRESULT ReadPtrFromGlobalVariable(IRacer * &rpRacer, bool bLastUnmarshal) {

// where to write the marshaled ptr

// куда записывать маршалированный указатель extern DWORD g_dwCookie;

// thread synchronization

// синхронизация потока extern

HANDLE g_heventWritten;

// wait for other thread to signal that ptr is available

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

WaitForSingleObject(g_heventWritten, INFINITE);

// read marshaled object reference from global variable

// читаем маршалированную объектную ссылку из глобальной переменной

HRESULT hr = g_pGIT->GetInterfaceFromGlobal( g_dwCookie, IID_IRacer, (void**)&rpRacer);

// if we are the last to unmarshal, revoke the pointer

// если мы поспедние в очереди на демаршалинг, то

// аннулируем указатель

if (bLastUnmarshal) g_pGIT->RevokeInterfaceFromGlobal(g_dwCookie);

return hr; }

Отметим принципиальную разницу между этими фрагментами кода и примерами с применением CoMarshalInterThreadInterfaceInStream. Она состоит в том, что код, основанный на GIT, способен демаршалировать более чем один заместитель.

 

Архитектура стандартного маршалинга

Как уже упоминалось ранее в этой главе, СОМ использует протокол ORPC для всех обращений между апартаментами. Это обстоятельство может представлять интерес с точки зрения архитектуры, но некоторые разработчики желают программировать коммуникационный код низкого уровня. Для того чтобы воспользоваться ORPC-коммуникациями, объектам СОМ не требуется делать ничего, кроме реализации IUnknown, для осуществления межапартаментных обращений по протоколу ORPC. По умолчанию при первом вызове CoMarshalInterface для объекта этот объект опрашивается, желает ли он управлять своими собственными межапартаментными связями. Этот вопрос приходит в форме запроса QueryInterface об интерфейсе IMarshal. Большинство объектов не реализуют интерфейс IMarshal и дают отказ на этот запрос со стороны QueryInterface, показывая тем самым, что их вполне удовлетворяет управление всеми связями самой СОМ посредством вызовов ORPC. Те объекты, которые реализуют интерфейс IMarshal, показывают этим, что ORPC им не подходит и что разработчик объекта предпочитает управлять всеми межапартаментными связями посредством специальных заместителей. Когда объект реализует интерфейс IMarshal, то все ссылки на этот объект будут подвергнуты специальному маршалингу. Специальный маршалинг будет обсуждаться позже в данной главе. Если же объект не реализует интерфейс IMarshal, то все ссылки на этот объект будут маршалированы стандартно. Большинство объектов предпочитают использовать стандартный маршалинг, и поэтому ему уделено основное внимание в данном разделе.

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

Администратор заглушек действует как идентификационная единица объекта во всей сети и единственным образом идентифицируется Идентификатором Объектов (Object Identifier – OID), который является идентификатором этого объекта во всех апартаментах. Между администраторами заглушек и идентификационными единицами СОМ-объектов имеется взаимно однозначное соответствие. Каждый администратор заглушек ссылается на ровно один СОМ-объект. Каждый СОМ-объект, использующий стандартный маршалинг, будет иметь ровно один администратор заглушек. Администратор заглушек содержит но крайней мере одну неосвобожденную ссылку на объект, которая удерживает ресурсы объекта в памяти. В этом смысле администратор заглушек является еще одним внутрипроцессным клиентом для объекта. Администратор заглушек следит за числом неосвобожденных внешних ссылок и будет существовать до тех пор, пока где-либо в сети останется хотя бы одна неосвобожденная ссылка. Большинство внешних ссылок являются просто заместителями, хотя промежуточные маршалированные объектные ссылки могут удерживать заглушки, чтобы быть уверенными, что в момент создания первого заместителя объект еще существует. Когда неосвобожденные заместители или ссылки уничтожаются, администратор заглушек извещается об этом и декрементирует свой счетчик внешних ссылок. Если уничтожена последняя внешняя ссылка на администратор заглушек, то последний самоуничтожается, освобождая свои неосвобожденные ссылки на действующий объект. Это имитирует эффект наличия на стороне клиента ссылок, поддерживающих объект. Методы явного контроля за временем жизни заглушки будут обсуждаться далее в этой главе.

Администратор заглушек действует лишь как сетевой идентификатор объекта и не понимает, как обрабатывать поступающие ORPC-запросы, предназначенные для объекта. Для того чтобы преобразовать поступающие ORPC-запросы в действительные вызовы методов объекта, администратору заглушек нужен вспомогательный объект, который знает детали сигнатур интерфейсных методов. Этот вспомогательный объект называется интерфейсной заглушкой (interface stub). Он должен правильно демаршалировать параметры [in], которые присутствуют в блоке ORPC-запроса, вызвать метод в действующий объект и затем маршалировать HRESULT и любые параметры [out] в ответный блок ORPC. Интерфейсные заглушки идентифицируются внутри апартамента с помощью Идентификаторов Интерфейсных Указателей (Interface Pointer Identifiers – IPIDs), которые внутри апартамента являются уникальными. Подобно администратору заглушек, каждая интерфейсная заглушка содержит ссылку на объект. Однако поддерживаемый интерфейс будет интерфейсом определенного типа, а не просто IUnknown. На рис. 5.3 показана взаимозависимость между администратором заглушек, интерфейсными заглушками и объектом. Отметим, что некоторые интерфейсные заглушки знают, как декодировать более чем один интерфейсный тип, в то время как другие понимают только один интерфейс.

Когда CoUnmarshalInterface демаршалирует стандартно маршалированную объектную ссылку, фактически эта функция возвращает указатель администратору заместителей (proxy manager). Этот администратор заместителей действует как копия объекта со стороны клиента и, подобно администратору заглушек, не имеет никакой априорной информации ни об одним из интерфейсов СОМ. Однако администратор заместителей знает, как реализовать три метода IUnknown. Любые дополнительные вызовы AddRef или Release просто увеличивают или уменьшают на единицу внутренний счетчик ссылок в администраторе заместителей и никогда не передаются с использованием ORPC. Последний Release в администраторе заместителей уничтожает заместитель, посылая в апартамент объекта требование о прекращении связи. Запросы QueryInterface в администраторе заместителей обрабатываются несколько иначе. Подобно администратору заглушек, администратор заместителей не имеет никакой априорной информации об интерфейсах СОМ. Вместо этого администратор заместителей должен загружать интерфейсные заместители, выставляющие тот интерфейс, на который в данный момент идет запрос. Интерфейсный заместитель преобразует вызовы метода в запросы ORPC. В отличие от администратора заглушек, администратор заместителей является непосредственно видимым для программистов, и для обеспечения правильных отношений идентификации интерфейсные заместители агрегируются в идентификационную единицу администратора заместителей. Это создает у клиента иллюзию, что все интерфейсы выставляются одним СОМ-объектом. На рис. 5.4 показаны отношения между администратором заместителей, интерфейсными заместителями и заглушкой.

Как показано на рис. 5.4, заместитель связывается с заглушкой через третий объект, называемый каналом. Канал – это поддерживаемая СОМ обертка вокруг слоя RPC на этапе выполнения. Канал выставляет интерфейс IRpcChannelBuffer

[ uuid(D5F56B60-593B-101A-B569-08002B2DBF7A), local, object ]

interface IRpcChannelBuffer : IUnknown {

// programmatic representation of ORPC message

// программное представление сообщения ORPC

typedef struct tagRPCOLEMESSAGE {

void *reserved1;

unsigned long dataRepresentation;

// endian/ebcdic

// endian /расширенный двоично-десятичный код

// для обмена информацией

void *Buffer;

// payload goes here

// полезная нагрузка идет сюда

ULONG cbBuffer;

// length of payload

// длина полезной нагрузки

ULONG iMethod;

// which method?

// чей метод?

void *reserved2[5];

ULONG rpcFlags;

} RPCOLEMESSAGE;

// allocate a transmission buffer

// выделяем буфер для передачи

HRESULT GetBuffer([inl RPCOLEMESSAGE *pMessage,

[in] REFIID riid);

// send an ORPC request and receive an ORPC response

// посылаем ORPC-запрос и получаем ORPC-ответ

HRESULT SendReceive([in,out] RPCOLEMESSAGE *pMessage,

[out] ULONG *pStatus);

// deallocate a transmission buffer

// освобождаем буфер передачи

HRESULT FreeBuffer([in] RPCOLEMESSAGE *pMessage);

// get distance to destination for CoMarshalInterface

// получаем расстояние до адресата для CoMarshalInterface

HRESULT GetDestCtx([out] DWORD *pdwDestCtx,

[out] void **ppvDestCtx);

// check for explicit disconnects

// проверяем явные отсоединения

HRESULT IsConnected(void);

}

Интерфейсные заместители используют метод SendReceive этого интерфейса, чтобы заставить канал послать блок запросов ORPC и получить блок ответов ORPC.

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

[ uuid(D5F56AFC-593B-101A-B569-08002B2DBF7A), local, object ]

interface IRpcStubBuffer : IUnknown {

// called to connect stub to object

// вызван для соединения заглушки с объектом

HRESULT Connect([in] IUnknown *pUnkServer),

// called to inform stub to release object

// вызван для информирования заглушки об освобождении объекта

void Disconnect(void);

// called when ORPC request arrives

// вызывается, когда поступает запрос ORPC

HRESULT Invoke ([in] RPCOLEMESSAGE *pmsg,

[in] IRpcChannelBuffer *pChannel);

// used to support multiple itf types per stub

// используется для поддержки нескольких типов интерфейсов

// для одной заглушки

IRpcStubBuffer *IsIIDSupported([in] REFIID riid);

// used to support multiple itf types per stub

// используется для поддержки нескольких интерфейсов

// для одной заглушки

ULONG CountRefs(vold);

// used by ORPC debugger to find pointer to object

// используется отладчиком ORPC для поиска указателя на объект

HRESULT DebugServerQueryInterface(void **ppv);

// used by ORPC debugger to release pointer to object

// используется отладчиком ORPC для освобождения указателя на объект

void DebugServerRelease(void *pv);

}

Метод Invoke будет вызываться библиотекой СОМ, когда поступит запрос ORPC на объект. При вводе маршалированные [in]-параметры будут находиться в RPCOLEMESSAGE, а при выводе заглушка должна маршалировать HRESULT метода и любые [out]-параметры, которые будут возвращены в блоке ответов ORPC.

Интерфейсный заместитель должен выставлять интерфейс (интерфейсы), за удаленный доступ к которым он отвечает, в дополнение к интерфейсу IRpcProxyBuffer:

[ uuid(D5F56A34-593B-101A-B569-08002B2DBF7A), local, object ]

interface IRpcProxyBuffer : IUnknown {

HRESULT Connect([in] IRpcChannelBuffer *pChannelBuffer);

void Disconnect(void);

}

Интерфейс IRpcPгoxуBuffer должен быть неделегирующим интерфейсом IUnknown интерфейсного заместителя. Все остальные интерфейсы, которые выставляет интерфейсный заместитель, должны делегировать администратору заместителей свои методы IUnknown. Именно в реализациях метода этих других интерфейсов интерфейсный заместитель должен использовать канал для посылки запросов ORPC на метод интерфейсной заглушки Invoke, который затем обрабатывает этот метод в апартаменте объекта.

Интерфейсные заместители и интерфейсные заглушки динамически связываются и совместно используют единый CLSID как для заместителя, так и для заглушки. Такую раздвоенную реализацию часто называют интерфейсным маршалером (interface marshaler). Объект класса интерфейсного маршалера выставляет интерфейс IPSFactoryBuffer:

[ uuid(D5F569DO-593B-101A-B569-08002B2DBF7A), local, object ]

interface IPSFactoryBuffer : IUnknown {

HRESULT CreateProxy(

[in] IUnknown *pUnkOuter,

// ptr to proxy manager

// указатель на администратор заместителей

[in] REFIID riid,

// the requested itf to remote

// запрошенный интерфейс для удаленного доступа

[out] IRpcProxyBuffer **ppProxy,

// ptr. to proxy itf.

// указатель на интерфейс заместителя

[out] void **ppv

// ptr to remoting interface

// указатель на удаленный интерфейс

);

HRESULT CreateStub(

[in] REFIID riid,

// the requested itf to remote

// запрошенный интерфейс для удаленного доступа

[in] IUnknown *pUnkServer,

// ptr to actual object

// указатель на действующий объект

[out] IRpcStubBuffer **ppStub

// ptr to stub on output

// указатель на заглушку на выходе

);

}

Администратор заместителей вызывает метод CreateProxy с целью агрегирования нового интерфейсного заместителя. Администратор заглушек вызывает метод CreateStub с целью создания новой интерфейсной заглушки.

Когда в объекте запрашивается новый интерфейс, то администраторы заместителей и заглушек должны преобразовать запрошенные IID и CLSID интерфейсного маршалера. Под Windows NT 5.0 хранилише класса совершает эти преобразования в директории NT, и они кэшируются в локальном реестре каждой хост-машины. Отображения IID в CLSID всей машины кэшируются в

HKEY_CLASSES_ROOT\Interface

а отображения каждого пользователя кэшируются в

HKEY_CURRENT_USER\Software\Classes\Interface

Один из этих ключей или оба будут содержать подключи для каждого известного интерфейса. Под Windows NT 4.0 и в более ранних версиях не существует хранилища классов и используется только область локального реестра HKEY_CLASSES_ROOT\Interface.

Если в интерфейсе установлен интерфейсный маршалер, то в реестре будет дополнительный подключ (ProxyStubClsid32). который показывает CLSID интерфейсного маршалера. Ниже показаны необходимые ключи реестра для интерфейсного маршалера:

[HKCR\Interface\{1A3A29F0-D87E-11d0-8C4F-0080C73925BA}]

@="IRacer"

[HKCR\Interface\{1A3A29F0-D87E-11d0-8C4F-OB80C73925BA}\ProxyStubClsid32]

@="{1A3A29F3-D87E-lld0-8C4F-0080C73925BA}"

Эти элементы реестра означают, что существует внутрипроцессный сервер с CLSID, равным {1A3A29F3-D87E-11d0-8C4F-0080C73925BA}, который реализует интерфейсные заместитель и заглушку для интерфейса IRacer ({1A3A29F0-D87E-11d0-8C4F-0080C73925BA}). Из этого следует, что HKCR\CLSID будет иметь подключ для интерфейсного маршалера, отображающего CLSID в соответствующее имя файла DLL. Опять же под Windows NT 5.0 это отображение может содержаться в хранилище классов, которое способно динамически заполнять локальный реестр. Поскольку интерфейсный маршалер должен выполняться в том же апартаменте, что и администратор заместителей или администратор заглушек, они должны использовать (флаг) ThreadingModel="Both" для гарантии того, что они всегда могут загрузиться в нужный апартамент.

 

Реализация интерфейсных маршалеров

В предыдущем разделе было показано четыре интерфейса, используемых архитектурой стандартного маршалинга. Хотя и допустимо реализовать интерфейсные маршалеры с помощью ручного кодирования на C++, на практике это осуществляется редко. Дело в том, что компилятор IDL может автоматически генерировать исходный С-код для интерфейсного маршалера на основе IDL-определения интерфейса. Созданные MIDL интерфейсные маршалеры преобразуют параметры метода в последовательную форму, используя протокол Сетевого Представления Данных (Network Data Representation – NDR), который допускает демаршалинг этих параметров при различных архитектурах хост-машин. NDR учитывает различия в порядке следования байтов, в формате с плавающей точкой, в наборе символов и в расположении результатов. NDR поддерживает фактически все совместимые с C типы данных. Для того чтобы обеспечить передачу интерфейсных указателей как параметров, MIDL генерирует вызовы CoMarshalInterface / CoUnmarshalInterface для маршалинга любых параметров интерфейсных указателей. Если параметр является статически типизированным интерфейсным указателем:

HRESULT Method([out] IRacer **ppRacer);

то сгенерированный код маршалера будет маршалировать параметр ppRacer путем передачи IID IRacer (IID_IRacer) вызовам CoMarshalInterface / CoUnmarshalInterface . Если же интерфейсный указатель типизирован динамически:

HRESULT Method([in] REFIID riid, [out, iid_is(riid)] void **ppv);

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

MIDL генерирует исходный код интерфейсного маршалера для каждого нелокального интерфейса, определенного вне области действия оператора library . В следующем псевдо-IDL коде

// sports.idl

// виды спорта. Язык описания интерфейсов

[local, object] interface IBoxer : IUnknown { … }

[object] interface IRacer : IUnknown { … }

[object] interface ISwimmer : IUnknown { … }

[helpstring(«Sports Lib»)]

library SportsLibrary {

interface IRacer;

// include def. of IRacer in TLB

// включаем определение IRacer в библиотеку типов TLB

[object] interface IWrestler : IUnknown { … } }

только интерфейсы IRacer и ISwimmer будут иметь исходный код интерфейсного маршалера. MIDL не будет генерировать маршалирующий код для IBoxer, поскольку атрибут [local] подавляет маршалинг. MIDL также не будет генерировать маршалер для IWrestler, поскольку он определен внутри области действия библиотечного оператора.

Если MIDL представлен в IDL такого типа, он будет генерировать пять файлов. Файл sports.h будет содержать С/С++-определения интерфейсов, sports_i.с – IID и LIBID, a sports.tlb – разобранный (tokenized) IDL для IRacer и IWrestler , который можно использовать в средах разработки, поддерживающих СОМ. Файл sports_p.c будет содержать фактические реализации методов интерфейсных заместителей и заглушек, которые осуществляют преобразования вызова методов в NDR. Этот файл также может содержать С-определения виртуальной таблицы (vtable) для интерфейсных заместителей и заглушек наряду со специальным управляющим кодом MIDL. Поскольку интерфейсные маршалеры являются внутрипроцессными серверами СОМ, то четыре стандартные точки входа (DllGetClassObject и другие) должны быть также определены. Эти четыре метода определены в пятом файле dlldata.c.

Для того чтобы построить интерфейсный маршалер из этих сгенерированных файлов, необходимо лишь создать сборочный файл (makefile), который скомпилирует три исходных С-файла (sports_i.с, sports_p.c, dlldata.c) и скомпонует их имеете для создания библиотеки DLL. Четыре стандартные точки входа СОМ должны быть явно экспортированы с помощью либо файла определения модуля, либо переключателей компоновщика. Отметим, что по умолчанию dlldata.c содержит только определения DllGetClassObject и DllCanUnloadNow . Это происходит потому, что поддерживающая RPC динамическая библиотека под Windows NT 3.50 поддерживала только эти две подпрограммы. Если интерфейсный маршалер будет использоваться только под Windows NT 3.51 или под более поздние версии (а также под Windows 95), то символ С-препроцсссора REGISTER_PROXY_DLL должен быть определен при компиляции файла dlldata.c , чтобы стандартные входные точки саморегистрации также были скомпилированы. Интерфейсный маршалер после создания должен быть установлен в локальном реестре и/или в хранилище классов.

В реализацию библиотеки СОМ под Windows NT 4.0 введена поддержка полностью интерпретируемого (interpretive) маршалинга. В зависимости от интерфейса использование интерпретируемого маршалера может значительно увеличить эффективность приложения путем сокращения объема рабочей памяти (working set). Предварительно установленные интерфейсные маршалеры для всех стандартных интерфейсов СОМ используют интерпретируемый маршалер. Microsoft Transaction Server (MTS) обязывает интерфейсные маршалеры использовать интерпретируемый маршалер. Чтобы задействовать интерпретируемый маршалер, просто запустите компилятор MIDL с переключателем /Oicf в командной строке:

midl.exe /0icf sports.idl

В то время, когда пишется этот текст, компилятор MIDL не перезаписывает существующий файл _p.c, так что при изменении данной установки этот файл должен быть удален. Поскольку интерфейсные маршалеры, основанные на /Oicf, не будут работать на версиях СОМ до Windows NT 4.0, то при компиляции исходного кода маршалера символу С-препроцессора _WIN32_WINNT нужно присвоить целое значение, большее или равное 0х400. С-компилятор сделает это во время компиляции.

Третья методика для генерирования интерфейсных маршалеров поддерживается ограниченным числом интерфейсных классов. Если интерфейс использует только простые типы данных, которые поддерживаются VARIANT, то можно использовать универсальный маршалер. Использование универсального маршалера разрешается путем добавления атрибута [oleautomation] к определению интерфейса:

[ uuid(F99D19A3-D8BA-11d0-8C4F-0080C73925BA), version(1.0)]

library SportsLib {

importlib(«stdole32.tlb»);

[

uuid(F99D1907-D8BA-11D0-8C4F-0080C73925BA), object,

oleautomation

]

interface IWrestler : IUnknown {

import «oaidl.idl»;

HRESULT HalfNelson([in] double nmsec);

} }

Наличие атрибута [oleautomation] информирует функцию RegisterTypeLib , что при регистрации библиотеки типов ей следует добавить следующие дополнительные элементы реестра:

[HKCR\Interface\{F99D1907-D8BA-11d0-8C4F-0080C73925BA}]

@="IWrestler"

[HKCR\Interface\{F99D1907-D8BA-11d0-8C4F-0080C73925BA}\ProxyStubClsid32]

@="{O0020424-0000-0000-C000-000000000046}"

[HKCR\Interface\{F99D1907-D8BA-11d0-8C4F-0080C73925BA}\ProxyStubClsid]

@="{O0020424-0000-0000-C000-000000000046}"

[HKCR\Interface\{F99D1907-D8BA-11d0-8C4F-0080C73925BA}\TypeLib]

@="{F99D19AЗ-08BA-11d0-8C4F-0080C73925BA}"

Version="1.0"

CLSID {O0020424-0000-0000-C000-000000000046} соответствует универсальному маршалеру, который предварительно устанавливается на всех платформах, поддерживающих СОМ, в том числе в 16-разрядных Windows.

Основное преимущество использования универсального маршалера заключается в том, что это – единственная поддерживаемая методика осуществления стандартного маршалинга между 16– и 32-разрядными приложениями. Кроме того, универсальный маршалер совместим с Microsoft Transaction Server. Другое преимущество универсального марщалера заключается в следующем: если библиотека типов установлена на хост-машинах и клиента, и объекта, то не потребуется никакой дополнительной DLL интерфейсного марщалера. Основной же недостаток использования универсального маршалера – ограниченная поддержка типов данных параметров. Это то же самое ограничение, которое устанавливают динамический вызов и среды выполнения сценариев, но является серьезным ограничением при разработке интерфейсов системного программирования низкого уровня. Под Windows NT 4.0 начальные затраты на вызов CoMarshalInterface / CoUnmarshalInterface несколько повысятся при использовании универсального маршалера. Однако после обработки интерфейсных заместителя и заглушки затраты на вызов метода становятся эквивалентными затратам на /0icf -маршалер.

 

Стандартный маршалинг, потоки и протоколы

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

Когда в процессе инициализируется первый апартамент, СОМ включает RPC-слой времени выполнения, переводя процесс в RPC-сервер. Если апартамент имеет тип МТА или RTA, то используется RPC-протокол ncalrpc , который является оберткой вокруг портов LPC (local procedure call – локальный вызов процедуры) под Windows NT. Если тип апартамента – STA, то используется последовательность закрытого протокола, основанная на очередях сообщений MSG Windows. При первом обращении внехостовых клиентов к объектам, постоянно находящимся в процессе, в процессе регистрируются дополнительные сетевые протоколы. Когда процесс впервые начинает использовать протоколы, отличные от протокола MSG Windows , запускается кэш потоков RPC. Этот кэш потоков начинается с одного потока, который ожидает приходящих запросов на установление соединения, запросов RPC или других действий, специфических для протоколов. Как только произойдет любое из этих событий, кэш потоков RPC переключит поток на обслуживание запроса и будет ждать следующих действий. Для предотвращения излишних затрат на создание/уничтожение потоков эти потоки возвращаются в потоковый кэш, где они будут ждать дальнейшей работы. Если работы нет, то потоки самоуничтожатся по истечении заранее определенного периода бездействия. Теневая сторона этого заключается в том, что кэш потоков RPC растет или сжимается в зависимости от занятости объектов, экспортированных из апартаментов процессов. С точки зрения программирования важно заметить, что кэш потоков RPC динамически размещает потоки, основанные на ORPC-запросах, приходящие по любым протоколам, кроме протокола Windows MSG, который будет обсуждаться позднее в этом разделе.

Когда поступающий ORPC-запрос переадресуется потоку из кэша. поток выделяет из заголовка ORPC-вызова IPID (идентификатор указателя интерфейса) и находит соответствующий администратор заглушек и интерфейсную заглушку. Поток определяет тип того апартамента, в котором хранится объект, и если объект находится в апартаменте типа МТА или RTA, поток входит в апартамент объекта и вызывает метод IRpcStubBuffer::Invoke на интерфейсную заглушку. Если апартамент имеет тип RTA, то в течение вызова метода последующие потоки не будут допускаться к объекту. Если апартамент имеет тип МТА, то последующие потоки могут обращаться к объекту одновременно. В случае внутрипроцессных RTA/MTA-связей канал может сократить кэш потоков RPC и использовать поток клиента повторно, временно входя в апартамент объекта. Если бы МТА и RTA были единственными типами апартаментов, то этого было бы достаточно.

Диспетчеризация вызовов в STA более сложна, так как в существующий STA не могут войти никакие другие потоки. К сожалению, когда ORPC-запросы поступают от внехостовых клиентов, они координируются с использованием потоков из RPC кэша потоков, которые по определению не могут выполняться в STA объекта. Для того чтобы войти в STA и направить вызов потока STA, RPC-поток использует АРI-функцию PostMessage , которая ставит сообщение в специальную MSG -очередь сообщений STA-потоков, как показано на рис. 5.5. Эта очередь представляет собой ту же очередь FIFO (first-in, first-out), которую применяет оконная система. Это означает, что для завершения диспетчеризации вызова STA-поток должен обслуживать очередь с помощью одной из вариаций следующего кода:

MSG msg;

while (GetMessage(&msg, 0, О, 0))

DispatchMessage(&msg);

Этот код означает, что STA-поток имеет по меньшей мере одно окно, которое может принимать сообщения. Когда поток входит в новый STA посредством вызова CoInitializeEx , СОМ создает новое невидимое окно, вызывая CreateWindowEx. Это окно связано с зарегистрированным в СОМ оконным классом, элемент которого WndProc ищет определенные заранее оконные сообщения и обслуживает соответствующий ORPC-запрос посредством вызова метода IRpcStubBuffer::Invoke на интерфейсную заглушку. Отметим, что поскольку окна, подобно объектам на основе STA, обладают потоковой привязкой, WndProc будет выполняться в апартаменте объекта. Чтобы избежать чрезмерного количества переключения потоков, в версии СОМ для Windows 95 предусмотрен транспортный RPC-механизм, который обходит RPC-кэш потоков и вызывает PostMessage из потока вызывающего объекта. Этот перенос возможен только в том случае, если клиент находится на том же хосте, что и объект, поскольку API-функция PostMessage не работает в сети.

Для предотвращения взаимоблокировки все типы апартаментов СОМ поддерживают реентерабельность (повторную входимость). Когда поток в апартаменте делает запрос на объект вне апартамента вызывающего объекта посредством заместителя, то могут обслуживаться и другие поступающие запросы методов, пока поток вызывающего объекта находится в ожидании ORPC-ответа па первый запрос. Без этой поддержки было бы невозможно создавать системы, основанные на совместно работающих объектах. При написании следующего кода предполагалось, что CLSID_Callback является внутрипроцессным сервером, поддерживающим модель вызывающего потока, и что CLSID_Object является классом, сконфигурированным для активации на удаленной машине:

ICallback *pcb = 0;

HRESULT hr = CoCreateInstance(CLSID_Callback, 0, CLSCTX_ALL,

IID_ICallback, (void**)&pcb);

assert(SUCCEEDED(hr));

// callback object lives in this apt.

// объект обратного вызова живет в этом апартаменте

I0bject "po = 0;

hr = CoCreateInstance(CLSID_Object, 0, CLSCTX_REMOTE_SERVER,

IID_Iobject, (void **)&po);

assert(SUCCEEDED(hr));

// object lives in different apt.

// объект живет в другом апартаменте

// make a call to remote object, marshaling a reference to

// the callback object as an [in] parameter

// делаем вызов удаленного объекта, маршалируя ссылку

// на объект обратного вызова как на [in]-параметр

hr = po->UseCallback(pcb);

// clean up resources

// очищаем ресурсы

pcb->Release();

pco->Release();

На рис. 5.6 показано, что если апартамент вызывающего объекта не поддерживает реентерабельность, то следующая реализация метода UseCallback вызовет взаимоблокировку:

STDMETHODIMP Object::UseCallback(ICallback *pcb) {

HRESULT hr = pcb->GetBackToCallersApartment();

assert(SUCCEEDED(hr));

return S_OK;

Напомним, что когда [in]–параметр передается через метод заместителя UseCallback, то заместитель вызывает CoMarshalInterface для маршалинга интерфейсного указателя ICallback. Поскольку указатель ссылается на объект, находящийся в апартаменте вызывающего объекта, то этот апартамент становится экспортером объектов и поэтому любые межапартаментные вызовы объекта должны обслуживаться в апартаменте вызывающего объекта. Когда заглушка интерфейса IObject демаршалирует интерфейс ICallback, она создает заместитель для передачи его реализации метода UseCallback. Этот заместитель представляет объект при промежуточном соединении с объектом обратного вызова, которое продолжается на протяжении всего времени вызова. Время существования этого заместителя/соединения может превысить время вызова, если реализация метода просто вызовет AddRef на заместитель:

STDMETHODIMP Object::UseCallback(ICallback *pcb) {

if (!pcb) return E_INVALIDARG;

// hold onto proxy for later use

// сохраняем в заместителе для дальнейшего использования

(m_pcbMyCaller = pcb)->AddRef();

return S_OK; }

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

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

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

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

[ uuid(00000016-0000-0000-C000-000000000046),local, object ]

interface IMessageFilter : IUnknown {

typedef struct tagINTERFACEINFO {

IUnknown *pUnk;

// which object?

// чей объект?

IID iid;

// which interface?

// чей интерфейс?

WORD wMethod;

// which method?

// чей метод?

} INTERFACEINFO;

// called when an incoming ORPC request arrives in an STA

// вызывается, когда входящий ORPC-запрос поступает в STA

DWORD HandleInComingCall(

[in] DWORD dwCallType,

[in] HTA5K dwThreadIdCaller,

[in] DWORD dwTickCount,

[in] INTERFACEINFO *pInterfaceInfo

);

// called when another STA rejects or postpones an ORPC request

// вызывается, когда другой STA отклоняет или откладывает ORPC-запрос

DWORD RetryRejectedCall(

[in] HTASK dwThreadIdCallee,

[in] DWORD dwTickCount,

[in] DWORD dwRejectType

);

// called when a non-COM MSG arrives while the thread is

// awaiting an ORPC response

// вызывается, когда поступает не СОМ'овское MSG, пока

// поток ожидает ORPC-ответа

DWORD MessagePending(

[in] HTASK dwThreadIdCallee,

[in] DWORD dwTickCount,

[in] DWORD dwPendingType

); }

Для установки специального фильтра сообщений в СОМ существует API-функция CoRegisterMessageFilter:

HRESULT CoRegisterMessageFilter([in] IMessageFilter *pmfNew, [out] IMessageFilter **ppmfOld);

CoRegisterMessageFilter связывает указанный фильтр сообщений с текущим STA. Предыдущий фильтр сообщений возвращается для того, чтобы вызывающий объект мог восстановить его в дальнейшем.

Когда бы входящий ORPC-запрос ни пришел в STA-поток, вызывается метод фильтра сообщений HandleIncomingCall, который дает апартаменту возможность принять, отклонить или отложить вызов. HandleIncomingCall используется как реентерабельными, так и нереентерабельными вызовами. Параметр dwCallType показывает, какой тип вызова был получен:

typedef enum tagCALLTYPE {

CALLTYPE_TOPLEVEL,

// STA not in outbound call

// STA не в исходящем вызове

CALLTYPE_NESTED,

// callback on behalf of outbound call

// обратный вызов от имени исходящего вызова

CALLTYPE_ASYNC,

// asynchronous call

// асинхронный вызов

CALLTYPE_TOPLEVEL_CALLPENDING,

// new call while waiting

// новый вызов во время ожидания

CALLTYPE_ASYNC_CALLPENDING

// async call while waiting

// асинхронный вызов во время ожидания

} CALLTYPE;

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

В СОМ определено перечисление, которое должна возвратить реализация HandleIncomingCall, чтобы указать, что произошло с вызовом:

typedef enum tagSERVERCALL {

SERVERCALL_ISHANDLED,

// accept call and forward to stub

// принимаем вызов и направляем его заглушке

SERVERCALL_REJECTED,

// tell caller that call is rejected

// сообщаем вызывающему объекту, что вызов отклонен

SERVERCALL RETRYLATER

// tell caller that call is postponed

// сообщаем вызывающему объекту, что вызов отложен

} SERVERCALL;

Если функция HandleIncomingCall фильтра сообщений возвращает SERVERCALL_ISHANDLED, то вызов будет направлен в интерфейсную заглушку для демаршалинга. Фильтр сообщений, принятый по умолчанию, всегда возвращает SERVERCALL_ISHANDLED. Если HandleIncomingCall возвращает SERVERCALL_REJECTED или SERVERCALL_RETRYLATER, то фильтр сообщений вызывающего объекта будет информирован о положении вызова и ORPC-запрос будет отклонен.

Когда фильтр сообщений отвергает или откладывает вызов, то фильтр сообщений вызывающего объекта информируется об этом с помощью метода RetryRejectedCall. Этот вызов происходит в контексте апартамента вызывающего объекта, и реализация метода RetryRejectedCall фильтра сообщений может решать, повторять ли отложенный вызов. Параметр dwRejectType указывает, был ли вызов отклонен или отложен. Реализация канала вызывающего объекта будет решать, какое действие предпринять, в зависимости от значения, возвращенного RetryRejectedCall. Если RetryRejectedCall возвращает –1, то канал предположит, что повторных попыток не требуется, и немедленно заставит заместитель возвратить HRESULT, равный RPC_E_CALL_REJECTED. По умолчанию фильтр сообщений всегда возвращает –1. Любое другое значение, возвращаемое методом RetryRejectedCall, интерпретируется как число миллисекунд, через которое следует повторить вызов. Поскольку это согласование осуществляется внутри канала, то не требуется повторного ORPC-запроса со стороны заместителя. В сущности, интерфейсные маршалеры не имеют ни малейшего понятия о процессах в фильтре сообщений.

Когда размещенный в STA поток блокирован в канале в ожидании ORPC-ответа, то не связанные с СОМ оконные сообщения могут поступать в MSG -очередь потока. Когда это происходит, то фильтр сообщений STA уведомляется об этом посредством метода MessagePending. Фильтр сообщений, принятый по умолчанию, разрешает диспетчеризацию некоторых оконных сообщений, чтобы предотвратить замораживание всей оконной системы. Тем не менее, действия ввода (например, щелчки мышью, нажатие клавиш) не учитываются, чтобы конечный пользователь не начал новое взаимодействие с системой. Как уже отмечалось ранее, фильтры сообщений существуют только в апартаментах STA и не поддерживаются в RTA или МТА. Фильтры сообщений лишь обеспечивают лучшую интеграцию СОМ с потоками, обрабатывающими события от пользовательского интерфейса. Из этого следует, что все эти потоки должны выполняться в однопотоковых апартаментах. Большинство потоков, обрабатывающих события от пользовательского интерфейса, захотят установить специальный фильтр сообщений, чтобы убедиться в том, что входящие запросы не обслуживаются, пока приложение находится в такой критической фазе, в которой реентерабельность может привести к семантическим ошибкам. Фильтры сообщений не следует применять в качестве универсального механизма для управления потоками. Реализация фильтров сообщений печально известна своей неэффективностью в тех случаях, когда вызовы отклоняются или откладываются. Это делает фильтры сообщений малоприспособленными в качестве механизма для управления потоками в высокопроизводительных приложениях.

 

Управление жизненным циклом и маршалинг

Ранее в этой главе обсуждались взаимоотношения между администратором заглушек и объектом. Администратор заглушек создается при первом вызове CoMarshalInterface для определенного идентифицированного объекта. Администратор заглушек хранит неосвобожденные ссылки на тот объект, который он предсиавляет, и существует до тех пор, пока остается хотя бы одна неосвобожденная внешняя ссылка на заглушку. Эти внешние ссылки обычно являются заместителями, хотя учитываются и маршалированные объектные ссылки, так как они могут представлять заместители. Когда все внешние ссылки на администратор заглушек уничтожены, он самоуничтожается и освобождает все хранящиеся в нем ссылки на текущий объект. Такое поведение по умолчанию в точности имитирует обычную внутрипроцессную семантику AddRef и Release. Многие объекты не имеют никаких специальных требований относительно жизненного цикла и целиком удовлетворяются этой схемой. Некоторые объекты предпочитают дифференцировать взаимоотношения между внешними ссылками, администратором заглушек и объектом. К счастью, СОМ предоставляет администратору заглушек на время жизненного цикла достаточно приемов работы, которые позволяют реализовывать различные стратегии. Для того чтобы понять, как организован жизненный цикл заглушки, необходимо в первую очередь исследовать алгоритм распределенной сборки мусора (garbage collection) СОМ.

Когда администратор заглушек создан, то идентификатор объекта (OID) регистрируется в распределенном сборщике мусора СОМ, который в настоящее время реализован в службе распознавателя идентификаторов экспортера объектов (OXID Resolver – OR). OR отслеживает, какие идентификаторы объектов экспортируются из каких апартаментов локальной хост-машины. Когда создается администратор заместителей, то CoUnmarshalInterface информирует локальный OR о том, что в апартамент импортируется объектная ссылка. Это означает, что локальный OR также знает, какие OID импортированы в каждый апартамент локальной хост-машины. Если определенный OID импортирован на хост-машину впервые, OR импортирующего хоста устанавливает отношения тестового опроса (ping relationship) с экспортирующим хостом. Тогда OR импортирующей стороны будет передавать периодические тестовые сообщения через RPC, подтверждая тем самым, что импортирующая хост-машина все еще функционирует и доступна в сети. Текущая реализация посылает такое сообщение один раз в две минуты. Если за последний тестовый интервал (ping interval) не было импортировано никаких дополнительных OID, то посылается простое уведомление. Если же были импортированы новые ссылки или освобождены уже существующие, то посылается более сложное сообщение, показывающее разницу между прошлым и нынешним наборами хранимых ссылок.

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

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

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

Администратор заглушек следит за тем, сколько внешних ссылок еще не выполнено. Когда заглушка создана, этот счетчик устанавливается в нуль. Если сделан вызов CoMarshalInterface с флагом MSHLFLAGS_NORMAL, этот счетчик увеличивается на некоторое число n, которое записано в маршалированной объектной ссылке. Администратор заместителей, демаршалируя ссылку, добавляет n к своему счетчику хранимых ссылок. Если CoMarshalInterface вызван для администратора заместителей для передачи копии ссылки в другой апартамент, то администратор заместителей может выделить некоторое количество ссылок для инициализации второго заместителя. Если в заместителе осталась только одна ссылка, он должен вернуться в администратор заглушек для запроса дополнительных ссылок.

Часто бывает полезно сохранить маршалированные интерфейсные ссылки в центральной области, доступной для одного или более клиентов. Классическим примером этого является Таблица Исполняемых Объектов (Running Object Table), используемая некоторыми реализациями моникеров. Если бы маршалированные интерфейсные указатели должны были создаваться с использованием флага MSHLFLAGS_NORMAL, то только один клиент смог бы когда-либо демаршалировать объектную ссылку. Если предполагается, что объектную ссылку будут демаршалировать несколько клиентов, то ссылка должна маршалироваться с применением либо MSHLFLAGS_TABLESTRONG, либо MSHLFLAGS_TABLEWEAK. В обоих случаях маршалированная объектная ссылка может быть демаршалирована несколько раз.

Разница между сильным (strong) и слабым (weak) табличными маршалингами заключается во взаимоотношениях между маршалированой объектной ссылкой и администратором заглушек. Когда маршалированная объектная ссылка создается с флагом MSHLFLAGS_TABLEWEAK, то внешний счетчик ссылок в администраторе заглушек не увеличивается. Это означает, что маршалированная объектная ссылка будет содержать нуль ссылок, и каждому администратору заместителей для получения одной или более внешних ссылок придется связываться с администратором заглушек. Маршалированная с помощью слабой таблицы ссылка не представляет сосчитанную внешнюю ссылку на администратор заглушек. Поэтому, когда последний администратор заместителей отсоединится от администратора заглушек, администратор заглушек самоуничтожится и, конечно, освободит все хранившиеся ссылки СОМ на объект. Если ни один администратор заместителей ни разу не свяжется с администратором заглушек, то последний останется жить в течение неопределенного времени. Отрицательной стороной является то, что неосвобожденная маршалированная объектная ссылка не заставляет оставаться в живых администратор заглушек или объект. Напротив, когда маршалированная объектная ссылка создана с применением флага MSHLFLAGS_TABLESTRONG , то есть с помощью сильной таблицы, то внешний счетчик ссылок увеличивается на единицу. Это означает, что маршалированная объектная ссылка представляет сосчитанную внешнюю ссылку на администратор заглушек. Как и в случае маршалинга по слабой таблице, каждому администратору заместителей понадобится связаться с администратором заглушек, чтобы получить одну или более дополнительных внешних ссылок. Поскольку маршалированная по сильной таблице ссылка представляет внешний счетчик ссылок на администратор заглушек, то при отсоединении последнего администратора заместителей от администратора заглушек он не будет самоуничтожаться и фактически продолжит хранение ссылок СОМ на объект. Отрицательная сторона маршалинга по сильной таблице заключается в том, что неосвобожденная маршалированная объектная ссылка влияет на жизненный цикл администратора заглушек или объекта. Это означает, что должен существовать какой-нибудь механизм для освобождения ссылок, хранящихся в объектной ссылке, маршалированной по сильной таблице. В СОМ предусмотрена API-функция CoReleaseMarshalData, которая информирует администратор заглушек о том, что маршалированная объектная ссылка уничтожается:

HRESULT CoReleaseMarshalData([in] IStream *pStm);

Подобно CoUnmarshalInterface, CoReleaseMarshalData принимает интерфейсный указатель IStream на маршалированную объектную ссылку. Если таблица маршалинга более не нужна, для ее аннулирования следует вызвать функцию CoReleaseMarshalData . Если по некоторым причинам нормально маршалированная объектная ссылка не будет демаршалироваться с помощью CoUnmarshalInterface , то должна вызываться также функция CoReleaseMarshalData .

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

HRESULT CoLockObjectExternal([in] IUnknown *pUnkObject,

[in] BOOL bLock,

[in] BOOL bLastUnlockKillsStub);

Первый параметр CoLockObjectExternal должен указывать на действительный объект, он не может указывать на заместитель. Второй параметр, bLock, показывает, увеличивать или уменьшать на единицу счетчик внешних ссылок администратора заглушек. Третий параметр показывает, нужно или нет уничтожать администратор заглушек, если этот вызов удаляет последнюю внешнюю ссылку. Чтобы понять, для чего необходима функция CoLockObjectExternal , рассмотрим объект, который контролирует некоторое аппаратное устройство и зарегистрирован в таблице исполняемых объектов (Running Object Table) с использованием маршалинга по слабой таблице. Пока объект осуществляет активный контроль, он хочет быть уверенным, что его администратор заглушек действительно существует, чтобы новые клиенты могли соединяться с объектом для проверки состояния устройства. Если же, однако, объект не осуществляет активный контроль, то он мог бы пожелать, чтобы администратор заглушек исчез, если нет соединенных с ним неосвобожденных заместителей. Для реализации такой функциональной возможности объект должен иметь метод, который начинает осуществлять контроль:

STDMETHODIMP Monitor::StartMonitoring(void) {

// ensure that stub manager/object stays alive

// убеждаемся, что администратор заглушек/объект остается жив

HRESULT hr = CoLockObjectExternal(this, TRUE, FALSE);

// start hardware monitoring

// начинаем контроль за аппаратным устройством

if (SUCCEEDED(hr))

hr = this->EnableHardwareProbe();

return hr; }

а также другой метод, который предписывает объекту закончить активный контроль:

STDMETHODIMP Monitor::StopMonitoring(void)

{

// stop hardware monitoring

// прекращаем контроль за устройством

this->DisableHardwareProbe();

// allow stub manager/object to die when no clients exist

// разрешаем администратору заглушек/объекту прекратить

// существование, когда нет клиентов

hr = CoLockObjectExternal(this, FALSE, TRUE);

return hr; }

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

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

HRESULT CoDisconnectObject(

[in] Unknown * pUnkObject,

// ptr to object

// указатель на объект

[in] DWORD dwReserved

// reserved, must be zero

// зарезервировано, должно равняться нулю

);

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

STDMETHODIMP Monitor::GetSample(/*[out]*/ SAMPLEDATA *ps) {

HRESULT hr = this->GetSampleFromProbe(ps);

if (FAILED(hr))

// probe or object may be corrupted

// образец или объект могут быть испорчены

CoDisconnectObject(this, 0);

return hr; }

Функция CoDisconnectObject используется также в случаях, когда процесс хочет отключиться, хотя один или более его объектов могут иметь неосвобожденные заместители. При явном вызове CoDisconnectObject до уничтожения любых объектов, которые могут иметь оставшиеся заместители, нет риска, что исходящие ORPC-запросы будут обслуживаться после того, как объект уже уничтожен. Если бы входящий ORPC-запрос должен был бы поступить после того, как объект уже уничтожен, но администратор заглушек еще жив, то небрежность привела бы к вызову интерфейсной заглушкой соответствующего метода из участка памяти, ранее известного как данный объект. Это вызвало бы лишние неприятности, связанные с тщетными усилиями по отладке.

Обе функции – CoLockObjectExternal и CoDisconnectObject – могут быть использованы разработчиком объектов для манипулирования администратором заглушек. Часто бывает полезно знать, есть ли в администраторе заглушек в наличии какие-либо заместители или объектные ссылки, маршалированные по сильной таблице (strong marshals ). Для информирования объектов о том, что имеются неосвобожденные внешние ссылки на администратор заглушек, в СОМ определен интерфейс IExternalConnection , который может быть экспортирован объектами:

[ uuid(00000019-0000-0000-C000-000000000046), object, local ]

interface IExternalConnection : IUnknown {

DWORD AddConnection(

[in] DWORD extconn,

// type of reference

// тип ссылки

[in] DWORD reserved

// reserved, must be zero

// зарезервировано, должно быть равно нулю

);

DWORD ReleaseConnection(

[in] DWORD extconn,

// type of reference

// тип ссылки

[in] DWORD reserved,

// reserved, must be zero

// зарезервировано, должно быть равно нулю

[in] BOOL fLastReleaseCloses

// should kill stub?

// нужно ли убить заглушку?

); }

При первом подсоединении администратора заглушек к объекту он спрашивает объект, желает ли тот, чтобы его уведомляли о создании или уничтожении внешних ссылок. Он делает это посредством запроса интерфейса IExternalConnection для QueryInterface. Если объект не реализует IExternalConnection, то администратор заглушек будет использовать свой собственный счетчик ссылок при решении вопроса, когда уничтожать администратор заглушек. Если же объект предпочтет реализовать IExternalConnection, то в этом случае администратор заглушек будет жить до тех пор, пока объект явно не уничтожит его путем вызова CoDisconnectObject.

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

class Monitor : public IExternalConnection, public IMonitor {

LONG m_cRef;

// normal COM reference count

// обычный счетчик ссылок СОМ

LONG m_cExtRef;

// external reference count

// счетчик внешних ссылок

Monitor(void) : m_cRef(0), m_cExtRef(0) { … }

STDMETHODIMP_(DWORD) AddConnection(DWORD extconn, DWORD) {

if (extconn & EXTCONN_STRONG)

// must check for this bit

// нужно проверить этот бит

return InterlockedIncrement(&m_cExtRef);

}

STDMETHODIMP_(DWORD) ReleaseConnection(DWORD extconn, DWORD,

BOOL bLastUnlockKillsStub) {

DWORD res = 0;

if (extconn & EXTCONN_STRONG) {

// must check for this bit

// нужно проверить этот бит

res = InterlockedDecrement(&m_cExtRef);

if (res == 0 && bLastUnlockKillsStub)

CoDisconnectObject(this, 0);

}

return res;

} }

: : :

: : : }

Получив эту реализацию, подпрограмма потока могла бы проверить состояние объекта и решить, выполнять или нет операцию регистрации, основываясь на уровне активности объекта:

DWORD WINAPI ThreadProc(void *pv) {

// assume ptr to real object is passed to CreateThread

// пусть указатель на действительный объект передается в CreateThread

Monitor *pm = (Monitor*)pv;

while (1) {

// sleep for 10 seconds

// ожидаем 10 секунд

Sleep(1OOOO);

// if object is not in use, perform a log operation

// если объект не используется, то выполняем операцию регистрации

if (pm->m_cExtRef == 0)

pm->TryToLogSampleData();

}

return 0; }

Если принять, что метод объекта TryToLogSampleData корректно поддерживает параллелизм, то данная поточная процедура будет регистрировать данные только при условии, что объект не используется внешними клиентами или не осуществляет активный контроль (напомним, что при контроле объект увеличивает счетчик внешних ссылок посредством CoLockObjectExternal). Хотя данный пример может показаться несколько запутанным, имеются случаи, когда отслеживание внешних ссылок является решающим для обеспечения правильности операции. Один классический пример описан в главе 6 и относится к регистрации объектов класса на внепроцессных серверах.

 

Специальный маршалинг

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

[uuid(00000003-0000-0000-C000-000000000046), local, object] interface IMarshal : IUnknown {

// get CLSID for custom proxy (CoMarshalInterface)

// получаем CLSID для специального заместителя (CoMarshalInterface)

HRESULT GetUnmarshalClass( [in] REFIID riid, [in, iid_is(riid) ] void *pv, [in] DWORD dwDestCtx, [in] void *pvDestCtx, [in] DWORD mshlflags, [out] CLSID *pclsid);

// get size of custom marshaled objref (CoGetMarshalSizeMax)

// получаем размер специально маршалированной объектной ссылки (CoGetMarshalSizeMax)

HRESULT GetMarshalSizeMax( [in] REFIID riid, [in, iid_is(riid)] void *pv, [in] DWORD dwDestCtx, [in] void *pvDestCtx, [in] DWORD mshlflags, [out] DWORD *pSize);

// write out custom marshaled objref (CoMarshalInterface)

// выполняем контрольное считывание специально маршалированной объектной ссылки (CoMarshalInterface)

HRESULT MarshalInterface([in] IStream *pStm, [in] REFIID riid, [in, iid_is(riid)] void *pv, [in] DWORD dwDestCtx, [in] void *pvDestCtx, [in] DWORD mshlflags);

// read objref and return proxy (CoUnmarshalInterface)

// читаем объектную ссылку и возвращаем заместитель (CoUnmarshalInterface)

HRESULT UnmarshalInterface([in] IStream *pStm, [in] REFIID riid, [out, iid_is(riid)] void **ppv);

// revoke a marshal (CoReleaseMarshalData)

// аннулируем маршалер (CoReleaseMarshalData)

HRESULT ReleaseMarshalData([in] IStream *pStm);

// tear down connection-state (CoDisconnectObject)

// разрываем связь между объектами (CoDisconnectObject)

HRESULT DisconnectObject([in] DWORD dwReserved);

}

Комментарии, предваряющие определения методов, показывают, какие именно API-функции вызывает каждый из них.

Когда метод CoMarshalInterface вызывается на объект, поддерживающий специальный маршалинг, маршалированная объектная ссылка имеет несколько другой (формат, как показано на рис. 5.7. Заметим, что после стандартного заголовка MEOW маршалированная объектная ссылка просто содержит CLSID, используемый для создания специального заместителя и непрозрачного байтового массива, предназначенного для инициализации этого специального заместителя. CoMarshalInterface находит CLSID специального заместителя посредством вызова на объект метода IMarshal::GetUnmarshalСlass. CoMarshalInterface заполняет непрозрачный байтовый массив, вызывая реализацию метода IMarshal::MarshalInterface объекта. Именно в MarshalInterface объект получает свой первый и единственный шанс послать инициализационное сообщение новому специальному заместителю, просто записав его в подаваемый байтовый поток.

При вызове CoUnmarshalInterface это сообщение будет передано вновь созданному специальному заместителю через его метод IMarshal::UnmarshalInterface. Это означает, что и объект, и специальный заместитель должны реализовать IMarshal . Метод объекта MarshalInterface записывает инициализационное сообщение. Метод заместителя UnmarshalInterface читает инициализационное сообщение. Когда метод UnmarshalInterface возвращается, СОМ больше не участвует ни в каких связях заместитель/объект. Реализация интерфейсных методов семантически корректным способом является делом специального заместителя. Если нужно произвести удаленный вызов метода на объект, то сделать это – задача заместителя. Если же метод может быть реализован в апартаменте клиента, то заместитель может сделать и это.

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

Для получения указателя на стандартный маршалер объекты могут вызывать метод CoGetStandardMarshal:

HRESULT CoGetStandardMarshal( [in] REFIID riid,

// type of itf marshaled?

// тип, которым маршалирован интерфейс?

[in, iid_is(riid)] IUnknown *pUnk,

// the itf to marshal

// интерфейс для маршалинга

[in] DWORD dwDestCtx,

// MSHCTX [in] void *pvDestCtx,

// reserved // зарезервировано [in] DWORD mshlflags,

// normal vs. table // нормальный или табличный маршалинг

[out] IMarshal **ppMarshal); // ptr to std. Marshal

// указатель на стандартный маршалер

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

STDMETHODIMP CustStd::GetMarshalSizeMax(

ULONG *pcb, REFIID riid, void *pv, DWORD dwDestCtx, void *pvDestCtx, DWORD mshlflags) {

// if context is supported, do work!

// если контекст поддерживается, то действуем!

if (dwDestCtx == MSHCTX_LOCAL || dwDestCtx == MSHCTX_INPROC) return this->MyCustomMarshalingRoutine(pcb);

// unsupported context, delegate to std marshal

// контекст не поддерживается, обращаемся к стандартному маршапингу

IMarshal *pMsh = 0;

HRESULT hr = CoGetStandardMarshal (riid, pv, dwDestCtx, pvDestCtx, mshlflags, &pMsh);

if (SUCCEEDED(hr)) {

hr = pMsh->GetMarshalSizeMax(pcb, riid, pv, dwDestCtx, pvDestCtx, mshlflags);

pMsh->Retease();

}

return hr;

}

В этом фрагменте кода не показано, как писать инициализационное сообщение для случая, когда действительно желателен специальный маршалинг. Дело в том, что не существует стандартной реализации каждого из методов IMarshal (отсюда и термин специальный (custom) маршалинг). Существует, однако, несколько общих сценариев, в которых специальный маршалинг чрезвычайно выигрышен и реализация IMarshal в этих сценариях – довольно обычное явление. Безусловно, наиболее общим приложением IMarshal является реализация маршалинга по значению (marshal-by-value).

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

Представим следующее определение класса СОМ-обертки вокруг простой двумерной точки:

class Point : public IPoint, public IMarshal

{

long m_x;

long m_y;

public:

Point(void) : m_x(0), m_y(0) {}

IMPLEMENT_UNKNOWN (Point)

BEGIN_INTERFACE_TABLE(Point)

IMPLEMENTS_INTERFACE(IPoint)

IMPLEMENTS_INTERFACE(IMarshal)

END_INTERFACE_TABLE()

// IPoint methods

// методы IPoint

// IMarshal methods

// методы IMarshal

};

Для поддержки маршалинга по значению метод MarshalInterface класса должен преобразовать состояние объекта в последовательную форму в качестве инициализационного сообщения для заместителя:

STOMETHODIMP Point::MarshalInterface(IStream *pStm, REFIID, void *, DWORD, void *, DWORD)

{

// write out endian header

// переписываем завершающий заголовок

DWORD dw = OxFF669900;

HRESULT hr = pStm->Write(&dw, sizeof(DWORD), 0);

if (FAILED(hr)) return hr; dw = m_x;

hr = pStm->Write(&dw, sizeof(DWORD), 0);

if (FAILED(hr)) return hr; dw = m_y;

return pStm->Write(&dw, sizeof (DWORD), 0);

}

Если допустить, что класс объекта реализован как внутрипроцессный сервер, то специальный заместитель может стать просто вторым экземпляром того же класса, из чего вытекает следующая реализация GetUnmarshalClass:

STDMETHODIMP Point::GetUnmarshalClass(REFIID, void *, DWORD, void *, DWORD, CLSID *pclsid)

{

*pclsid = CLSID_Point;

// this class's CLSID

// CLSID этого класса return hr;

}

Для обеспечения того, чтобы для инициализационного сообщения было выделено достаточно места, методу объекта GetMarshalSizeMax требуется возвратить правильное количество байт:

STDMETHODIMP Point::GetMarshalSizeMax(REFIID, void *, DWORD, void *, DWORD, DWORD *pcb)

{

*pcb = 3 * sizeof (DWORD);

// m_x + m_y + header

return hr;

}

Когда маршалированная объектная ссылка демаршалируется с помощью CoUnmarshalInterface, тот факт, что она была маршалирована специальным образом, вызовет создание нового специального заместителя. Объектная ссылка содержит CLSID специального заместителя, возвращенный исходным объектом в своем методе GetUnmarshalClass. Когда создан новый специальный заместитель, его метод UnmarshalInterface получает инициализационное сообщение, которое объект записал в своей реализации MarshalInterface:

STDMETHODIMP Point::UnmarshalInterface(IStream *pStm, REFIID riid, void ** ppv)

{

*ppv = 0;

// read endian header // читаем заключительный заголовок DWORD dw; ULONG cbRead;

HRESULT hr = pStm->Read(&dw, sizeof (DWORD), &cbRead);

if (FAILED(hr) || cbRead != sizeof(DWORD)) return RPC_E_INVALID_DATA; bool bSwapEndian = dw == 0x009966FF;

// read m_x and m_y // читаем m_x и m_y

hr = pStm->Read(&dw, sizeof(DWORD), &cbRead);

m_x = dw; if (FAILED(hr) || cbRead != sizeof(DWORD)) return RPC_E_INVALID_DATA;

hr = pStm->Read(&dw, sizeof(DWORD), &cbRead);

m_y = dw; if (FAILED(hr)) || cbRead != sizeof(DWORD)) return RPC_E_INVALID_DATA;

// byte swap members if necessary

// байт переставляет свои биты, если необходимо

if (bSwapEndian) byteswapdata(&m_x, &m_y);

// return pointer to this object

// возвращаем указатель на этот объект return

this->QueryInterface(riid, ppv);

}

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

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

 

Маршалер свободной поточной обработки (FreeThreaded Marshaler)

Если в классе установлена опция ThreadingModel="Both" , то она показывает, что экземпляры класса, а также объект класса могут безопасно находиться в любых апартаментах: STA или МТА. В то же время, согласно правилам СОМ, любой данный экземпляр будет находиться только в одном апартаменте. Если бы разработчик объекта прошел все этапы проверки того, что объект может благополучно находиться в МТА, то в этом случае объекту вообще не нужно было бы заботиться об апартаментах. Одновременный доступ к подобному объекту мог бы быть не только для нескольких потоков внутри МТА, но также от потоков вне МТА (например, от потоков, выполняемых в STA). В то же время клиенты не могут знать, что такой доступ является безопасным для отдельно взятого объекта, поэтому любое совместное использование интерфейсного указателя в нескольких апартаментах должно быть установлено с использованием явной технологии маршалинга. Это означает, что доступ к внутрипроцессному объекту будет осуществляться через ORPC-вызовы, если только вызывающий объект не выполняется в том же самом апартаменте, где был создан объект.

В отличие от клиентов, объекты знают о своих отношениях с апартаментами, о своем параллелизме и реентерабельности. Объекты, удовлетворяющиеся ORPC-запросами при доступе из нескольких апартаментов одного и того же процесса, ведут себя так по умолчанию. А объект, которого не устраивает доступ ORPC, имеет возможность обойти это путем реализации специального маршалинга. Довольно просто использовать специальный маршалинг для обхода администратора заглушек и преобразования исходного указателя на объект в маршалированную объектную ссылку. При использовании этой технологии реализация специального заместителя могла бы просто считывать исходный указатель из маршалированной объектной ссылки и передавать его вызывающему объекту в импортирующем апартаменте. Клиентские потоки по-прежнему передавали бы интерфейсный указатель через границу апартамента с помощью явного или неявного вызова CoMarshalInterface / CoUnmarshalInterface. Однако объект мог бы договориться со специальным заместителем о том, чтобы просто передать исходный указатель нужному объекту. Хотя данная технология безупречно работает для внутрипроцессного маршалинга, она, к сожалению, не приводит к успеху в случае межпроцессного маршалинга. Но, к счастью, реализация объекта может просто обратиться к стандартному маршалеру за другим контекстом маршалинга, отличным от MSHCTX_INPROC.

Поскольку только что описанное поведение является полезным для большого класса объектов, в СОМ предусмотрена агрегируемая реализация IMarshal, выполняющая в точности то, что было описано. Эта реализация называется маршалером свободной поточной обработки (FreeThreaded Marshaler – FTM) и может быть осуществлена с помощью вызова API-функции CoCreateFreeThreadedMarshaler:

HRESULT CoCreateFreeThreadedMarshaler( [in] IUnknown *pUnkOuter, [out] IUnknown **ppUnkInner);

Класс, который желает использовать FTM, просто агрегирует экземпляр либо во время инициализации, либо по требованию при первом запросе QueryInterface об интерфейсе IMarshal . Следующий класс заранее обрабатывает FTM во время построения.

class Point : public IPoint {

LONG m_cRef; IUnknown *m_pUnkFTM;

long m_x; long m_y; Point(void) : m_cRef(0), m_x(0), m_y(0) {

HRESULT hr = CoCreateFreeThreadedMarshaler(this,&m_pUnkFTM);

assert(SUCCEEDED(hr)) ;

}

virtual ~Point(void) { m_pUnkFTM->Release(); }

};

Соответствующая реализация QueryInterface просто запросила бы интерфейс IMarshal из FTM:

STDMETHODIMP Point::QueryInterface(REFIID riid, void **ppv)

{ if (riid == IID_IUnknown || riid == IID_IPoint)

*ppv = static_cast(this);

else if (riid == IID_IMarshal) return m_pUnkFTM->QueryInterface(riid, ppv);

else return (*ppv = 0), E_NOINTERFACE;

((IUnknown* )*ppv)->AddRef();

return S_OK;

}

Поскольку используется FTM, не понадобится никаких заместителей, как бы ни маршалировались через внутрипроцессные границы апартамента ссылки на объекты Point . Это применимо к явным вызовам CoMarshalInterface / CoUnmarshalInterface, а также в случаях, когда ссылки на объекты Point передаются как параметры метода на внутрипроцессные заместители объектов, не являющихся объектами Point.

FTM занимает не менее 16 байт памяти. Поскольку многие внутрипроцессные объекты никогда не используются за пределами своего апартамента, то предварительное выделение памяти для FTM не является лучшим использованием имеющихся ресурсов. В высшей степени вероятно, что объект уже имеет некий примитив для синхронизации потоков. В таком случае FTM может быть отложенно агрегирован (lazy-aggregated) при первом же запросе QueryInterface о IMarshal. Для того чтобы добиться этого, рассмотрим такое определение класса:

class LazyPoint : public IPoint {

LONG m_cRef; IUnknown *m_pUnkFTM;

long m_x;

long m_y;

LazyPoint (void) : m_cRef (0) .m_pUnkFTM(0),m_x(0), m_y(0) {}

virtual ~LazyPoint(void) {

if (m_pUnkFTM) m_pUnkFTM->Release();

}

void Lock(void);

// acquire object-specific lock

// запрашиваем блокировку, специфическую для объектов

void Unlock(void);

// release object-specific lock

// освобождаем блокировку, специфическую для объектов

:

:

:

};

Основываясь на таком определении класса, следующая реализация QueryInterface осуществит корректное агрегирование FTM по требованию:

STDMETHODIMP Point::QueryInterface(REFIID riid, void **ppv) {

if (riid == IID_IUnknown || riid == IID_IPoint)

*ppv = static_cast(this);

else if (riid == IID_IMarshal) {

this->Lock();

HRESULT hr = E_NOINTERFACE;

*ppv = 0;

if (m_pUnkFTM == 0)

// acquire FTM first time through

// получаем первый FTM

CoCreateFreeThreadedMarshaler(this, &m_pUnkFTM);

if (m_pUnkFTM != 0)

// by here, FTM is acquired

// здесь получен FTM

hr = m_pUnkFTM->QueryInterface(riid, ppv);

this->Unlock();

return hr;

} else return (*ppv = 0), E_NOINTERFACE;

((IUnknown *)*ppv)->AddRef(); return S_OK; }

Недостатком данного подхода является то, что все запросы QueryInterface на IMarshal будут сериализованы (преобразованы в последовательную форму); тем не менее, если IMarshal вообще не будет запрошен, то будет запрошено меньше ресурсов.

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

class Rect : public IRect { LONG m_cRef; IPoint *m_pPtTopLeft; IPoint *m_pPtBottomRight; Rect(void) : m_cRef(0) {

HRESULT hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**) &m_pPtTopLeft);

assert(SUCCEEDED (hr)); hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&m_pPtBottomRight);

assert (SUCCEEDED(hr));

}

;

;

;

}

Пусть класс Rect является внутрипроцессным и помечен как ThreadingModel = «Both». Разработчик данного Rect -объекта всегда будет выполняться в апартаменте потока, вызывающего CoCreateInstance (CLSID_Rect). Это означает, что два вызова CoCreateInstance (CLSID_Point) будут также выполняться в апартаменте клиента. Правила же СОМ гласят, что элементы данных m_pPtTopLeft и m_pPtBottomRight могут быть доступны только из того апартамента, который выполняет вызовы CoCreateInstance.

Похоже на то, что по меньшей мере один из методов Rect использует в своей работе два интерфейсных указателя в качестве элементов данных:

STDMETHODIMP Rect::get_Area(long *pn) {

long top, left, bottom, right;

HRESULT hr = m_pPtTopLeft->GetCoords(&left, &top);

assert(SUCCEEDED(hr));

hr = m_pPtBottomRight->GetCoords(&right, &bottom);

assert (SUCCEEDED (hr));

*pn = (right – left) * (bottom – top);

return S_OK;

}

Если бы класс Rect должен был использовать FTM, тогда можно было бы вызывать этот метод из апартаментов, отличных от того апартамента, который осуществлял начальные вызовы CoCreateInstance. К сожалению, это заставило бы метод get_Area нарушить правила СОМ, поскольку два элемента данных – интерфейсные указатели – являются легальными только в исходном апартаменте. Если бы класс Point также использовал FTM, то формально это не было бы проблемой. Тем не менее, в общем случае клиенты (такие, так класс Rect), не должны делать допущений относительно этой специфической исключительно для реализаций детали. Фактически, если объекты Point не используют FTM и окажутся созданными в другом апартаменте из-за несовместимости с ThreadingModel, то в этом случае объект Rect содержал бы указатели на заместители. Известно, что заместители четко следуют правилам СОМ и послушно возвращают RPC_E_WRONG_THREAD в тех случаях, когда к ним обращаются из недопустимого апартамента.

Это оставляет разработчику Rect выбор между двумя возможностями. Одна из них – не использовать FTM и просто принять к сведению, что когда клиенты передают объектные ссылки Rect между апартаментами, то для обращения к экземплярам класса Rect будет использоваться ORPC. Это действительно является простейшим решением, так как оно не добавляет никакого дополнительного кода и будет работать, не требуя умственных усилий. Другая возможность – не содержать исходные интерфейсные указатели как элементы данных, а вместо этого держать в качестве элементов данных некую маршалированную форму интерфейсного указателя. Именно для этого и предназначена глобальная интерфейсная таблица (Global Interface Table – GIT). Для реализации данного подхода в классе Rect следовало бы иметь в качестве элементов данных не исходные интерфейсные указатели, а «закладку» (cookies) DWORD:

class SafeRect : public IRect {

LONG m_cRef;

// СОМ reference count

// счетчик ссылок СОМ IUnknown *m_pUnkFTM;

// cache for FTM lazy aggregate

// кэш для отложенного агрегирования FTM

DWORD m_dwTopLeft;

// GIT cookie for top/left

// закладка GIT для верхнего/левого

DWORD m_dwBottomRight;

// GIT cookie for bottom/right

// закладка GIT для нижнего/правого

Разработчик по-прежнему создает два экземпляра Point, но вместо хранения исходных указателей регистрирует интерфейсные указатели с помощью глобальной таблицы GIT:

SafeRect::SafeRect(void) : m_cRef(0), m_pUnkFTM(0) {

// assume ptr to GIT is initialized elsewhere

// допустим, что указатель на GIT инициализирован

// где-нибудь в другом месте

extern IGIobalInterfaceTable *g_pGIT;

assert(g_pGIT != 0);

IPoint *pPoint = 0;

// create instance of class Point

// создаем экземпляр класса Point HRESULT

hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);

assert (SUCCEEDED (hr));

// register interface pointer in GIT

// регистрируем интерфейсный указатель в GIT

hr = g_pGIT->RegisterInterfaceInGlobal(pPoint, IID_Ipoint, &m_dwTopLeft);

assert(SUCCEEDED(hr));

pPoint->Release();

// reference is now held in GIT

// ссылка теперь содержится в GIT

// create instance of class Point

// создаем экземпляр класса Point

hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);

assert(SUCCEEDED(hr));

// register interface pointer in GIT

// регистрируем интерфейсный указатель в GIT

hr = g_pGIT->RegisterInterfaceInGlobal(pPoint, IID_Ipoint, &m_dwBottomRight);

assert(SUCCEEDED(hr)); pPoint->Release();

// reference is now held in GIT

// ссылка теперь содержится в GIT

}

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

Поскольку класс был преобразован для использования GIT вместо исходных интерфейсных указателей, он должен демаршалировать новый заместитель в каждом вызове метода, которому требуется доступ к зарегистрированным интерфейсам:

STDMETHODIMP SafeRect::get_Area(long *pn) {

extern IGlobalInterfaceTable *g_pGIT; assert(g_pGIT != 0);

// unmarshal the two interface pointers from the GIT

// демаршалируем дВа интерфейсных указателя из GIT

IPoint *ptl = 0, *pbr = 0;

HRESULT hr = g_pGIT->GetInterfaceFromGlobal(m_dwPtTopLeft, IID_Ipoint, (void**)&ptl);

assert (SUCCEEDED(hr));

hr = g_pGIT->GetInterfaceFromGlobal(m_dwPtBottomRight, IID_Ipoint, (void**)&pbr);

// use temp ptrs to implement method

// дпя реализации метода используем временные указатели

long top, left, bottom, right;

hr = ptl->GetCoords(&left, &top);

assert (SUCCEEDED(hr));

hr = pbr->GetCoords(&right, &bottom);

assert (SUCCEEDED (hr));

*pn = (right – left) * (bottom – top);

// release temp ptrs. // освобождаем временные указатели

ptl->Release();

pbr->Release();

return S_OK;

}

Поскольку реализация SafeRect использует FTM, то нецелесообразно пытаться сохранить немаршалированные интерфейсные указатели между вызовами метода, так как неизвестно, произойдет ли следующий вызов метода в том же самом апартаменте.

Все зарегистрированные интерфейсные указатели будут храниться в таблице GIT до тех пор, пока они не будут явно удалены нз GIT. Это означает, что класс SafeRect должен явно аннулировать элементы GIT для двух своих элементов данных:

SafeRect::~SafeRect(void) {

extern IGlobalInterfaceTable *g_pGIT;

assert(g_pGIT != 0);

HRESULT hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwTopLeft);

assert(SUCCEEDED(hr));

hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwBottomRight);

assert(SUCCEEDED(hr));

}

Удаление интерфейсного указателя из GIT освобождает все хранящиеся ссылки на объект.

Отметим, что совместное использование GIT и FTM влечет за собой очень много обращений к GIT, которые будут сделаны для создания временных интерфейсных указателей, необходимых для использования в каждом отдельном методе. Хотя GIT оптимизирована именно для поддержки такой схемы использования, код остается однообразным. Следующий простой класс C++ скрывает использование «закладки» GIT за удобным интерфейсом, обеспечивающим безопасность типа:

template class GlobalInterfacePointer {

DWORD m_dwCookie;

// the GIT cookie

// «закладка» GIT

// prevent misuse

// предотвращаем неправильное использование

GlobalInterfacePointer(const GlobalInterfacePointer&);

void operator =(const GlobalInterfacePointer&);

public:

// start as invalid cookie

// начинаем как неправильная «закладка»

GlobalInterfacePointer(void) : m_dwCookie(0) { }

// start with auto-globalized local pointer

// начинаем с автоматически глобализованным локальным указателем

GlobalInterfacePointer(Itf *pItf, HRESULT& hr) : m_dwCookie(0)

{ hr = Globalize(pItf); }

// auto-unglobalize

// осуществляем автоматическую деглобапизацию

~GlobalInterfacePointer(void) { if(m_dwСооkiе) Unglobalize() ; }

// register an interface pointer in GIT

// регистрируем интерфейсный указатель в GIT

HRESULT Globalize(Itf *pItf) { assert (g_pGIT != 0 && m_dwCookie == 0);

return g_pGIT->RegisterInterfaceInGlobal(pItf, * piid, &m_dwCookie);

}

// revoke an interface pointer in GIT

// аннулируем интерфейсный указатель в GIT

HRESULT Unglobalize(void) {

assert(g_pGIT != 0 && m_dwCookie != 0);

HRESULT hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwCookie);

m_dwCookie = 0;

return hr;

}

// get а local interface pointer from GIT

// получаем локальный интерфейсный указатель из GIT

HRESULT Localize(Itf **ppItf) const {

assert(g_pGIT != 0 && m_dwCookie != 0);

return g_pGIT->GetInteгfaceFromGlobal(m_dwCookie, *piid, (void**)ppItf);

}

// convenience methods

// методы для удобства

bool IsOK(void) const { return m_dwCookie != 0; }

DWORD GetCookie(void) const { return m_dwCookie; }

};

#define GIP(Itf) GlobalInterfacePointer

Имея данное определение класса и макрос, класс SafeRect теперь вместо исходных DWORD сохраняет GlobalInterfacePointers:

class SafeRect : public IRect {

LONG m_cRef:

// СОM reference count

// счетчик ссылок СОМ

IUnknown *m_pUnkFTM;

// cache for FTM lazy aggregate

// кэш дпя отложенного агрегирования FTM

GIP(IPoint) m_gipTopLeft;

// GIT cookie – top/left

// «закладка» GIT для верхнего/левого элемента

GIP(IPoint) m_gipBottomRight;

// GIT cookie – bottom/right

// «закладка» GIT для нижнего/правого элемента

:

:

:

}

Для инициализации элемента GlobalInterfacePointer разработчик (который выполняется в апартаменте объекта) просто регистрирует обрабатываемые указатели, вызывая метод Globalize на каждый GlobalInterfacePointer:

SafeRect::SafeRect(void) : m_cRef (0), m_pUnkFTM(0) {

IPoint *pPoint = 0;

// create instance of class Point

// создаем экземпляр класса Point

HRESULT hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);

assert (SUCCEEDED(hr));

// register interface pointer in GIT

// регистрируем интерфейсный указатель в GIT

hr = m_gipTopLeft.Globalize(pPoint);

assert (SUCCEEDED(hr));

pPoint->Release();

// reference is now held in GIT

// теперь ссыпка хранится в GIT

// create instance of class Point

// создаем экземпляр класса Point

hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Iроint, (void**) &рРоint);

assert(SUCCEEDED(hr));

// register interface pointer in GIT

// регистрируем интерфейсный указатель в GIT

hr = m_gipBottomRight.Globalize(pPoint);

assert (SUCCEEDED (hr));

pPoint->Release();

// reference is now held in GIT

// теперь ссылка хранится в GIT

}

Те методы, которым нужен доступ к глобализованным указателям, могут импортировать локальную копию посредством метода Localize из GlobalInterfaсePointer:

STDMETHODIMP SafeRect::get_Top(long *pVal) {

IPoint *pPoint = 0;

// local imported pointer

// локальный импортированный указатель

HRESULT hr = m_gipTopLeft.Localize(&pPoint);

if (SUCCEEDED(hr)){

long x;

hr = pPoint->get_Coords(&x, pVal);

pPoint->Release(); }

return hr;

}

Отметим, что в силу применения маршалера свободной поточной обработки (FreeThreaded Marshaler) исходный интерфейсный указатель не может быть кэширован, а должен импортироваться при каждом вызове метода, чтобы предотвратить попытку доступа из неверного апартамента.

Предыдущий фрагмент кода может быть автоматизирован еще больше. Поскольку большинство вызовов методов в классе GlobalInterfacePointer должны будут локализовать временный указатель в самом вызове метода, то приводимый ниже класс автоматизирует импорт временного указателя и его последующее освобождение, что очень напоминает интеллектуальный указатель (smart pointer):

template class LocalInterfacePointer {

Itf *m_pItf;

// temp imported pointer

// временный импортированный указатель

// prevent misuse

// предотвращаем неверное использование

LocalInterfacePointer(const LocalInterfacePointer&);

operator = (const LocalInterfacePointer&);

public:

LocalInterfacePointer(const GlobalInterfacePointer& rhs, HRESULT& hr) { hr = rhs.Loca1ize(&m_pItf) ; }

LocalInterfacePointer(DWORD dwCookie, HRESULT& hr) { assert(g_pGIT != 0);

hr = g_pGIT->GetInterfaceFromGlobal(dwCookie, *piid, (void**)&m_pItf); }

~LocalInterfacePointer(void) { if (m_pItf) m_pItf->Release(); }

class SafeItf : public Itf { STDMETHOD_(ULONG, AddRef) (void) = 0;

// hide

// скрытый STDMETHOD_(ULONG, Release)(void) = 0;

// hide

// скрытый

};

SafeItf *GetInterface(void) const { return (SafeItf*) m_pItf; }

SafeItf *operator ->(void) const { assert(m_pItf != 0);

return GetInterface();

}

};

#def1ne LIP(Itf) LocalInterfacePointer

С получением этого второго класса C++ обработка импортированных указателей становится намного проще:

STDMETHODIMP SafeRect::get_Area(long *pn) {

long top, left, bottom, right;

HRESULT hr, hr2;

// import pointers

// импортируем указатели

LIP(IPoint) lipTopLeft(m_gipTopLeft, hr);

LIP(IPoint) lipBottomRight(m_gipBottomRight, hr2);

assert(SUCCEEDED(hr) && SUCCEEDED(hr2));

// use temp tocal pointers

// используем временные локальные указатели

hr = lipTopLeft->GetCoords(&left, &top);

hr2 = lipBottomRight->GetCoords(&right, &bottom);

assert(SUCCEEDED(hr) && SUCCEEDED(hr2));

*pn = (right – left) * (bottom – top); return S_OK;

// LocalInterfacePointer auto-releases temp ptrs.

// LocalInterfacePointer сам освобождает

// временные указатели

}

Макросы GIP и LIP делают совместное использование GIT и FTM намного менее громоздким. До появления GIT использование FTM в классе с интерфейсными указателями было значительно более трудным, чем теперь обеспечивает любой из кодов, приведенных в данном разделе.

 

Где мы находимся?

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

 

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

 

Подводные камни внутрипроцессной активации

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

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

Еще один подводный камень при внутрипроцессной активации состоит в том, что она не позволяет производить распределенные вычисления. Если объект должен быть активирован в адресном пространстве клиента, то по определению он разделит CPU (central processor unit – центральный процессор) и другие локальные ресурсы с клиентом. Внутрипроцессная активация также делает затруднительным совместное использование одного и того же объекта несколькими клиентскими процессами. Хотя понятие апартамента и допускает экспорт объектных ссылок из любого процесса (включая и те процессы, которые по традиции рассматривались как клиентские), тем не менее, трудно представить себе семантику активации для совместного использования внутрипроцессного экземпляра.

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

 

Активация и SCM

Диспетчер управления COM-сервисами (Service Control Manager – SCM ) обеспечивает связь между CLSID и серверными процессами в реестре. Это позволяет SCM запускать серверный процесс при поступлении клиентских запросов на активацию. Если предположить, что код для класса будет упакован как образ процесса (ЕХЕ), а не как DLL, то достаточно использовать ключ реестра LocalServer32 вместо InprocServer32, как показано в следующем примере:

[HKCR\CLSID\{27EE6A26-DF65-11d0-8C5F-0080C73925BA}] @="Gorillaquot;

[HKCR\CLSID\{27EE6A26-DF65-11d0-8C5F-0080C73925BA}\LocalServer32] @="C:\ServerOfTheApes.exe"

Ожидается, что внепроцессный сервер установит эти ключи во время самоинсталляции. В отличие от своих внутрипроцессных аналогов, внепроцессные серверы не экспортируют известные библиотеки DllRegisterServer и DllUnregisterServer. Вместо этого внепроцессный сервер должен проверить командную строку на наличие известных ключей /RegServer и /UnregServer. Имея вышеуказанные элементы реестра, SCM начнет новый серверный процесс с использованием файла ServerOfTheApes.ехе, при первом запросе на активацию класса Gorilla. После этого извещение SCM о том, какие классы фактически являются доступными из нового процесса, будет обязанностью серверного процесса.

Как уже рассматривалось в главе 3, процессы могут контактировать с SCM для связывания ссылок на объекты класса, экземпляров класса и постоянных экземпляров. Для осуществления этого в COM предусмотрены три функции активации (CoGetClassObject, CoCreateInstanceEx и CoGetInstanceFromFile). Они, как и высокоуровневые моникеры, предназначены для того, чтобы скрыть детали реализации каждой стратегии связывания. В каждой из этих трех стратегий активации для вызова объекта к жизни используется объект класса. Как уже рассматривалось в главе 3, когда активация объекта осуществляется внутри процесса, DLL класса загружается самой COM, а для выборки соответствующих объектов класса используется известная точка входа DllGetClassObject. Однако пока не рассматривалось, как объекты могут быть активированы через границы процессов.

Процесс становится серверным процессом для определенного класса после явной саморегистрации с помощью SCM. После такой регистрации любые активационные запросы класса, для которых необходима внепроцессная активация, будут отосланы к зарегистрированному серверному процессу. Серверные процессы саморегистрируются с помощью SCM API-функции CoRegisterClassObject:

HRESULT CoRegisterClassObject(

[in] REFCLSID rclsid,

// which class?

// какой класс?

[in] IUnknown *pUnkClassObject,

// ptr to class object

// указатель на объект класса

[in] DWORD dwClsCtx,

// locality

// локализация

[in] DWORD dwRegCls,

// activation flags

// флаги активации

[out] DWORD *pdwReg);

// association ID

// ID связи

При вызове CoRegisterClassObject библиотека COM сохраняет ссылку на объект класса, указанную в качестве второго параметра, и связывает объект класса с его CLSID в организованной внутри библиотеки таблице. В зависимости от флагов активации, использованных при вызове, библиотека COM может также сообщать локальному SCM, что вызывающий процесс является теперь серверным процессом для указанного класса. CoRegisterClassObject возвращает двойное слово (DWORD), которое представляет связь между CLSID и объектом класса. Это двойное слово можно использовать для завершения связи (а также для извещения SCM о том, что вызывающий процесс более не является серверным процессом для данного CLSID) путем вызова API-функции CoRevokeClassObject:

HRESULT CoRevokeClassObject([in] DWORD dwReg);

// association ID

// ID связи

Два параметра типа DWORD являются примером тонкого устройства CoRegisterClassObject . Эти параметры дают вызывающему объекту контроль над тем, как и когда объект класса является доступным.

А каким образом и на какой срок сделать доступным объект класса, вызывающему объекту позволяют решить флаги активации, передающиеся CoRegisterСlassObject в качестве четвертого параметра. COM предусматривает следующие константы для использования в этом параметре:

typedef enum tagREGCLS {

REGCLS_SINGLEUSE = 0,

// give out class object once

// выделяем объект класса однократно

REGCLS_MULTIPLEUSE = 1,

// give out class object many

// выделяем объект класса многократно

REGCLS_MULTI_SEPARATE = 2,

// give out class object many

// выделяем объект класса многократно

REGCLS_SUSPENDED = 4,

// do not notify SCM (flag)

// не извещаем SCM (флаг) REGCLS_SURROGATE = 8 // used with DLL Surrogates // используется с суррогатами DLL } REGCLS;

Значение REGCLS_SURROGATE используется в реализациях суррогатов DLL, которые будут рассматриваться позднее в данной главе. Двумя основными значениями являются REGCLS_SINGLEUSE и REGCLS_MULTIPLEUSE. Первое предписывает библиотеке COM использовать объект класса для обслуживания только одного активационного запроса. Когда происходит первый активационный запрос, COM удаляет зарегистрированный объект класса из области открытой видимости (public view). Если придет второй активационный запрос, COM должна использовать другой зарегистрированный объект класса. Если больше не доступен ни один объект класса с тем же CLSID, то для удовлетворения этого запроса COM создаст другой серверный процесс.

Напротив, флаг REGCLS_MULTIPLEUSE показывает, что объект класса может быть использован многократно, до тех пор, пока вызов функции CoRevokeСlassObject не удалит его элемент из таблицы класса библиотеки COM. Флаг REGCLS_MULTI_SEPARATE адресует последующие внутрипроцессные активационные запросы, которые могут произойти в процессе вызывающего объекта. Если вызывающий объект регистрирует объект класса с флагом REGCLS_MULTIPLEUSE, то COM допускает, что любые внутрипроцессные активационные запросы от процесса вызывающего объекта не будут загружать отдельный внутрипроцессный сервер, а будут вместо этого использовать зарегистрированный объект класса. Это означает, что даже если вызывающая программа только зарегистрировала объект класса с флагом CLSCTX_LOCAL_SERVER, то для удовлетворения внутрипроцессных запросов от того же процесса будет использован зарегистрированный объект класса. Если такое поведение неприемлемо, вызывающая программа может зарегистрировать объект класса, используя флаг REGCLS_MULTI_SEPARATE. Флаг инструктирует COM использовать зарегистрированный объект класса для внутрипроцессных запросов только в случае, если для регистрации этого класса был использован флаг CLSCTX_INPROC_SERVER . Это означает, что следующий вызов CoRegisterClassObject:

hr = CoRegisterClassObject(CLSID_Me, &g_coMe, CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE, &dw);

эквивалентен следующему:

hr = CoRegisterClassObject(CLSID_Me, &g_coMe, CLSCTX_LOCAL_SERVER | CLSCTX_INPROC, REGCLS_MULTI_SEPARATE, &dw);

В любом случае, если бы из процесса вызывающего объекта был осуществлен такой вызов:

hr = CoGetClassObject(CLSID_Me, CLSCTX_INPROC, 0, IID_IUnknown, (void**)&pUnkCO);

то никакая DLL не была бы загружена. Вместо этого COM удовлетворила бы запрос, используя объект класса, зарегистрированный посредством CoRegisterClassObject. Если, однако, серверный процесс вызвал CoRegisterClassObject таким образом:

hr = CoRegisterClassObject(CLSID_Me, &g_coMe, CLSCTX_LOCAL_SERVER, REGCLS_MULTI_SEPARATE, &dw);

то любые внутрипроцессные запросы на активацию CLSID_Me, исходящие изнутри серверного процесса, заставят DLL загрузиться.

CoRegisterClassObject связывает зарегистрированный объект класса с апартаментом вызывающего объекта. Это означает, что все поступающие запросы методов будут выполняться в апартаменте вызывающей программы. В частности, это означает, что если объект класса экспортирует интерфейс IClassFactory, то метод CreateInstance будет выполняться в апартаменте вызывающей программы. Результаты метода CreateInstance будут маршалированы из апартамента объекта класса, а это, в свою очередь, означает, что экземпляры класса будут принадлежать к тому же апартаменту, что и объект класса.

Серверные процессы могут регистрировать объекты класса для более чем одного класса. Если объекты класса зарегистрированы для выполнения в МТА процесса, то это означает, что поступающие запросы на активацию могут быть обслужены, как только будет завершен первый вызов CoRegisterClassObject. Во многих серверных процессах, основанных на МТА, это может вызвать проблемы, так как бывает, что процесс должен выполнить дальнейшую инициализацию. Чтобы избежать этой проблемы, в реализации COM под Windows NT 4.0 введен флаг REGCLS_SUSPENDED. При добавлении этого флага в вызов CoRegisterСlassObject библиотека COM не извещает SCM о том, что класс доступен. Это предотвращает поступление в серверный процесс входящих активационных запросов. Библиотека COM связывает CLSID с объектом класса; однако она помечает этот элемент в таблице библиотеки класса как отложенный. Для снятия этой пометки в COM предусмотрена API-функция CoResumeClassObjects:

HRESULT CoResumeClassObjects(void);

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

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

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) {

// define a singleton class object for each class

// определяем синглетон для каждого класса

static GorillaClass s_gorillaClass; static OrangutanClass s_orangutanClass;

static ChimpClass s_chimpClass; DWORD rgdwReg[3];

const DWORD dwRegCls = REGCLS_MULTIPLEUSE | REGCLS_SUSPENDED;

const DWORD dwClsCtx = CLSCTX_LOCAL_SERVER;

// enter the MTA

// входим в МТА

HRESULT hr = GoInitializeEx(0, COINIT_MULTITHREADED);

assert(SUCCEEDED(hr));

// register class objects with СОM library's class table

// регистрируем объекты класса с помощью

// таблицы класса библиотеки COM

hr = CoRegisterClassObject(CLSID_Gorilla, &s_gorillaClass, dwClsCtx, dwRegCls, rgdwReg);

assert(SUCCEEDED(hr));

hr = CoRegisterClassObject(CLSID_Orangutan, &s_orangutanClass, dwClsCtx, dwRegCls, rgdwReg + 1);

assert(SUCCEEDED(hr)) ;

hr = CoRegisterClassObject(CLSID_Chimp, &s_chimpClass, dwClsCtx, dwRegCls, rgdwReg + 2);

assert(SUCCEEDED(hr));

// notify the SCM

// извещаем SCM

hr = CoResumeClassObjects();

assert(SUCCEEDED(hr));

// keep process alive until event is signaled

// сохраняем процессу жизнь, пока событие не наступило

extern HANDLE g_heventShutdown; WaitForSingleObject(g_heventShutdown, INFINITE);

// remove entries from COM library's class table

// удаляем элементы из таблицы класса библиотеки COM

for (int n = 0; n < 3; n++)

CoRevokeClassObject(rgdwReg[n]);

// leave the MTA

// покидаем MTA CoUninitialize();

return 0;

}

В данном фрагменте кода предполагается, что событие (Win32 Event object) будет инициализировано где-нибудь еще внутри процесса таким образом:

HANDLE g_heventShutdown = CreateEvent(0, TRUE, FALSE, 0);

Имея данное событие, сервер может быть мирно остановлен с помощью вызова API-функции SetEvent:

SetEvent(g_heventShutdown);

которая запустит последовательность выключения в главном потоке. Если бы сервер был реализован как сервер на основе STA, то главный поток должен был бы вместо ожидания события Win32 Event запустить конвейер обработки оконных сообщений (windows message pump). Это необходимо для того, чтобы позволить поступающим ORPC-запросам входить в апартамент главного потока.

 

Снова о времени жизни сервера

В примере, показанном в предыдущем разделе, не было точно показано, как и когда должен прекратить работу серверный процесс. В общем случае серверный процесс сам контролирует свое время жизни и может прекратить работу в любой выбранный им момент. Хотя для серверного процесса и допустимо неограниченное время работы, большинство из них предпочитают выключаться, когда не осталось неосвобожденных ссылок на их объекты или объекты класса. Это аналогично стратегии, используемой большинством внутрипроцессных серверов в их реализации DllCanUnloadNow. Напомним, что в главе 3 говорилось, что обычно сервер реализует две подпрограммы, вызываемые в качестве интерфейсных указателей, которые запрашиваются и освобождаются внешними клиентами:

// reasons to remain loaded

// причины оставаться загруженными

LONG g_cLocks = 0;

// called from AddRef + IClassFactory::LockServer(TRUE)

// вызвано из AddRef + IClassFactory::LockServer(TRUE)

void LockModule(void) {

InterlockedIncrement(&g_cLocks);

}

// called from Release + IClassFactory::LockServer(FALSE)

// вызвано из Release + IClassFactory::LockServer(FALSE)

void UnlockModule(void) {

InterlockedDecrement(&g_cLocks);

}

Это сделало реализацию DllCanUnloadNow предельно простой:

STDAPI DllCanUnloadNow() { return g_cLocks ? S_FALSE : S_OK; }

Подпрограмму DllCanUnloadNow нужно вызывать в случаях, когда клиент решил «собрать мусор» в своем адресном пространстве путем вызова CoFreeUnusedLibraries для освобождения неиспользуемых библиотек.

Имеются некоторые различия в том, как ЕХЕ-серверы прекращают работу серверов. Во-первых, обязанностью серверного процесса является упреждающее инициирование процесса своего выключения. В отличие от внутрипроцессных серверов, здесь не существует «сборщика мусора», который запросил бы внепроцессный сервер, желает ли он прекратить работу. Вместо этого серверный процесс должен в подходящий момент явно запустить процесс своего выключения. Если для выключения сервера используется событие Win32 Event, то процесс должен вызвать API-функцию SetEvent:

void UnlockModule(void) {

if (InterlockedDecrement(&g_cLocks) ==0)

{

extern HANDLE g_heventShutdown;

SetEvent(g_heventShutdown);

}

}

Если вместо серверного основного потока обслуживается очередь событий Windows MSG , то для прерывания цикла обработки сообщений следует использовать некоторые из API-функций. Проще всего использовать PostThreadMessage для передачи в основной поток сообщения WM_QUIT:

void UnlockModule(void) {

if (InterlockedDecrement(&g_cLocks) == 0) {

extern DWORD g_dwMainThreadID;

// set from main thread

// установлено из основного потока

PostThreadMessage(g_dwMainThreadID, WNLQUIT, 0, 0);

}

}

Если серверный процесс на основе STA знает, что он никогда не будет создавать дополнительные потоки, то он может использовать несколько более простую API-функцию PostQuitMessage:

void UnlockModule(void) {

if (InterlockedDecrement(&g_cLocks) == 0) PostQuitMessage(0);

}

Этот способ работает только при вызове из главного потока серверного процесса.

Второе различие в управлении временем жизни внутрипроцессного и внепроцессного сервера связано с тем, что должно поддерживать сервер в загруженном или работающем состоянии. В случае внутрипроцессного сервера такой силой обладают неосвобожденные ссылки на объекты и неотмененные вызовы IClassFactory::LockServer(TRUE). Неосвобожденные ссылки на объекты необходимо рассмотреть в контексте внепроцессного сервера.

Безусловно, сервер должен оставаться доступным до тех пор, пока внешние клиенты имеют неосвобожденные ссылки на объекты класса сервера. Для внутрипроцессного сервера это реализуется следующим образом:

STDMETHODIMP_(ULONG) MyClassObject::AddRef(void) {

LockModule();

// note outstanding reference

// отмечаем неосвобожденную ссылку

return 2;

// non-heap-based object

// объект, размещенный не в «куче»

}

STDMETHODIMP_(ULONG) MyClassObject::Release(void) {

UnlockModule();

// note destroyed reference

// отмечаем уничтоженную ссылку

return 1;

// non-heap-based object

// объект, размещенный не в «куче»

}

Такое поведение является обязательным, поскольку если DLL выгружается, несмотря на оставшиеся неосвобожденные ссылки на объекты класса, то даже последующие вызовы метода Release приведут клиентский процесс к гибели.

К сожалению, предшествующая реализация AddRef и Release не годится для внепроцессных серверов. Напомним, что после входа в апартамент COM первое, что делает типичный внепроцессный сервер, – регистрирует свои объекты класса с помощью библиотеки COM путем вызова CoRegisterClassObject. Тем не менее, пока таблица класса сохраняет объект класса, существует по меньшей мере одна неосвобожденная ссылка COM на объект класса. Это означает, что после регистрации своих объектов класса счетчик блокировок всего модуля будет отличен от нуля. Эти самоустановленные (self-imposed) ссылки не будут освобождены до вызова серверным процессом CoRevokeClassObject. К сожалению, типичный серверный процесс не вызовет CoRevokeClassObject до тех пор, пока счетчик блокировок всего модуля не достигнет нуля, что означает, что серверный процесс никогда не прекратится.

Чтобы прервать циклические отношения между таблицей класса и временем жизни сервера, большинство внепроцессных реализации объектов класса попросту игнорируют неосвобожденные ссылки на AddRef и Release:

STDMETHODIMP_(ULONG) MyClassObject::AddRef(void) {

// ignore outstanding reference

// игнорируем неосвобожденную ссылку

return 2;

// non-heap-based object

// объект, размещенный не в «куче»

}

STDMETHODIMP_(ULONG) MyClassObject::Release(void) {

// ignore destroyed reference

// игнорируем уничтоженную ссылку

return 1;

// non-heap-based object

//объект, размещенный не в «куче»

}

Это означает, что после регистрации объектов своего класса счетчик блокировок всего модуля останется на нуле.

На первый взгляд такая реализация означает, что серверный процесс может прекратить работу, несмотря на то, что существуют неосвобожденные ссылки на объекты его класса. Такое поведение фактически зависит от реализации объекта класса. Напомним, что сервер должен продолжать работу до тех пор, пока на объекты его класса есть внешние ссылки. Предшествующие модификации AddRef и Release влияют только на внутренние ссылки, которые хранятся в таблице классов библиотеки COM и поэтому игнорируются. Когда внешний клиент запрашивает ссылку на один из объектов класса серверного процесса, SCM входит в апартамент объекта класса для отыскания там ссылки на объект класса. В это время делается вызов CoMarshalInterface для сериализации объектной ссылки с целью использования ее клиентом. Если объект класса реализует интерфейс IExternalConnection, то он может заметить, что внешние ссылки являются неосвобожденными, и использовать эти сведения для управления временем жизни сервера. Если предположить, что объект класса реализует интерфейс IExternalConnection, тo следующий код достигает желаемого эффекта:

STDMETHODIMP_(DWORD) MyClassObject::AddConnection(DWORD extconn, DWORD) {

DWORD res = 0;

if (extconn & EXTCONN_STRONG) {

LockModule();

// note external reference

// записываем внешнюю ссылку

res = InterlockedIncrement(&m_cExtRef);

}

return res;

}

STDMETHODIMP_(DWORD) MyClassObject::ReleaseConnection(DWORD extconn, DWORD, BOOL bLastReleaseKillsStub)

{

DWORD res = 0;

if (extconn & EXTCONN_STRONG) {

UnlockModule();

// note external reference

// записываем внешнюю ссылку

res = InterlockedDecrement(&m_cExtRef);

if (res == 0 & bLastReleaseKillsStub)

CoDisconnectObject((IExternalConnection*)this, 0);

}

return res;

}

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

Хотя технология использования IExternalConnection для объектов класса существовала в COM с самых первых дней, лишь немногие разработчики используют ее на деле. Вместо этого большинство серверов обычно игнорируют неосвобожденные внешние ссылки на объекты класса и завершают серверные процессы преждевременно. Этому положению способствовало присутствие метода LockServer в интерфейсе IClassFactory, который внушает разработчикам мысль, что клиенты будто бы способны в действительности обеспечить выполнение сервера. В то время как большинство разработчиков серверов успешно запирают модуль в методах LockServer, для клиента не существовало надежного способа вызвать данный метод. Рассмотрим следующий клиентский код: IClassFactory *pcf = 0;

HRESULT hr = CoGetClassObject(CLSID_You, CLSCTX_LOCAL_SERVER, О, IID_IClassFactory, (void**)&pcf);

if (SUCCEEDED(hr)) hr = pcf->LockServer(TRUE);

// keep server running?

// поддерживать выполнение сервера?

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

IClassFactory *pcf = 0;

HRESULT hr = S_OK;

do {

if (pcf) pcf->Release();

hr = CoGetClassObject(CLSID_You, CLSCTX_LOCAL_SERVER, 0, IID_IClassFactory, (void**)&pcf);

if (FAILED(hr)) break;

hr = pcf->LockServer(TRUE);

// keep server running?

// поддерживать выполнение сервера?

} while (FAILED(hr));

Отметим, что данный фрагмент кода периодически пытается подсоединиться к объекту класса и заблокировать его, пока вызов LockServer проходит успешно. Если сервер завершит работу преждевременно – между вызовами CoGetClassObject и LockServer , то вызов LockServer возвратит сообщение об ошибке, извещающее об отсоединенном заместителе, что вызовет повтор последовательности. Под Windows NT 3.51 и в более ранних версиях этот нелепый код был единственным надежным способом получения ссылки на объект класса.

Был признан тот факт, что многие реализации серверов не использовали IExternalConnection для должного управления временем жизни сервера, и в версии COM под Windows NT 4.0 введена следующая модернизация для замены этих наивных реализаций. При маршалинге ссылки на объект класса в ответ на вызов CoGetClass0bject SCM вызовет метод объекта класса IClassFactory::LockServer. С тех пор как значительное большинство серверов реализуют IClassFactory в своих объектах класса, эта модернизация исполняемых программ COM исправляет значительное количество дефектов. Однако если объект класса не экспортирует интерфейс IClassFactoryили если сервер должен выполняться и в более ранних версиях COM, чем Windows NT 4.0, то необходимо использовать технологию IExternalConnection.

Следует обсудить еще одну проблему, относящуюся ко времени жизни сервера. Отметим, что когда сервер решает прекратить работу, то он сообщает о том, что главный поток серверного приложения должен начать свою последовательность операций останова (shutdown sequence ) до выхода из процесса. Частью этой последовательности операций останова является вызов CoRevokeClassObject для отмены регистрации его объектов класса. Если, однако, были использованы показанные ранее реализации UnlockModule, то появляются условия серьезной гонки. Возможно, что в промежутке между тем моментом, когда сервер сигнализирует главному потоку посредством вызова SetEvent или PostThreadMessage, и тем моментом, когда сервер аннулирует объекты своего класса, вызывая CoRevokeClassObject , в серверный процесс поступят дополнительные запросы на активацию. Если в этот интервал времени создаются новые объекты, то уже нет способа сообщить главному потоку, что прекращение работы – плохая идея и что у процесса появились новые объекты для обслуживания. Для устранения этих условий гонки в COM предусмотрены две API-функции: ULONG CoAddRefServerProcess(void); ULONG CoReleaseServerProcess(void);

Эти две подпрограммы управляют счетчиком блокировок модуля от имени вызывающего объекта. Эти подпрограммы временно блокируют любой доступ к библиотеке COM, чтобы гарантировать, что во время установки счетчика блокировок новые активационные запросы не будут обслуживаться. Кроме того, если функция CoReleaseServerProcess обнаружит, что удаляется последняя блокировка в процессе, то она изнутри пометит все объекты класса в процессе как приостановленные и сообщит SCM, что процесс более не является сервером для его CLSID.

Следующие подпрограммы корректно реализуют время жизни сервера во внепроцессном сервере:

void LockModule(void) {

CoAddRefServerProcess();

// COM maintains lock count

// COM устанавливает счетчик блокировок

}

void UnlockModule(void) {

if (CoReleaseServerProcess() == 0)

SetEvent(g_heventShutdown);

}

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

Даже при использовании функций CoAddRefServerProcess / CoReleaseServerProcess все еще остаются возможности для гонки. Возможно, что во время выполнения CoReleaseServerProcess на уровне RPC будет получен входящий запрос на активацию от SCM. Если вызов от SCM диспетчеризован после того, как функция CoReleaseServerProcess снимает свою блокировку библиотеки COM, то активационный запрос отметит, что объект класса уже помечен как приостановленный, и в SCM будет возвращено сообщение об ошибке со специфическим кодом (CO_E_SERVER_STOPPING ). Когда SCM обнаруживает этот специфический код, он просто запускает новый экземпляр серверного процесса и повторяет запрос, как только новый серверный процесс зарегистрирует себя. Несмотря на системы защиты, используемые библиотекой COM, остается вероятность того, что поступающий активационный запрос будет выполняться одновременно с заключительным вызовом функции CoReleaseServerProcess. Чтобы избежать этого, сервер может явно возвратить CO_E_SERVER_STOPPING как из IClassFactory::Create Instance, так и из IPersistFile::Load в том случае, если он определит, что по окончании запроса на прекращение работы был сделан еще какой-то запрос. Следующий код демонстрирует этот способ:

STDMETHODIMP MyClassObject::CreateInstance(IUnknown *puo, REFIID riid, void **ppv) {

LockModule();

// ensure we don't shut down while in call

// убеждаемся в том, что не прекращаем работу

// во время вызова

HRESULT hr; *ppv = 0;

// shutdown initiated?

// процесс останова запущен?

DWORD dw = WaitForSingleObject(g_heventShutdown, 0);

if (dw == WAIT_OBJECT_0) hr = CO_E_SERVER_STOPPING;

else {

// normal CreateInstance implementation

// нормальная реализация CreateInstance

}

UnlockModule();

return hr;

}

Во время написания этого текста ни одна из коммерческих библиотек классов COM не реализовывала этот способ.

 

Снова о времени жизни сервера

В примере, показанном в предыдущем разделе, не было точно показано, как и когда должен прекратить работу серверный процесс. В общем случае серверный процесс сам контролирует свое время жизни и может прекратить работу в любой выбранный им момент. Хотя для серверного процесса и допустимо неограниченное время работы, большинство из них предпочитают выключаться, когда не осталось неосвобожденных ссылок на их объекты или объекты класса. Это аналогично стратегии, используемой большинством внутрипроцессных серверов в их реализации DllCanUnloadNow. Напомним, что в главе 3 говорилось, что обычно сервер реализует две подпрограммы, вызываемые в качестве интерфейсных указателей, которые запрашиваются и освобождаются внешними клиентами:

// reasons to remain loaded

// причины оставаться загруженными

LONG g_cLocks = 0;

// called from AddRef + IClassFactory::LockServer(TRUE)

// вызвано из AddRef + IClassFactory::LockServer(TRUE)

void LockModule(void) {

InterlockedIncrement(&g_cLocks);

}

// called from Release + IClassFactory::LockServer(FALSE)

// вызвано из Release + IClassFactory::LockServer(FALSE)

void UnlockModule(void) { InterlockedDecrement(&g_cLocks);

}

Это сделало реализацию DllCanUnloadNow предельно простой:

STDAPI DllCanUnloadNow()

{

return g_cLocks ? S_FALSE : S_OK;

}

Подпрограмму DllCanUnloadNow нужно вызывать в случаях, когда клиент решил «собрать мусор» в своем адресном пространстве путем вызова CoFreeUnusedLibraries для освобождения неиспользуемых библиотек.

Имеются некоторые различия в том, как ЕХЕ-серверы прекращают работу серверов. Во-первых, обязанностью серверного процесса является упреждающее инициирование процесса своего выключения. В отличие от внутрипроцессных серверов, здесь не существует «сборщика мусора», который запросил бы внепроцессный сервер, желает ли он прекратить работу. Вместо этого серверный процесс должен в подходящий момент явно запустить процесс своего выключения. Если для выключения сервера используется событие Win32 Event, то процесс должен вызвать API-функцию SetEvent:

void UnlockModule(void) {

if (InterlockedDecrement(&g_cLocks) ==0) {

extern HANDLE g_heventShutdown;

SetEvent(g_heventShutdown);

}

}

Если вместо серверного основного потока обслуживается очередь событий Windows MSG, то для прерывания цикла обработки сообщений следует использовать некоторые из API-функций. Проще всего использовать PostThreadMessage для передачи в основной поток сообщения WM_QUIT:

void UnlockModule(void) {

if (InterlockedDecrement(&g_cLocks) == 0) {

extern DWORD g_dwMainThreadID;

// set from main thread

// установлено из основного потока

PostThreadMessage(g_dwMainThreadID, WNLQUIT, 0, 0);

}

}

Если серверный процесс на основе STA знает, что он никогда не будет создавать дополнительные потоки, то он может использовать несколько более простую API-функцию PostQuitMessage:

void UnlockModule(void) {

if (InterlockedDecrement(&g_cLocks) == 0) PostQuitMessage(0);

}

Этот способ работает только при вызове из главного потока серверного процесса.

Второе различие в управлении временем жизни внутрипроцессного и внепроцессного сервера связано с тем, что должно поддерживать сервер в загруженном или работающем состоянии. В случае внутрипроцессного сервера такой силой обладают неосвобожденные ссылки на объекты и неотмененные вызовы IClassFactory::LockServer(TRUE). Неосвобожденные ссылки на объекты необходимо рассмотреть в контексте внепроцессного сервера.

Безусловно, сервер должен оставаться доступным до тех пор, пока внешние клиенты имеют неосвобожденные ссылки на объекты класса сервера. Для внутрипроцессного сервера это реализуется следующим образом:

STDMETHODIMP_(ULONG) MyClassObject::AddRef(void) {

LockModule();

// note outstanding reference

// отмечаем неосвобожденную ссылку

return 2;

// non-heap-based object

// объект, размещенный не в «куче»

}

STDMETHODIMP_(ULONG) MyClassObject::Release(void) {

UnlockModule();

// note destroyed reference

// отмечаем уничтоженную ссылку

return 1;

// non-heap-based object

// объект, размещенный не в «куче»

}

Такое поведение является обязательным, поскольку если DLL выгружается, несмотря на оставшиеся неосвобожденные ссылки на объекты класса, то даже последующие вызовы метода Release приведут клиентский процесс к гибели.

К сожалению, предшествующая реализация AddRef и Release не годится для внепроцессных серверов. Напомним, что после входа в апартамент COM первое, что делает типичный внепроцессный сервер, – регистрирует свои объекты класса с помощью библиотеки COM путем вызова CoRegisterClassObject. Тем не менее, пока таблица класса сохраняет объект класса, существует по меньшей мере одна неосвобожденная ссылка COM на объект класса. Это означает, что после регистрации своих объектов класса счетчик блокировок всего модуля будет отличен от нуля. Эти самоустановленные (self-imposed) ссылки не будут освобождены до вызова серверным процессом CoRevokeClassObject. К сожалению, типичный серверный процесс не вызовет CoRevokeClassObject до тех пор, пока счетчик блокировок всего модуля не достигнет нуля, что означает, что серверный процесс никогда не прекратится.

Чтобы прервать циклические отношения между таблицей класса и временем жизни сервера, большинство внепроцессных реализации объектов класса попросту игнорируют неосвобожденные ссылки на AddRef и Release:

STDMETHODIMP_(ULONG) MyClassObject::AddRef(void) {

// ignore outstanding reference

// игнорируем неосвобожденную ссылку

return 2;

// non-heap-based object

// объект, размещенный не в «куче»

}

STDMETHODIMP_(ULONG) MyClassObject::Release(void) {

// ignore destroyed reference

// игнорируем уничтоженную ссылку

return 1;

// non-heap-based object

//объект, размещенный не в «куче»

}

Это означает, что после регистрации объектов своего класса счетчик блокировок всего модуля останется на нуле.

На первый взгляд такая реализация означает, что серверный процесс может прекратить работу, несмотря на то, что существуют неосвобожденные ссылки на объекты его класса. Такое поведение фактически зависит от реализации объекта класса. Напомним, что сервер должен продолжать работу до тех пор, пока на объекты его класса есть внешние ссылки. Предшествующие модификации AddRef и Release влияют только на внутренние ссылки, которые хранятся в таблице классов библиотеки COM и поэтому игнорируются. Когда внешний клиент запрашивает ссылку на один из объектов класса серверного процесса, SCM входит в апартамент объекта класса для отыскания там ссылки на объект класса. В это время делается вызов CoMarshalInterface для сериализации объектной ссылки с целью использования ее клиентом. Если объект класса реализует интерфейс IExternalConnection, то он может заметить, что внешние ссылки являются неосвобожденными, и использовать эти сведения для управления временем жизни сервера. Если предположить, что объект класса реализует интерфейс IExternalConnection, тo следующий код достигает желаемого эффекта:

STDMETHODIMP_(DWORD) MyClassObject::AddConnection(DWORD extconn, DWORD) {

DWORD res = 0;

if (extconn & EXTCONN_STRONG) {

LockModule();

// note external reference

// записываем внешнюю ссылку

res = InterlockedIncrement(&m_cExtRef);

}

return res;

}

STDMETHODIMP_(DWORD) MyClassObject::ReleaseConnection(DWORD extconn, DWORD, BOOL bLastReleaseKillsStub) {

DWORD res = 0;

if (extconn & EXTCONN_STRONG) {

UnlockModule();

// note external reference

// записываем внешнюю ссылку

res = InterlockedDecrement(&m_cExtRef);

if (res == 0 & bLastReleaseKillsStub) CoDisconnectObject((IExternalConnection*)this, 0);

}

return res;

}

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

Хотя технология использования IExternalConnection для объектов класса существовала в COM с самых первых дней, лишь немногие разработчики используют ее на деле. Вместо этого большинство серверов обычно игнорируют неосвобожденные внешние ссылки на объекты класса и завершают серверные процессы преждевременно. Этому положению способствовало присутствие метода LockServer в интерфейсе IClassFactory, который внушает разработчикам мысль, что клиенты будто бы способны в действительности обеспечить выполнение сервера. В то время как большинство разработчиков серверов успешно запирают модуль в методах LockServer, для клиента не существовало надежного способа вызвать данный метод. Рассмотрим следующий клиентский код:

IClassFactory *pcf = 0;

HRESULT hr = CoGetClassObject(CLSID_You, CLSCTX_LOCAL_SERVER, О, IID_IClassFactory, (void**)&pcf);

if (SUCCEEDED(hr)) hr = pcf->LockServer(TRUE);

// keep server running?

// поддерживать выполнение сервера?

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

IClassFactory *pcf = 0;

HRESULT hr = S_OK;

do {

if (pcf) pcf->Release();

hr = CoGetClassObject(CLSID_You, CLSCTX_LOCAL_SERVER, 0, IID_IClassFactory, (void**)&pcf);

if (FAILED(hr)) break;

hr = pcf->LockServer(TRUE);

// keep server running?

// поддерживать выполнение сервера?

}

while (FAILED(hr));

Отметим, что данный фрагмент кода периодически пытается подсоединиться к объекту класса и заблокировать его, пока вызов LockServer проходит успешно. Если сервер завершит работу преждевременно – между вызовами CoGetClassObject и LockServer, то вызов LockServer возвратит сообщение об ошибке, извещающее об отсоединенном заместителе, что вызовет повтор последовательности. Под Windows NT 3.51 и в более ранних версиях этот нелепый код был единственным надежным способом получения ссылки на объект класса.

Был признан тот факт, что многие реализации серверов не использовали IExternalConnection для должного управления временем жизни сервера, и в версии COM под Windows NT 4.0 введена следующая модернизация для замены этих наивных реализаций. При маршалинге ссылки на объект класса в ответ на вызов CoGetClass0bject SCM вызовет метод объекта класса IClassFactory::LockServer. С тех пор как значительное большинство серверов реализуют IClassFactory в своих объектах класса, эта модернизация исполняемых программ COM исправляет значительное количество дефектов. Однако если объект класса не экспортирует интерфейс IClassFactoryили если сервер должен выполняться и в более ранних версиях COM, чем Windows NT 4.0, то необходимо использовать технологию IExternalConnection.

Следует обсудить еще одну проблему, относящуюся ко времени жизни сервера. Отметим, что когда сервер решает прекратить работу, то он сообщает о том, что главный поток серверного приложения должен начать свою последовательность операций останова (shutdown sequence ) до выхода из процесса. Частью этой последовательности операций останова является вызов CoRevokeClassObject для отмены регистрации его объектов класса. Если, однако, были использованы показанные ранее реализации UnlockModule , то появляются условия серьезной гонки. Возможно, что в промежутке между тем моментом, когда сервер сигнализирует главному потоку посредством вызова SetEvent или PostThreadMessage, и тем моментом, когда сервер аннулирует объекты своего класса, вызывая CoRevokeClassObject, в серверный процесс поступят дополнительные запросы на активацию. Если в этот интервал времени создаются новые объекты, то уже нет способа сообщить главному потоку, что прекращение работы – плохая идея и что у процесса появились новые объекты для обслуживания. Для устранения этих условий гонки в COM предусмотрены две API-функции:

ULONG CoAddRefServerProcess(void);

ULONG CoReleaseServerProcess(void);

Эти две подпрограммы управляют счетчиком блокировок модуля от имени вызывающего объекта. Эти подпрограммы временно блокируют любой доступ к библиотеке COM, чтобы гарантировать, что во время установки счетчика блокировок новые активационные запросы не будут обслуживаться. Кроме того, если функция CoReleaseServerProcess обнаружит, что удаляется последняя блокировка в процессе, то она изнутри пометит все объекты класса в процессе как приостановленные и сообщит SCM, что процесс более не является сервером для его CLSID.

Следующие подпрограммы корректно реализуют время жизни сервера во внепроцессном сервере:

void LockModule(void) {

CoAddRefServerProcess();

// COM maintains lock count

// COM устанавливает счетчик блокировок

}

void UnlockModule(void) {

if (CoReleaseServerProcess() == 0) SetEvent(g_heventShutdown);

}

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

Даже при использовании функций CoAddRefServerProcess / CoReleaseServerProcess все еще остаются возможности для гонки. Возможно, что во время выполнения CoReleaseServerProcess на уровне RPC будет получен входящий запрос на активацию от SCM. Если вызов от SCM диспетчеризован после того, как функция CoReleaseServerProcess снимает свою блокировку библиотеки COM, то активационный запрос отметит, что объект класса уже помечен как приостановленный, и в SCM будет возвращено сообщение об ошибке со специфическим кодом (CO_E_SERVER_STOPPING). Когда SCM обнаруживает этот специфический код, он просто запускает новый экземпляр серверного процесса и повторяет запрос, как только новый серверный процесс зарегистрирует себя. Несмотря на системы защиты, используемые библиотекой COM, остается вероятность того, что поступающий активационный запрос будет выполняться одновременно с заключительным вызовом функции CoReleaseServerProcess. Чтобы избежать этого, сервер может явно возвратить CO_E_SERVER_STOPPING как из IClassFactory::Create Instance, так и из IPersistFile::Load в том случае, если он определит, что по окончании запроса на прекращение работы был сделан еще какой-то запрос. Следующий код демонстрирует этот способ:

STDMETHODIMP MyClassObject::CreateInstance(IUnknown *puo, REFIID riid, void **ppv) {

LockModule();

// ensure we don't shut down while in call

// убеждаемся в том, что не прекращаем работу

// во время вызова HRESULT hr;

*ppv = 0;

// shutdown initiated?

// процесс останова запущен?

DWORD dw = WaitForSingleObject(g_heventShutdown, 0);

if (dw == WAIT_OBJECT_0) hr = CO_E_SERVER_STOPPING;

else {

// normal CreateInstance implementation

// нормальная реализация CreateInstance

}

UnlockModule();

return hr;

}

Во время написания этого текста ни одна из коммерческих библиотек классов COM не реализовывала этот способ.

 

Идентификаторы приложений

В версии COM под Windows NT 4.0 введено понятие приложений COM (COM applications). Приложения COM идентифицируются с помощью GUID (называемых в этом контексте AppID – идентификаторы приложения) и представляют серверный процесс для одного или более классов. Каждый CLSID может быть связан с ровно одним идентификатором приложений. Эта связь фиксируется в локальном реестре, использующем именованное значение AppID:

[HKCR\CLSID\{27EE6A4E-DF65-11D0-8C5F-0080C73925BA}] @="Gorilla" AppID="{27EE6A4E-DF65-11D0-8C5F-0080C73925BA}"

Все классы, принадлежащие к одному и тому же приложению COM, будут иметь один и тот же AppID, а также будут использовать одни и те же установки удаленной активации и защиты. Эти установки записаны в локальном реестре под ключом HKEY_CLASSES_ROOT\AppID

Подобно CLSID, AppID могут быть зарегистрированы для каждого пользователя под Windows NT версии 5.0 или выше. Поскольку серверы, реализованные до появления Windows NT 4.0, не регистрируют явно свои AppID, инструментальные средства конфигурирования COM (например, DCOMCNFG.EXE, OLEVIEW.EXE) автоматически создадут новый AppID для этих старых серверов. Чтобы синтезировать AppID для старых серверов, эти программы автоматически добавляют именованное значение AppID ко всем CLSID, экспортируемым определенным локальным сервером. При добавлении этих именованных значений DCOMCNFG или OLEVIEW просто использует в качестве AppID первый встреченный CLSID для данного сервера. Те приложения, которые были разработаны после выпуска Windows NT 4.0, могут (и будут) использовать для своих AppID особый GUID.

Большинством установок AppID можно управлять с помощью программы DCOMCNFG.EXE, которая является стандартным компонентом Windows NT 4.0 или выше. DCOMCNFG.EXE предоставляет администраторам удобный для использования интерфейс для контроля установок удаленного доступа и защиты. Более мощный инструмент, OLEVIEW.EXE, осуществляет большинство функциональных возможностей DCOMCNFG.EXE и, кроме того, обеспечивает очень «COM-центрический» (COM-centric) взгляд на реестр. Обе эти программы интуитивно понятны при использовании и обе являются существенными для разработок с использованием COM.

Простейшим установочным параметром AppID является RemoteServerName. Эта именованная величина показывает, какую хост-машину следует использовать для удаленных запросов на активацию, если в них явно не указано с помощью COSERVERINFO удаленное хост-имя. Рассмотрим следующие установки реестра:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}] @="Аре Server" RemoteServerName="www.apes.com"

[HKCR\AppID\{27EE6A4E-DF65-11d0-8C5F-0080C73925BA}] @="Gorilla" AppID={27EE6A4D-DF65-11d0-8C5F-0080C73925BA}

[HKCR\AppID\{27EE6A4F-DF65-11d0-8C5F-0080C73925BA}] @="Chimp" AppID={27EE6A4D-DF65-11d0-8C5F-0080C73925BA}

Если клиент осуществляет такой запрос на активацию:

IApeClass *рас = 0;

HRESULT hr = CoGetClassObject(CLSID_Chimp, CLSCTX_REMOTE_SERVER, 0, IID_IApeClass, (void**)&pac);

то SCM со стороны клиента направит этот запрос в SCM на www.apes.com , где этот запрос будет рассмотрен как локальный активационный запрос. Отметим, что если клиент предоставляет явное хост-имя:

IApeClass *рас = 0;

COSERVERINFO csi;

ZeroMemory(&csi, sizeof(csi));

csi.pwszName = OLESTR();

HRESULT hr = CoGetClassObject(CLSID_Chimp, CLSCTX_REMOTE_SERVER, &csi, IID_IApeClass, (void**)&pac);

то установка RemoteServerName игнорируется и запрос направляется в www.apes.com.

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

IApeClass *pac = 0;

HRESULT hr = CoGetClassObject(CLSID_Chimp, CLSCTX_ALL, 0, IID_IApeClass, (void*)&pac);

Поскольку не указано никакого хост-имени, то SCM сначала будет искать в локальном реестре следующий ключ:

[HKCR\AppID\{27EE6A4F-DF65-11d0-8C5F-0080C7392SBA}]

Если этот ключ локально не доступен, COM обратится к хранилищу класса (class store) под Windows NT 5.0, если оно доступно. Если с этой точки зрения ключ реестра доступен, то вслед за этим SCM будет искать подключ InpocServer32:

HKCR\CLSID\{27EE6A4F-DF65-11d0-8C5F-0080C73925BA}\InprocServer32] @="C:\somefile.dll"

Если этот ключ найден, класс будет активирован путем загрузки той DLL, которая указана в реестре. В противном случае SCM ищет подключ InprocHandler32 :

HKCR\CLSID\{27EE6A4F-DF65-11d0-8C5F-0080C73925BA}\InprocHandler32] @="C:\somefile.dll"

Если класс имеет ключ дескриптора (handler), то и тогда класс будет активирован путем загрузки той DLL, которая указана в реестре. Если ни один из внутрипроцессных подключей не доступен, то SCM предполагает, что активационный запрос должен быть внепроцессным. В таком случае SCM проверяет, имеет ли серверный процесс объект класса, зарегистрированный в настоящее время для запрашиваемого CLSID. Если это так, то SCM входит в серверный процесс и маршалирует объектную ссылку из соответствующего объекта класса и возвращает ее в апартамент вызывающего объекта, где она демаршалируется до того, как управление возвращается к вызывающему объекту. Если объект класса был зарегистрирован серверным процессом с флагом REGCLS_SINGLEUSE, то SCM затем забывает, что класс доступен в серверном процессе и не будет использовать его для последующих запросов на активацию.

Только что описанный сценарий является корректным, если серверный процесс уже выполняется. Если, однако, SCM получает внепроцессный запрос на активацию, но под запрашиваемым CLSID не зарегистрировался ни один серверный процесс, то SCM запустит серверный процесс, который еще не запущен. COM поддерживает три модели для создания серверов: сервисы NT (NT Services), нормальные процессы и суррогатные процессы (surrogate processes). NT Services и нормальные процессы очень похожи, и причины, по которым один из них можно предпочесть другому, явятся предметом дальнейшего обсуждения в рамках этой главы. Суррогатные процессы используются в основном для возложения функции ведущего узла на старые внутрипроцессные серверы в отдельных серверных процессах. Это дает преимущества удаленной активации и локализации ошибок для старых DLL или для классов, которые должны быть упакованы как DLL (например, виртуальная машина Java). Независимо от того, какая модель используется для создания серверного процесса, у серверного процесса есть 120 секунд (или 30 секунд под Windows NT Service Pack 2 и более ранних версий) для регистрации запрошенного объекта класса с применением CoRegisterClassObject. Если серверный процесс не может вовремя зарегистрировать сам себя, то SCM откажет вызывающему объекту в запросе на активацию.

При создании серверного процесса SCM вначале проверяет, имеет ли AppID, соответствующий запрашиваемому классу, именованную величину LocalService:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA} LocalService="apesvc"

Если это именованное значение имеется, то SCM использует NT Service Control Manager (диспетчер управления сервисами) для запуска той службы NT, которая указана в реестре (например, apesvc). Если же именованная величина LocalService отсутствует, то в этом случае SCM ищет в указанном CLSID ключе подключ LocalServer32:

[HKCR\CLSID\{27EE6A4F-DF65-11d0-8C5F-0080C73925BA}\LocalServer32] @="C:\somefile.exe"

Если этот ключ присутствует, то SCM применит для запуска серверного процесса API-функцию CreateProcess (или CreateProcessAsUser). В случае отсутствия и LocalService, и LocalServer32, SCM ищет, определен ли для AppID -класса суррогатный процесс:

[HKCR\AppID\{27EE6A4D-DF6S-11d0-8CSF-0080C73925BA}] DllSurrogate=""

Если величина, именованная DllSurrogate, существует, но пуста, то SCM запустит суррогатный процесс по умолчанию (dllhost.exe). Если именованная величина DllSurrogate существует, но ссылается на легальное имя файла:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C7392SBA}] DllSurrogate="С:\somefile.exe"

то SCM запустит указанный серверный процесс. В любом случае суррогатный процесс саморегистрируется библиотекой COM (и SCM) с помощью API-функции CoRegisterSurrogate в качестве суррогатного процесса:

HRESULT CoRegisterSurrogate([in] ISurrogate *psg);

Эта API-функция предполагает, что суррогатный процесс предоставляет реализацию интерфейса ISurrogate:

[uuid(00000022-0000-0000-C000-000000000046), object] interface ISurrogate : IUnknown {

// SCM asking surrogate to load inprocess class object and

// call CoRegisterClassObject using REGCLS_SUSPENDED

// SCM просит суррогат загрузить внутрипроцессный

// объект класса и вызвать CoRegisterClassObject

// с флагом REGCLS_SUSPENDED

HRESULT LoadDllServer([in] REFCLSID rclsid);

// SCM asking surrogate to shut down

// SCM просит суррогат прекратить работу

HRESULT FreeSurrogate();

}

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

Если, наконец, не существует ни одного из этих ключей реестра или именованных величин, то SCM будет искать элемент RemoteServerName под ключом AppID, соответствующим классу:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8CSF-0080C7392SBA}] RemoteServerName="www.apes.com"

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

Еще один дополнительный фактор, способный изменить адресацию активационных запросов, относится только к запросам CoGetInstanceFromFile (включая вызовы BindToObject файлового моникера). По умолчанию, если имя файла, использованное для наименования постоянного объекта, относится к файлу из удаленной файловой системы, то COM будет использовать вышеописанный алгоритм для определения того, где активировать объект. Если, однако, AppID класса имеет именованную величину ActivateAtStorage и эта величина равна "Y" или "y", то COM направит активационный запрос к той машине, на которой располагается файл, при условии, что вызывающий объект не передавал явное хост-имя через структуру COSERVERINFO. Этот способ гарантирует, что во всей сети будет существовать только один экземпляр.

 

COM и защита

Исходная версия COM не занималась проблемой защиты. Это можно рассматривать как упущение, так как многие примитивы NT без удаленного доступа (nonremotable) (например, процессы, потоки) могут быть защищены, несмотря на то, что ими нельзя управлять дистанционно. Версия Windows NT 4.0 вынудила добавить к COM обеспечение безопасности, так как стало возможным осуществлять доступ к серверным процессам практически от любой машины в сети. К счастью, поскольку COM использует в качестве средства сообщения RPC, то защита COM просто применяет существующую инфраструктуру защиты RPC.

Защита COM может быть разделена на три категории: аутентификация (authentication), контроль доступа (access control) и управление маркерами (token management). Аутентификация заключается в обеспечении подлинности сообщения, а именно: отправитель действительно тот, за кого он себя выдает, а данное сообщение действительно пришло от отправителя. Контроль за доступом проверяет, кто имеет допуск к объектам сервера и кто имеет право запуска серверного процесса. Управление маркерами осуществляет контроль за тем, чьи полномочия использованы при запуске серверных процессов и при выполнении самого вызова метода. В COM предусмотрены до некоторой степени разумные установки по умолчанию по всем трем аспектам защиты, что делает теоретически возможным писать приложения COM, не учитывая вопросов безопасности. Эти установки по умолчанию основаны на принципе наименьших сюрпризов; то есть если программист не делает ничего явного по защите, то маловероятно, что этим будут внесены какие-либо «дыры» в систему безопасности NT. В то же время построение даже простейшего рассредоточенного приложения на базе COM требует, чтобы каждому аспекту обеспечения безопасности было уделено определенное внимание.

Большинство аспектов защиты COM может быть сконфигурировано путем помещения в реестр нужной информации. Программа DCOMCNFG.ЕХЕ позволяет администраторам настраивать большинство установок (но не все), относящихся к защите COM. Для большинства этих установок (но не для всех) программист приложения может предпочесть употребление явных API-функций вместо установок в реестре. В целом большинство приложений используют комбинацию установок DCOMCNFG.EXE с явными API-функциями. Первый вариант проще для отладки системными администраторами, в то время как второй предполагает большую гибкость без риска неправильного обращения с DCOMCNFG.EXE.

Защита COM использует основные средства RPC для аутентификации и заимствования прав (impersonation). Напомним, что RPC использует загружаемые транспортные модули для того, чтобы после их загрузки в систему были добавлены новые сетевые протоколы. Транспортные модули именуются при помощи последовательностей протоколов (protocol sequences) (например, «ncadg_ip_udp»), которые преобразуются в реестре в специальную транспортную библиотеку DLL. Это позволяет третьим участникам устанавливать поддержку новых транспортных протоколов без модифицирования библиотеки COM. Подобным же образом RPC поддерживает загружаемые модули защиты, позволяя добавлять в систему новые протоколы защиты. Модули защиты именуются при помощи целых чисел, которые преобразуются в реестре в специальные DLL модулей защиты. Эти DLL должны соответствовать требованиям SSPI (Security Support Provider Interface – интерфейс провайдера поддержки безопасности), который является производным от Internet Draft Standard GSSAPI.

В системных заголовочных файлах определено несколько констант для известных модулей защиты. Ниже приведен текущий список известных на момент написания этого текста модулей защиты:

enum {

RPC_C_AUTHN_NONE = 0, // no authentication package

// модуля аутентификации нет

RPC_C_AUTHN_DCE_PRIVATE = 1, // DCE private key (not used)

// закрытый ключ DCE (не используется)

RPC_C_AUTHN_DCE_PUBLIC = 2, // DCE public key (not used)

// открытый ключ DCE (не используется)

RPC_C_AUTHN_DEC_PUBLIC = 4, // Digital Equip, (not used)

// цифровое оборудование (не используется)

RPC_C_AUTHN_WINNT = 10, // NT Lan Manager

// администратор локальной сети NT

RPC_C_AUTHN_GSS_KERBEROS,

RPC_C_AUTHN_MQ = 100, // MS Message Queue package

// модуль MS Message Queue (очереди сообщений Microsoft)

RPC_C_AUTHN_DEFAULT = 0xFFFFFFFFL

};

RPC_C_AUTHN_WINNT показывает, что должен использоваться протокол аутентификации Администратора локальной сети (NT LAN (local area network) Manager – NTLM). RPC_C_AUTHN_GSS_KERBEROS показывает, что будет использован протокол аутентификации Kerberos. Под Windows NT 4.0 поддерживается только протокол NTLM, если не установлена SSP третьего участника. Windows NT 5.0 будет выпущена с поддержкой как минимум NTLM и Kerberos. По вопросам получения других модулей защиты обращайтесь к соответствующей документации.

Каждый интерфейсный заместитель может быть сконфигурирован независимо, что дает возможность использовать различные модули защиты. Если интерфейсный заместитель сконфигурирован для использования протокола защиты, в клиентский процесс загружается соответствующая SSP DLL. Для того чтобы запрос на соединение с защитой был принят, серверный процесс должен зарегистрировать и загрузить соответствующую библиотеку SSP DLL до получения от клиента первого вызова ORPC. Если соединение сконфигурировано для использования модуля защиты, то соответствующая SSP DLL работает в связке с динамическим уровнем иерархии RPC и имеет возможность видеть каждый пакет, передаваемый или получаемый в рамках конкретного соединения. Библиотеки SSP DLL могут посылать в каждом пакете дополнительную информацию, специфическую для защиты, а также модифицировать маршалированное состояние параметра в целях шифрования. DCE RPC (и COM) предусматривают шесть уровней аутентификационной защиты, которые варьируются от отсутствия защиты до полного шифрования состояния всех параметров:

enum {

RPC_C_AUTHN_LEVEL_DEFAULT, // use default level for pkg

// используем для модуля уровень, принятый по умолчанию

RPC_C_AUTHN_LEVEL_NONE, // по authentication

// без аутентификации

RPC_C_AUTHN_LEVEL_CONNECT, // only authenticate credentials

// только аутентификация мандата

RPC_C_AUTHN_LEVEL_CALL, // protect message headers

// защищаем заголовки сообщений

RPC_C_AUTHN_LEVEL_PKT, // protect packet headers

// защищаем заголовки пакетов

RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, // protect parameter state

// защищаем состояние параметров

RPC_C_AUTHN_LEVEL_PKT_PRIVACY, // encrypt parameter state

// зашифровываем состояние параметров

};

Каждый последующий уровень аутентификации включает в себя функциональные возможности предыдущего уровня. Уровень RPC_C_AUTHN_LEVEL_NONE показывает, что не будет проведено никакой аутентификации. Уровень RPC_C_AUTHN_LEVEL_CONNECT показывает, что при первом вызове метода полномочия клиента должны быть аутентифицированы на сервере. Если у клиента нет необходимых полномочий, то вызов ORPC будет прерван с ошибкой E_ACCESSDENIED. Как именно проверяется достоверность этих полномочий, зависит от того, какая SSP используется. Под NTML серверный процесс выдает запрос пароля (challenge) клиентскому процессу. Этот запрос представляет собой просто непредсказуемое большое случайное число. Клиент использует закодированную версию пароля вызывающего объекта для шифрования этого запроса, который затем пересылается обратно серверу в качестве отклика (response). Затем сервер шифрует исходный запрос пароля с помощью того, что он считает закодированным паролем, и сравнивает результат с тем откликом, который он получил от клиента. Если отклик клиента совпадает с зашифрованным запросом сервера, то «личность» клиента считается установленной. NTLMSSP последовательно располагает пары квитирования (установления связи) запрос-отклик в отправных пакетах, которые посылаются исполняемой программой RPC для синхронизации порядковых номеров. Поэтому между клиентом и сервером не производится никакого дополнительного сетевого обмена данными. В зависимости от типа учетной записи (доменная, локальная) дополнительный обмен данными с контроллером домена для поддержки опосредованной аутентификации (pass-through authentication) может производиться или не производиться.

При использовании уровня аутентификации RPC_AUTHN_LEVEL_CONNECT никакого дополнительного обмена информацией, касающейся защиты, после проверки начальных полномочий не осуществляется. Это означает, что программы-злоумышленники могут перехватывать сообщения в сети и воспроизводить RPC-запросы путем простого изменения порядковых номеров DCE (среды распределенных вычислений) в заголовках пакетов. Для дополнительной защиты от воспроизведения вызова следовало бы использовать уровень аутентификации RPC_C_AUTHN_LEVEL_CALL. Он информирует библиотеки SSP DLL о необходимости защиты RPC-заголовка первого пакета каждого запроса или отклика RPC путем привязывания к передаваемому пакету однонаправленного хэш-ключа (на базе случайных чисел). Поскольку запрос или отклик RPC может быть помещен частями в более чем один сетевой пакет, то RPC API поддерживает также уровень аутентификации RPC_C_AUTHN_LEVEL_PKT. Этот уровень защищает от воспроизведения на уровне сетевых пакетов, что является большей защитой, чем уровень RPC_C_AUTHN_LEVEL_CALL, поскольку RPC-сообщение может занимать два пакета или более.

До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT включительно SSP DLL в большей или меньшей мере игнорирует фактическую полезную нагрузку RPC-пакетов и защищает только целостность RPC-заголовков. Для того чтобы убедиться, что состояние маршалированного параметра не изменено вражеским агентом в сети, в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. Этот уровень предписывает SSP DLL вычислять контрольную сумму состояния маршалированного параметра и проверять, что содержимое пакета не было изменено в процессе передачи. Поскольку при этом уровне аутентификации каждый передаваемый байт должен обрабатываться с помощью SSP DLL, она проходит значительно медленнее, чем при уровне RPC_C_AUTHN_LEVEL_PKT, и его следует использовать только в ситуациях, требующих особой защиты.

До уровня аутентификации RPC_C_AUTHN_LEVEL_PKT_INTEGRITY включительно фактическое содержание RPC-пакетов пересылается как открытый текст (например, незашифрованный). Для обеспечения невидимости состояния маршалированного параметра для вражеских агентов сети в RPC предусмотрен уровень аутентификации RPC_C_AUTHN_LEVEL_PKT_PRIVACY. Данный уровень аутентификации предписывает SSP DLL зашифровывать состояние маршалированного параметра до передачи. Подобно всем прочим уровням аутентификации уровень RPC_C_AUTHN_LEVEL_PKT_PRIVACY включает в себя защиту всех уровней ниже себя. Как и в случае RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, каждый передаваемый байт должен обрабатываться SSP DLL, поэтому во избежание излишних издержек этот уровень аутентификации следует использовать только в особых с точки зрения безопасности ситуациях.

Наиболее важной API-функцией в службе безопасности COM является CoInitializeSecurity. Каждый процесс, использующий COM, вызывает CoInitializeSecurity ровно один раз, явно или неявно. Функция CoInitializeSecurity вводит автоматические установки по защите. Эти установки применяются ко всем импортируемым и экспортируемым ссылкам на объекты, за исключением явно переопределенных с использованием дополнительных вызовов API-функций. Чтобы использовать один или нескольких модулей защиты, CoInitializeSecurity конфигурирует используемый исполняемый слой RPC, а также устанавливает уровень аутентификации, принимаемый по умолчанию для процесса. Кроме того, CoInitializeSecurity позволяет вызывающей программе указать, каким пользователям разрешено делать ORPC-запросы на объекты, экспортируемые из текущего процесса. CoInitia1izeSecurity имеет довольно большое число параметров:

HRESULT CoInitializeSecurity(

[in] PSECURITY_DESCRIPTOR pSecDesc, // access control

// контроль за доступом

[in] LONG cAuthSvc, // # of sec pkgs (-1 == use defaults)

// количество модулей защиты (-1 == используем по умолчанию)

[in] SOLE_AUTHENTICATION_SERVICE *rgsAuthSvc, // SSP array

// массив SSP

[in] void *pReserved1, // reserved MBZ

// зарезервировано, должен быть О

[in] DWORD dwAuthnLevel, // auto, AUTHN_LEVEL

// аутентификация AUTHN_LEVEL

[in] DWORD dwImpLevel, // auto. IMP_LEVEL

// аутентификация IMP_LEVEL

[in] void *pReserved2, // reserved MBZ

// зарезервировано, должен быть О

[in] DWORD dwCapabilities, // misc flags

// различные флаги

[in] void *pReserved3 // reserved MBZ

// зарезервировано, должен быть О

);

Некоторые из этих параметров применяются только в тех случаях, когда процесс выступает как экспортер/сервер. Другие – только если процесс действует как импортер/клиент. Остальные применяются в обоих случаях.

Первый параметр функции CoInitializeSecurity, pSecDesc, применим только в случае, когда процесс выступает как экспортер. Этот параметр используется для контроля того, каким принципалам – пользователям или процессам, имеющим учетную запись (principals) – разрешен доступ к объектам, экспортируемым из данного процесса. В деталях этот параметр будет обсужден позже в данной главе. Второй и третий параметры функции CoInitializeSecurity, соответственно cAuthSvc и rgsAuthSvc, используются при работе процесса в качестве экспортера для регистрации одного или нескольких модулей защиты с помощью библиотеки COM. Эти два параметра ссылаются на массив описаний модулей защиты:

typedef struct tagSOLE_AUTHENTICATION_SERVICE {

DWORD dwAuthnSvc; // which authentication package?

// какой модуль защиты?

DWORD dwAuthzSvc; // which authorization service?

// какая служба авторизации?

OLECHAR *pPrincipalName; // server principal name?

// имя серверного принципала?

HRESULT hr; // result of registration

// результат регистрации

} SOLE_AUTHENTICATION_SERVICE;

В Windows NT 4.0 единственной установленной службой аутентификации является RPC_C_AUTHN_WINNT (NTLM). При использовании аутентификации NTLM служба авторизации (authorization service – сервис контроля доступа, определяющий права клиента) должна быть указана как RPC_C_AUTHZ_NONE, а имя серверного принципала не используется и должно быть нулевым. Для тех процессов, которые просто хотят использовать пакет (пакеты) защиты по умолчанию на отдельной машине, следует использовать значения: cAuthSvc, равное -1, и rgsAuthSvc, равное нулю.

Пятый параметр функции CoInitializeSecurity, dwAuthnLevel, применим как к экспортируемым, так и к импортируемым объектным ссылкам. Величина, заданная для этого параметра, устанавливает предельно низкий уровень аутентификации для объектных ссылок, экспортируемых из этого процесса. Это означает, что поступающие ORPC-запросы должны иметь по крайней мере такой уровень аутентификации; в противном случае этот вызов будет отклонен. Эта величина определяет также минимальный уровень аутентификации, используемый новыми интерфейсными заместителями, которые возвращаются API-функциями или методами COM. Создавая новый интерфейсный заместитель во время демаршалинга, COM рассматривает число, обозначающее нижний уровень аутентификации, заданный экспортером, как часть разрешения OXID. Затем COM устанавливает уровень аутентификации нового заместителя равным или нижнему уровню экспортера, или нижнему уровню текущего процесса – в зависимости от того, какой из них выше. Если процесс, импортирующий объектную ссылку, имеет уровень аутентификации ниже, чем экспортирующий процесс, то для установки уровня аутентификации используется нижний уровень экспортера. Такой способ гарантирует, что любые ORPC-запросы, посылаемые интерфейсным заместителем, пройдут через нижний уровень экспортера. Далее в этой главе будет рассмотрено, как с целью более детального контроля можно явным образом изменить уровень аутентификации для отдельного интерфейсного заместителя.

Шестой параметр функции CoInitializeSecurity, dwImpLevel применяется для импортируемых объектных ссылок. Величина, определенная для этого параметра, устанавливает уровень заимствования прав (impersonation level), используемый для всех объектных ссылок, которые возвращаются функцией CoUnmarshalInterface. Уровень заимствования прав позволяет одному процессу заимствовать атрибуты защиты у другого процесса и отражает степень доверия, которое клиент испытывает к серверу. Этот параметр должен принимать одно из следующих четырех значений, характеризующих уровень заимствования прав:

enum {

// hide credentials of caller from object

// скрываем от объекта полномочия вызывающей программы

RPC_C_IMP_LEVEL_ANONYMOUS = 1,

// allow object to query credentials of caller

// разрешаем объекту запрашивать полномочия вызывающей программы

RPC_C_IMP_LEVEL_IDENTIFY = 2,

// allow use of caller's credentials up to one-hop away

// разрешаем использовать полномочия вызывающей

// программы не далее одной сетевой передачи

RPC_C_IMP_LEVEL_IMPERSONATE = 3,

// allow use of caller's credentials across multiple hops

// разрешаем использовать полномочия вызывающей

// программы в течение нескольких сетевых передач

RPC_C_IMP_LEVEL_DELEGATE = 4

};

Уровень RPC_C_IMP_LEVEL_ANONYMOUS не позволяет реализации объекта обнаружить идентификатор безопасности вызывающей программы. Уровень доверия RPC_C_IMP_LEVEL_IDENTIFY указывает, что реализация объекта может программно определить идентификатор защиты вызывающей программы. Уровень доверия RPC_C_IMP_LEVEL_IMPERSONATE указывает, что сервер может не только определить идентификатор защиты вызывающей программы, но также выполнить операции на уровне операционной системы с использованием полномочий вызывающей программы. На этом уровне доверия объекты могут использовать полномочия вызывающей программы, но имеют доступ только к локальным ресурсам. В противоположность этому, уровень доверия RPC_C_IMP_LEVEL_DELEGATE разрешает серверу доступ как к локальным, так и к удаленным ресурсам с использованием полномочий вызывающей программы. Этот уровень доверия не поддерживается протоколом аутентификации NTLM, но поддерживается протоколом аутентификации Kerberos.

Восьмой параметр функции CoInitializeSecurity, dwCapabilities применим к импортируемым и к экспортируемым объектным ссылкам. Этот параметр является битовой маской, которая может состоять из нуля или более следующих битов:

typedef enum tagEOLE_AUTHENTICATION_CAPABILITIES {

EOAC_NONE = 0х0,

EOAC_MUTUAL_AUTH = 0х1,

// These are only valid for CoInitializeSecurity

// только эти допустимы для CoInitializeSecurity

EOAC_SECURE_REFS = 0х2,

EOAC_ACCESS_CONTROL = 0х4,

EOAC_APPID = 0х8

} EOLE_AUTHENTICATION_CAPABILITIES;

Взаимная аутентификация (EOAC_MUTUAL_AUTH) под NTLM не поддерживается. Она используется для проверки того, что сервер исполняется как ожидаемый принципал. Ссылки защиты (EOAC_MUTUAL_AUTH) указывают, что распределенные вызовы подсчета ссылок COM будут аутентифицироваться для гарантии того, что никакие вражеские агенты не могут испортить счетчик ссылок, используемый OR и администраторами заглушек для управления жизненным циклом. EOAC_ACCESS_CONTROL и EOAC_APPID используются для управления семантикой первого параметра функции CoInitializeSecurity и будут обсуждаться далее в этой главе.

Как было установлено ранее в этом разделе, CoInitializeSecurity вызывается один раз на процесс, явно или неявно. Приложения, желающие вызвать CoInitializeSecurity явно, должны делать это после первого вызова CoInitializeEx, но перед «первым интересным вызовом COM» (first interesting COM call). Фраза «первый интересный вызов COM» относится к любой API-функции, которой может понадобиться OXID. Сюда относятся CoMarshalInterface и CoUnmarshalInterface, а также любые API-вызовы, неявно вызывающие эти функции. Поскольку вызовы CoRegisterClassObject связывают объекты класса с апартаментами, то CoInitializeSecurity должна быть вызвана до регистрации объектов класса. API-функции активации (например, CoCreateInstanceEx) являются любопытным исключением. Активация API-функций для определенных внутренних классов, которые являются частью COM API (например, глобальная интерфейсная таблица, COM-объект контроля доступа по умолчанию) может быть произведена до вызова CoInitializeSecurity. Тем не менее, функция CoInitializeSecurity должна быть вызвана раньше, чем любые активационные вызовы, которые фактически консультируются с реестром и загружают другие DLL или контактируют с другими серверами. Если приложение не вызывает функцию CoInitializeSecurity явно, то COM вызовет ее неявно в качестве первого интересного вызова COM.

Когда COM вызывает функцию CoInitializeSecurity неявно, она читает значения большинства параметров из реестра. Некоторые из этих параметров содержатся в реестровом ключе, общем для всей машины, в то время как остальные записаны под специфическим AppID данного приложения. Чтобы извлечь AppID приложения, COM ищет имя файла процесса приложения под ключом реестра

HKEY_CLASSES_ROOT\AppID

Если COM находит здесь имя файла, она извлекает AppID из именованной величины AppID:

[HKCR\AppID\ServerOfTheApes.exe]

AppID="{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}"

Если никакого соответствия не существует, то COM считает, что приложение не имеет в реестре специфических установок по защите.

Неявные вызовы CoInitializeSecurity находят первый параметр, pSecDesc, путем поиска сериализованного (приведенного в последовательную форму) дескриптора защиты NT SECURITY_DESCRIPTOR в следующей именованной величине:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]

AccessPermission=

Если эта именованная величина не найдена, то COM ищет общий для всей машины элемент:

[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]

DefaultAccessPermission=

Оба этих элемента реестра могут быть легко изменены при помощи DCOMCNFG.ЕХЕ. Если не найден ни один из этих элементов реестра, то COM создаст дескриптор защиты (security descriptor), предоставляющий доступ принципалу только вызывающей программы и встроенной учетной записи SYSTEM. COM использует этот дескриптор защиты, чтобы при помощи Win32 API-функции AccessCheck предоставить или запретить доступ к объектам, экспортированным из данного процесса.

Неявные вызовы CoInitializeSecurity используют для второго и третьего параметров (cAuthSvc и rgsAuthSvc) значения -1 и нуль соответственно, указывая тем самым, что должны использоваться модули защиты, принятые по умолчанию. Неявные вызовы CoInitializeSecurity находят значения для пятого и шестого параметров (dwAuthnLevel и dwImpLevel) в следующем элементе реестра всей машины:

[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]

LegacyAuthenticationLevel = 0x5

LegacyImpersonationLevel = 0x3

RPC_C_AUTHN_LEVEL_PKT_INTEGRITY и RPC_C_AUTHN_LEVEL_IMPERSONATE принимают числовые значения 5 и 3 соответственно. Если эти именованные величины отсутствуют, то используются значения RPC_C_AUTHN_LEVEL_CONNECT и RPC_C_IMP_LEVEL_IDENTIFY. Из флагов, используемых в восьмом параметре функций CoInitializeSecurity, dwCapabilities, в настоящее время читается из элемента реестра всей машины только флаг EOAC_SECURE_REFS:

[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]

LegacySecureRefs = "Y"

Если эта именованная величина в наличии и содержит "Y" или "y", то COM будет использовать флаг EOAC_SECURE_REFS; в противном случае используется флаг EOAC_NONE. Каждая из этих традиционных установок аутентификации может быть легко изменена при помощи DCOMCNFG.ЕХЕ.

 

Программируемая защита

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

Чтобы позволить разработчикам игнорировать автоматические установки защиты на базе интерфейсных заместителей, администратор заместителей выставляет интерфейс IClientSecurity:

[local, object, uuid(0000013D-0000-0000-C000-000000000046)]

interface IClientSecurity : IUnknown {

// get security settings for interface proxy pProxy

// получаем установки защиты для интерфейсного заместителя

pProxy HRESULT* QueryBlanket([in] IUnknown *pProxy, [out] DWORD *pAuthnSvc, [out] DWORD *pAuthzSvc, [out] OLECHAR **pServerPrincName, [out] DWORD *pAuthnLevel, [out] DWORD *pImpLevel, [out] void **pAuthInfo, [out] DWORD *pCapabilities );

// change security settings for interface proxy pProxy

// изменяем установки защиты для интерфейсного заместителя

pProxy HRESULT SetBlanket([in] IUnknown *pProxy, [in] DWORD AuthnSvc, [in] DWORD AuthzSvc, [in] OLECHAR *pServerPrincName, [in] DWORD AuthnLevel, [in] DWORD ImpLevel, [in] void *pAuthInfo, [in] DWORD Capabilities );

// duplicate an interface proxy

// дублируем интерфейсный заместитель

HRESULT CopyProxy([in] IUnknown *pProxy, [out] IUnknown **ppCopy );

}

Второй, третий и четвертый параметры методов SetBlanket и QueryBlanket соответствуют трем членам структуры данных SOLE_AUTHENTICATION_SERVICE. Под Windows NT 4.0 единственными допустимыми величинами являются соответственно RPC_C_AUTHN_WINNT, RPC_C_AUTHN_NONE и нуль.

Как показано на рис. 6.1, каждый отдельный интерфейсный заместитель имеет свои собственные установки защиты. Метод IClientSecurity::SetBlanket позволяет вызывающей программе изменять эти установки для каждого интерфейсного заместителя по отдельности.

Метод IClientSecurity::QueryBlanket позволяет вызывающей программе прочитать эти установки для отдельного интерфейсного заместителя. В качестве параметров, о которых вызывающая программа не беспокоится, могут быть переданы нулевые указатели. Метод IClientSecurity::СоруРгоху позволяет вызывающей программе копировать интерфейсный заместитель. Это дает возможность делать изменения в копии интерфейса, которая не будет возвращаться при последующих запросах QueryInterface об администраторе заместителей. В идеале установки защиты следовало бы делать только в скопированных интерфейсных заместителях, чтобы изолировать измененный заместитель от нормальной реализации администратора заместителей в QueryInterface ; это также позволило бы нескольким потокам независимо друг от друга изменять полные установки защиты между вызовами метода.

Все параметры методов IClientSecurity::SetBlanket и IClientSecurity::QueryBlanket соответствуют параметрам CoInitializeSecurity с одним значительным исключением. Седьмой параметр (pAuthInfo ) указывает на набор полномочий клиента. Точная форма этих полномочий специфична для каждого модуля безопасности. Для модуля безопасности NTLM этот параметр может указывать на структуру COAUTHIDENTITY:

typedef struct _COAUTHIDENTITY {

OLECHAR *User;

// user account name

// имя учетной записи пользователя

ULONG UserLength;

// wcslen(User)

// длина имени пользователя

OLECHAR *Domain;

// Domain/Machine name

// имя домена/машины

ULONG DomainLength;

// wcslen(Domain)

// длина имени домена

OLECHAR *Password;

// cleartext password

// пароль открытым текстом

ULONG PasswordLength;

// wcslen(Password)

// длина пароля

ULONG Flags;

// must be SEC_WINNT_AUTH_IDENTITY_UNICODE

// должно быть SEC_WINNT_AUTH_IDENTITY_UNICODE

} COAUTHIDENTITY;

Эта структура позволяет клиентам делать вызовы методов COM как любым принципалам защиты, при условии, что они знают открытые тексты паролей для желаемой учетной записи. Если вместо указателя на явную структуру COAUTHIDENTITY передается нулевой указатель, то каждый внешний вызов будет делаться с использованием полномочий вызывающего процесса.

Чаще всего метод IClientSecurity::SetBlanket применяется для повышения уровня аутентификации отдельного заместителя. Следующий код демонстрирует эту технологию:

HRESULT Encrypt(IApe *pApe) {

IClientSecurity *pcs = 0;

// ask proxy manager for IClientSecurity interface

// запрашиваем интерфейс IClientSecurity у администратора заместителей

HRESULT hr = pApe->QueryInterface(IID_IClientSecurity, (void**)&pcs);

if (SUCCEEDED(hr)) {

hr = pcs->SetBlanket(pApe, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_IMP_LEVEL_IDENTIFY, 0, EOAC_NONE);

pcs->Release();

}

return hr;

}

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

HRESULT DupeAndEncrypt(IApe *pApe, IApe * &rpSecretApe) {

rpSecretApe = 0;

IClientSecurity *pcs = 0;

// ask proxy manager for IClientSecurity interface

// запрашиваем интерфейс IClientSecurity у администратора заместителей

HRESULT hr = pApe->QueryInterface(IID_IClientSecurity, (void**)&pcs);

if (SUCCEEDED(hr)) {

hr = pcs->CopyProxy(pApe, (IUnknown**)&rpSecretApe);

if (SUCCEEDED(hr))

hr = pcs->SetBlanket (rpSecretApe, RPC_AUUTHN_WINNT, RPC_C_AUTHZ_NONE, 0, RPC_С_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_IMP_LEVEL_IDENTIFY, 0, EOAC_NONE);

pcs->Release();

}

return hr;

}

Для удобства в COM API предусмотрены оберточные функции вокруг каждого из трех методов IClientSecurity , которые изнутри вызывают QueryInterface для нахождения соответствующего интерфейса IClientSecurity и затем вызывают нужный метод:

// get security settings for interface proxy pProxy

// получаем установки защиты для интерфейсного заместителя

pProxy HRESULT CoQueryProxyBlanket([in] IUnknown *pProxy, [out] DWORD *pAuthnSvc, [out] DWORD *pAuthzSvc, [out] OLECHAR **pServerPrincName, [out] DWORD *pAuthnLevel, [out] DWORD *pImpLevel, [out] void **pAuthInfo, [out] DWORD *Capabilities);

// change security settings for interface proxy pProxy

// изменяем установки защиты для интерфейсного заместителя

pProxy HRESULT CoSetProxyBlanket([in] IUnknown *pProxy, [in] DWORD AuthnSvc, [in] DWORD AuthzSvc, [in] OLECHAR *pServerPrincName, [in] DWORD AuthnLevel, [in] DWORD ImpLevel, [in] void *pAuthInfo, [in] DWORD Capabilities);

// duplicate an interface proxy

// копируем интерфейсный заместитель

HRESULT CoCopyProxy([in] IUnknown *pProxy, [out] IUnknown **ppCopy);

Следующий код представляет собой модифицированную версию предыдущей функции, где используются эти удобные процедуры:

HRESULT DupeAndEncrypt(IApe *pApe, IАре *ArpSecretApe) {

rpSecretApe = 0; HRESULT hr = СоСоруProxy(pApe, (IUnknown**)&rpSecretApe);

if (SUCCEEDED(hr))

hr = CoSetProxyBlanket(rpSecretApe, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_IMP_LEVEL_IDENTIFY, 0, EOAC_NONE);

return hr;

}

Первая версия несколько эффективнее, так как для нахождения интерфейса IClientSecurity в ней использован только один вызов QueryInterface. Для последней версии требуется меньше кода, поэтому и вероятность ошибок в ней меньше.

Важно отметить, что методы IClientSecurity могут применяться только в тех интерфейсах, которые используют интерфейсные заместители. Это означает, что те интерфейсы, которые реализованы локально администратором заместителей (например, IMultiQI, IClientSecurity), не могут использоваться с методами IClientSecurity. Интерфейс IUnknown – это особый случай. IUnknown фактически является локальным интерфейсом, реализованным администратором заместителей. Однако администратору заместителей часто требуется связаться с апартаментом сервера для запроса новых интерфейсов и для освобождения ресурсов, хранящихся в соответствующем администраторе заглушек. Эта связь осуществляется через закрытый интерфейс IRemUnknown, который реализуется библиотекой COM отдельно внутри каждого апартамента. Разработчики могут контролировать полную защиту, использованную для этих вызовов IRemUnknown путем передачи реализации IUnknown администратора заместителей в IClientSecurity::SetBlanket (подобно интерфейсному заместителю, администратор заместителей использует общие для процесса автоматические установки защиты в случае, если функция SetBlanket не вызывается). Поскольку все интерфейсные заместители агрегированы администратором заместителей, то это, в сущности, означает, что вызовы IClientSecurity::SetBlanket на какой-либо определенный интерфейсный заместитель не влияют на функции QueryInterface, AddRef и Release. Скорее, на них влияют установки, примененные к реализации IUnknown администратором заместителей. Для того чтобы получить указатель на реализацию IUnknown администратором заместителей, можно просто запросить с помощью QueryInterface интерфейсный заместитель для IID_IUnknown. Следующий фрагмент кода демонстрирует эту технологию, отключая защиту как для интерфейсного заместителя, так и для его администратора заместителей:

void TurnOffAllSecurity(IApe *pApe) {

IUnknown *pUnkProxyManager = 0;

// get a pointer to the proxy manager

// получаем указатель на администратор заместителей

HRESULT hr = pApe->QueryInterface(IID_IUnknown, (void**)&pUnkProxyManager);

assert(SUCCEEDED(hr));

// set blanket for proxy manager

// устанавливаем защиту для администратора заместителей

hr = CoSetProxyBlanket(pUnkProxyManager, RPC_C_AUTHN_NONE, RPC_C_AUTHZ_NONE, О, RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);

assert(SUCCEEDED(hr));

// set blanket for interface proxy

// устанавливаем защиту для интерфейсного заместителя

hr = CoSetProxyBlanket(pApe, RPC_C_AUTHN_NONE, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);

assert(SUCCEEDED(hr));

// release temporary pointer to proxy manager

// освобождаем временный указатель на администратор заместителей

pUnkProxyManager->Release();

}

Хотя представляется возможным установить и запросить защиту для администратора заместителей, невозможно скопировать администратор заместителей с помощью IClientSecurity::CopyProxy, так как это нарушило бы правила идентификации COM.

Когда ORPC-запрос направляется интерфейсной заглушке, COM создает объект контекста вызова (call context object), представляющий различные аспекты вызова, в том числе установки защиты того интерфейсного заместителя, который отправил этот запрос. COM связывает этот контекстный объект с потоком, который будет выполнять вызов метода. Библиотека COM выставляет API-функцию CoGetCallContext, позволяющую реализациям метода получить контекст для текущего вызова метода:

HRESULT CoGetCallContext ([in] REFIID riid, [out, iid_is(riid)] void **ppv);

В Windows NT 4.0 единственным интерфейсом, доступным для контекстного объекта вызова, является интерфейс IServerSecurity:

[local, object, uuid(0000013E-0000-0000-C000-000000000046)]

interface IServerSecurity : IUnknown {

// get caller's security settings

// получаем установки защиты вызывающей программы

HRESULT QueryBlanket( [out] DWORD *pAuthnSvc,

// authentication pkg

// модуль аутентификации

[out] DWORD *pAuthzSvc,

// authorization pkg

// модуль авторизации

[out] OLECHAR **pServerName,

// server principal

// серверный принципал

[out] DWORD *pAuthnLevel,

// authentication level

// уровень аутентификации

[out] DWORD *pImpLevel,

// impersonation level

// уровень заимствования прав

[out] void *pPrivs,

// client principal

// клиентский принципал

[out] DWORD *pCaps

// EOAC flags

// флаги EOAC

);

// start running with credentials of caller

// начинаем выполнение с полномочиями вызывающей программы

HRESULT ImpersonateClent(void);

// stop running with credentials of caller

// заканчиваем выполнение с полномочиями вызывающей программы

HRESULT RevertToSelf(void);

// test for Impersonation

// тест для заимствования прав BOOL

IsImpersonating(void);

}

IServerSecurity::QueryBlanket возвращает установки полной защиты, фактически использованные для текущего ORPC-вызова (которые могут несколько отличаться от клиентских установок благодаря специфическому для SSP повышению уровней). Как было в случае с IClientSecurity::QueryBlanket, функции IServerSecurity::QueryBlanket также разрешается передавать нуль вместо неиспользуемых параметров. Ниже приведен пример реализации метода, которая гарантирует, что вызывающая программа обеспечила возможность шифрования перед обработкой вызова:

STDMETHODIMP Gorilla::SwingFromTree(/*(in]*/ long nTreeID) {

// get current call context

// получаем контекст текущего вызова IServerSecurity *pss = 0;

HRESULT hr = CoGetCallContext(IID_IServerSecurity, (void**)&pss);

DWORD dwAuthnLevel;

if (SUCCEEDED(hr)) {

// get authentication level of current call

// получаем уровень аутентификации текущего вызова

hr = pss->QueryBlanket(0, 0, 0, &dwAuthnLevel, 0, 0, 0);

pss->Release(); }

// verify proper authentication level

// проверяем правильность уровня аутентификации

if (FAILED(hr) || dwAuthnLevel != RPC_C_AUTHN_LEVEL_PKT_PRIVACY)

hr = APE_E_NOPUBLICTREE;

else hr = this->ActuallySwingFromTree(nTreeID);

return hr;

}

Как было в случае с IClientSecurity, каждый метод IServerSecurity доступен в качестве удобной API-функции. Приводимая ниже реализация метода использует удобную подпрограмму вместо явного вызова интерфейса IServerSecurity

STDMETHODIMP Gorilla::SwingFromTree(/*[in]*/ long nTreeID) {

DWORD dwAuthnLevel;

// get authentication level of current call

// получаем уровень аутентификации текущего вызова

HRESULT hr = CoQueryClientBlanket(0, 0, 0, &dwAuthnLevel, 0, 0, 0);

// verify proper authentication level

// проверяем правильность уровня аутентификации

if (FAILED(hr) || dwAuthnLevel != RPC_C_AUTHN_LEVEL_РКТ_PRIVACY)

hr = АРЕ_Е_NOPUBLICTREE;

else hr = this->ActuallySwingFromTree(nTreeID);

return hr;

}

И снова мы видим, что последняя версия требует меньше кода и поэтому вероятность ошибок в ней меньше.

Метод IServerSecurity::QueryBlanket также позволяет разработчику объекта находить идентификатор защиты вызывающей программы через параметр pPrivs. Как и в случае с полномочиями, передаваемыми в IClientSecurity::SetBlanket , точный формат этого идентификатора является специфическим для конкретного модуля защиты. Для NTLM этот формат является просто строкой вида Authority\AccountName

Следующая реализация метода отыскивает идентификатор защиты вызывающей программы с помощью API-функции CoQueryClientBlanket:

STDMETHODIMP Gorilla::EatBanana() {

OLECHAR *pwszClientPrincipal = 0;

// get security identifier of caller

// получаем идентификатор защиты вызывающей программы

HRESULT hr = CoQueryClientBlanket(0, 0, 0, 0, 0, (void**)&pwszClientPrincipal, 0);

// log user name

// регистрируем имя пользователя

if (SUCCEEDED(hr)) {

this->LogCallerIDToFile(pwszClientPrincipal);

hr = this->ActuallyEatBanana();

}

return hr;

}

При вызове CoQueryClientBlanket для успешного возвращения идентификатора защиты вызывающей программы последняя должна определить:

По крайней мере RPC_C_IMP_LEVEL_IDENTIFY как автоматический (или явный) уровень заимствования прав;

По крайней мере RPC_C_AUTHN_LEVEL_CONNECT как автоматический (или явный) уровень аутентификации.

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

Точно так же, как можно полностью контролировать установки защиты, использующиеся при вызове метода с помощью интерфейса IClientSecurity , представляется полезным контролировать установки защиты, использованные при вызове на активацию. К сожалению, активационные вызовы являются глобальными API-функциями, не имеющими соответствующего администратора заместителей, откуда можно было бы получить интерфейс IClientSecurity. Для того чтобы позволить вызывающим программам задавать установки защиты для активационных вызовов, каждый активационный вызов принимает структуру СОSERVERINFO:

typedef struct _COSERVERINFO {

DWORD dwReserved1;

LPWSTR pwszName; COAUTHINFO * pAuthInfo;

DWORD * dwReserved2;

} COSERVERINFO;

В одной из предыдущих глав было отмечено, что элемент данных pwszName позволяет вызывающей программе осуществлять явный контроль того, какая хост-машина будет обслуживать активационный запрос. Третий элемент данных, pAuthInfo, указывает на структуру данных, которая позволяет вызывающей программе контролировать установки защиты, использованные при осуществлении активационного вызова. Этот параметр является указателем на структуру COAUTHINFO, определенную следующим образом:

typedef struct _COAUTHINFO {

DWORD dwAuthnSvc;

DWORD dwAuthzSvc;

LPWSTR pwszServerPrincName;

DWORD dwAuthnLevel;

DWORD dwImpersonationLevel;

COAUTHIDENTITY * pAuthIdentityData;

DWORD dwCapabilities;

} COAUTHINFO;

Эти элементы данных соответствуют параметрам IClientSecurity::SetВlanket, однако используются только во время активационного вызова и не влияют на результирующий интерфейсный заместитель.

Следующий фрагмент кода осуществляет активационный вызов, используя структуру COAUTHINFO, чтобы заставить SCM использовать при активационном вызове шифрование (RPC_C_AUTHN_LEVEL_PKT_PRIVACY):

void CreateSecretChimp(IApe *&rpApe) {

rpApe = 0;

// create a COAUTHINFO that specifies privacy

// создаем COAUTHINFO, которая определяет секретность

COAUTHINFO cai = { RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_IMP_LEVEL_IDENTIFY, 0, 0 };

// issue an activation call using the COAUTHINFO

// осуществляем активационный вызов с использованием COAUTHINFO

COSERVERINFO csi = { 0, 0, &cai, 0 };

IApeClass *pac = 0;

hr = CoGetClassObject(CLSID_Chimp, CLSCTX_ALL, &csi, IID_IApeClass, (void**)&pac);

assert(SUCCEEDED(hr));

// the activation call occurred with encryption,

// but рас is using automatic security settings

// активационный вызов произошел с шифрованием,

// но пакет использует автоматические установки защиты

hr = pac->CreateApe(&rpApe);

pac->Release();

return hr;

}

Важно отметить, что, поскольку структура COAUTHINFO оказывает воздействие только на сам активационный вызов, результирующий интерфейсный заместитель IApeClass будет использовать автоматические установки защиты, установленные более ранним вызовом CoInitializeSecurity. Это означает, что вызов метода IApeClass::CreateApe будет использовать автоматические установки защиты, а не те, которые определены структурой COAUTHINFO . Для того чтобы гарантировать применение шифрования во время создания или обработки нового Chimp, необходимо модифицировать функцию так, чтобы она ставила полную защиту на заместители обоих интерфейсов – IApeClass и IАре:

// encrypt calls on IApeClass reference

// зашифровываем вызовы на ссылку на IApeClass CoSetProxyBlanket(pac, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);

// issue call to create object

// осуществляем вызов для создания объекта

pac->CreateApe(&rpApe);

// encrypt calls on IApe reference

// зашифровываем вызовы на ссылку на IApe

CoSetProxyBlanket(rpApe, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);

Использование явного вызова COAUTHIDENTITY во время активации может позволить вызывающей программе создавать объекты в процессах, которые в противном случае были бы недоступны принципалу вызывающего процесса. Однако в этом случае вызывающая программа должна гарантировать, что администратор заместителей использует эти же самые полномочия при освобождении интерфейсного указателя, иначе будет утечка ресурсов со стороны сервера. Как уже упоминалось ранее в этой главе, полная защита администратора заместителей контролируется отдельно путем вызова метода IClientSecurity::SetBlanket на реализацию IUnknown администратором заместителей.

 

Контроль доступа

Как уже упоминалось ранее в этой главе, каждый процесс COM может защитить сам себя от несанкционированного доступа. COM рассматривает контроль доступа на двух уровнях: права запуска (launch permissions) и права доступа (access permissions). Права запуска используются, чтобы определить, какие пользователи могут запускать серверные процессы при осуществлении активационных вызовов к SCM. Права доступа определяют, какие пользователи могут обращаться к объектам процесса после того, как сервер уже запущен. Оба типа контроля доступа можно сконфигурировать при помощи DCOMCNFG.EXE, но только права доступа могут быть заданы программно на этапе выполнения (поскольку после того, как сервер запущен, уже слишком поздно отказывать пользователю в правах запуска). Вместо этого право запуска предоставляется диспетчеру управления сервнсами SCM во время активации.

Когда SCM решает, что должен быть запущен новый серверный процесс, он пытается получить дескриптор защиты NT SECURITY_DESCRIPTOR, описывающий, каким пользователям разрешено запускать серверный процесс. В первую очередь SCM проверяет AppID класса для явной установки прав запуска. Эта установка приходит в форме сериализованного дескриптора защиты NT, который хранится в именованной величине LaunchPermission AppID:

[HKCR\AppID\{27EE6A4D-DF65-1d0-8C5F-0080C73925BA}]

LaunchPermission=

Если эта именованная величина отсутствует, SCM пытается прочитать общие для всей машины права запуска из такой именованной величины:

[HKEY_LOCAL_MACHINE\Software\Microsoft\OLE]

DefaultLaunchPermission=

Обе эти установки могут быть модифицированы с помощью DCOMCNFG.EXE. Если не найден ни один из этих ключей реестра, то COM запретит запуск кому бы то ни было. Если же SECURITY_DESCRIPTOR найден, SCM проверяет идентификатор защиты активизирующей вызывающей программы (формально называемой активизатором – actiuator) по списку разграничительного контроля доступа DACL (Discretionary Access Control List), имеющемуся в дескрипторе, чтобы определить, имеет ли активизатор полномочия на запуск сервера. Если активизатор не имеет необходимых полномочий, то следует отказ на активационный вызов с HRESULT E_ACCESSDENIED, и никаких процессов не запускается. В случае успешной проверки SCM запускает серверный процесс и продолжает выполнение активационного запроса.

Права запуска определяют только, какие пользователи могут или не могут начинать серверные процессы во время активации. Эта проверка всегда выполняется SCM на основе информации, записанной в реестре. Права доступа определяют, какие пользователи могут действительно связываться с объектами серверного процесса. Эта проверка осуществляется библиотекой COM при каждом запросе на установку соединения, приходящем от клиента. Для контроля установок прав доступа к процессу разработчики могут использовать API-функцию CoIntializeSecurity.

Напомним, что процессы, не вызывающие явно функцию CoInitializeSecurity, автоматически используют список контроля доступа, записанный под ключом реестра AppID приложения:

[HKCR\AppIO\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]

AccessPermission=

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

Приложения, явно вызывающие CoInitializeSecurity, могут вручную контролировать, каким вызывающим программам разрешен доступ к объектам, экспортируемым данным процессом. По умолчанию первый параметр CoIntializeSecurity принимает указатель на SECURITY_DESCRIPTOR NT. Если вызывающая программа передает в качестве этого параметра нулевой указатель, то COM не будет осуществлять никакого контроля входящих вызовов. Это разрешает вызовы от любого аутентифицированного принципала защиты. Если и клиент, и сервер укажут RPC_C_AUTHN_LEVEL_NONE, то COM разрешит вызовы от кого угодно, независимо от его аутентификации. Если же в вызывающей программе имеется легальный указатель на дескриптор защиты, то COM с помощью DACL этого дескриптора защиты определит, каким вызывающим программам разрешен доступ к объектам процесса. Заголовки SDK определяют так называемый флаг прав (COM_RIGHTS_EXECUTE), который используется при создании DACL для явного разрешения или запрета пользователям на связь с объектами процесса.

Хотя и допускается использовать API-функции Win32 для создания SECURITY_DESCRIPTOR с целью передачи его в CoInitializeSecurity, этот способ контроля доступа к объектам процесса не является предпочтительным, в основном по причине темной природы API-функций защиты Win32. Для упрощения программирования в COM контроля доступа в реализации COM для Windows NT 4.0 Service Pack 2 разработчикам разрешено указывать тот объект COM, который будет использоваться для выполнения проверки доступа при установке новых соединений. Этот объект регистрируется библиотекой COM во время выполнения CoInitializeSecurity и должен реализовать интерфейс IAccessControl:

[object, uuid(EEDD23EO-8410-11CE-A1C3-08002B2B8D8F)]

interface IAccessControl : IUnknown {

// add access allowed rights for a list of users

// добавляем разрешенные права доступа для списка пользователей

HRESULT GrantAccessRights([in] PACTRL_ACCESSW pAccessList);

// explicitly set the access rights for a list of users

// явно устанавливаем права доступа для списка пользователей

HRESULT SetAccessRights([in] PACTRL_ACCESSW pAccessList

// users+rights

// пользователи + Права

);

// set the owner/group IDs of the descriptor

// устанавливаем идентификаторы владельца/группы для дескриптора

HRESULT Set0wner(

[in] PTRUSTEEW pOwner, // owner ID

// ID владельца

[in] PTRUSTEEW pGroup // group ID

// ID группы

);

// remove access rights for a list of users

// удаляем права доступа для списка пользователей

HRESULT RevokeAccessRights(

[in] LPWSTR lpProperty, // not used

// не используется

[in] ULONG cTrustees, // how many users

// сколько имеется пользователей

[in, size_is(cTrustees)] TRUSTEEW prgTrustees[] // users

// пользователи

);

// get list of users and their rights

// получаем список пользователей и их прав

HRESULT GetAllAccessRights(

[in] LPWSTR lpProperty, // not used

// не используется

[out] PACTRL_ACCESSW *ppAccessList, // users+rights

// пользователи + права

[out] PTRUSTEEW *ppOwner, // owner ID

// ID владельца

[out] PTRUSTEEW *ppGroup // group ID

// ID группы

);

// called by COM to allow/deny access to an object

// вызывается COM для разрешения/запрета доступа к объекту

HRESULT IsAccessAllowed(

[in] PTRUSTEEW pTrustee, // caller's ID

// ID вызывающей программы

[in] LPWSTR lpProperty, // not used

// не используется

[in] ACCESS_RIGHTS Rights, // COM_RIGHTS_EXECUTE

[out] BOOL *pbAllowed // yes/no!

// да/нет!

);

}

Этот интерфейс предназначен для того, чтобы разработчики могли создавать объекты контроля доступа на основе статических таблиц данных, преобразующих имена принципалов в права доступа. Интерфейс основывается на новом Windows NT 4.0 API защиты на базе опекуна (trustee), то есть пользователя, обладающего правами доступа к объекту. Основным типом данных, используемым этим API, является TRUSTEE:

typedef struct _TRUSTEE_W {

struct _TRUSTEE_W *pMultipleTrustee;

MULTIPLE_TRUSTEE_OPERATION MultipleTrusteeOperation;

TRUSTEE_FORM TrusteeForm;

TRUSTEE_TYPE TrusteeType;

switch_is(TrusteeForm)]

union {

[case(TRUSTEE_IS_NAME)]

LPWSTR ptstrName;

[case(TRUSTEE_IS_SID)]

SID *pSid;

};

} TRUSTEE_W, *PTRUSTEE_W, TRUSTEEW, *PTRUSTEEW;

Этот тип данных используется для описания принципала защиты. Первые два параметра, pMultipleTrustee и MultipleTrusteeOperation, позволяют вызывающей программе отличать настоящие регистрационные имена (logins – логины) от попыток заимствования прав. Пятый параметр, ptstrName/pSid, содержит либо идентификатор защиты NT (security identifier – SID), либо текстовое имя учетной записи, подлежащее идентификации. При этом третий параметр, TrusteeForm, указывает, какой именно член объединения (union member) используется. Четвертый параметр, TrusteeType, указывает, является ли данный принципал учетной записью пользователя или группы.

Для связывания опекуна с полномочиями, которые ему даны или в которых ему отказано, в Win32 API предусмотрен тип данных ACTRL_ACCESS_ENTRY:

typedef struct _ACTRL_ACCESS_ENTRYW {

TRUSTEE_W Trustee; // who?

// кто?

ULONG fAccessFlags; // allowed/denied?

// разрешено/запрещено?

ACCESSRIGHTS Access;// which rights?

// какие права?

ACCESSRIGHTS ProvSpecificAccess; // not used by COM

// в COM не используется

INHERIT_FLAGS Inheritance; // not used by COM

// в COM не используется

LPWSTR lpInheritProperty; // not used by COM

// в COM не используется

} ACTRL_ACCESS_ENTRYW, *PACTRL_ACCESS_ENTRYW;

а также тип данных для создания списков элементов для опекунов/полномочий:

typedef struct _ACTRL_ACCESS_ENTRY_LISTW {

ULONG cEntries;

[size_is(cEntries)] ACTRL_ACCESS_ENTRYW *pAccessList;

} ACTRL_ACCESS_ENTRY_LISTW, *PACTRL_ACCESS_ENTRY_LISTW;

И наконец, в Win32 предусмотрено еще два дополнительных типа данных, которые позволяют связывать элементы списков доступа с именованными признаками.

typedef struct _ACTRL_PROPERTY_ENTRYW {

LPWSTR lpProperty; // not used by COM

// не используется в COM

ACTRL_ACCESS_ENTRY_LISW *pAccessEntryList;

ULONG fListFlags; // not used by COM

// не используется в COM

} ACTRL_PROPERTY_ENTRYW, *PACTRL_PROPERTY_ENTRYW;

typedef struct _ACTRL_ALISTW {

ULONG cEntries;

[size_is(cEntries)]

ACTRL_PROPERTY_ENTRYW *pPropertyAccessList;

} ACTRL_ACCESSW, *PACTRL_ACCESSW;

Хотя в настоящее время COM не использует возможности контроля по каждому признаку, заключенному в этих двух типах данных, тип данных ACTRL_ACCESSW все же используется в интерфейсе IAccessControl для представления списков контроля доступа. Дело в том, что этот интерфейс широко используется также в службе директорий Windows NT 5.0, где требуется контроль доступа по каждому признаку.

В COM предусмотрена реализация интерфейса IAccessControl (CLSID_DCOMAccessControl), которую вызывающие программы могут заполнять явными именами учетных записей и правами доступа, используя типы данных контроля доступа NT 4.0. Следующий фрагмент кода использует эту реализацию для создания объекта контроля доступа, разрешающего доступ для встроенной учетной записи SYSTEM и для пользователей в группе Sales\Managers, но запрещающего доступ для отдельного пользователя Sales\Bob:

HRESULT CreateAccessControl(IAccessControl * &rpac)

{

rpac = 0;

// create default access control object

// создаем объект контроля доступа по умолчанию

HRESULT hr = CoCreateInstance(CLSID_DCOMAccessControl,

0, CLSCTX_ALL, IID_IaccessControl,

(void**)&rpac);

if (SUCCEEDED(hr)) {

// build list of users/rights using NT4 security data types

// создаем списов пользователей/прав, используя типы данных защиты из NT4

ACTRL_ACCESS_ENTRYW rgaae[] = {

{ { 0, NO_MULTIPLE_TRUSTEE, TRUSTEE_IS_NAME,

TRUSTEE_IS_USER, L"Sales\\Bob" },

ACTRL_ACCESS_DENIED, COM_RIGHTS_EXECUTE, 0,

NO_INHERITANCE, 0 },

{ { 0, NO_MULTIPLE_TRUSTEE, TRUSTEE_IS_NAME,

TRUSTEE_IS_GROUP, L"Sales\\Managers" },

ACTRL_ACCESS_ALLOWED, COM_RIGHTS_EXECUTE, 0,

NO_INHERITANCE, 0 },

{ { 0, NO_MULTIPLE_TRUSTEE, TRUSTEE_IS_NAME,

TRUSTEE_IS_USER, L"NT AUTHORITY\\SYSTEM" },

ACTRL_ACCESS_ALLOWED, COM_RIGHTS_EXECUTE, 0,

NO_INHERITANCE, 0 }

};

ACTRL_ACCESS_ENTRY_LISTW aael =

{ sizeof(rgaae)/sizeof(*rgaae), rgaae };

ACTRL_PROPERTY_ENTRYW ape = { 0, &aael, 0 };

ACTRL_ACCESSW aa = { 1, &ape };

// present list of users+rights to Access Control object

// представляем список пользователей + прав объекту контроля доступа

hr = rpac->SetAccessRights(&aa);

}

return hr;

}

Имея эту функцию, приложение может связать вновь созданный объект контроля доступа с его процессом следующим образом:

IAccessControl *pac = 0;

HRESULT hr = CreateAccessControl(pac);

assert(SUCCEEDED(hr));

hr = CoInitializeSecurity(pac, -1, 0, 0,

RPC_C_AUTHN_LEVEL_PKT, RPC_C_IMP_LEVEL_IDENTIFY, 0,

EOAC_ACCESS_CONTROL,

// use IAccessControl

// используем IAccessControl

0);

assert(SUCCEEDED(hr));

pac->Release();

// COM holds reference until last CoUninitialize

// COM сохраняет ссылку до последнего CoUninitialize

Флаг EOAC_ACCESS_CONTROL показывает, что первый параметр в функции СоInitializeSecurity является указателем на интерфейс IAccessControl, а не указателем на SECURITY_DESCRIPTOR NT. При каждом поступающем запросе на связь COM будет использовать метод этого объекта IsAccessAllowed для определения того, разрешен или запрещен доступ к объектам процесса. Отметим, что хотя этот код должен исполняться до первого интересного вызова COM, вызов CoCreateInstance для получения реализации по умолчанию IAccessControl является допустимым, так как COM не рассматривает его как интересный.

Если список авторизованных пользователей не может быть известен во время запуска процесса, то можно зарегистрировать специальную (custom) реализацию IAccessControl, которая выполняет определенного рода проверку доступа во время выполнения в своей реализации метода IsAccessAllowed. Поскольку сама COM использует только метод IsAccessAllowed, то такая специальная реализация могла бы безошибочно возвращать E_NOTIMPL для всех других методов IAccessControl. Ниже приведена простая реализация IAccessControl, позволяющая получить доступ к объектам процесса только пользователям с символом "x" в именах своих учетных записей:

class XOnly : public IAccessControl {

// Unknown methods

// методы IUnknown

STDMETHODIMP QueryInterface(REFIID riid, void **ppv) {

if (riid == IID_IAccessControl || riid == IID_IUnknown)

*ppv = static_cast(this);

else

return (*ppv = 0), E_NOINTERFACE;

((IUnknown*)*ppv)->AddRef();

return S_OK;

}

STDMETHODIMP_(ULONG) AddRef(void) { return 2; }

STDMETHODIMP_(ULONG) Release(void) { return 1; }

// IAccessControl methods

// методы IAccessControl

STDMETHODIMP GrantAccessRights(ACTRL_ACCESSW *)

{ return E_NOTIMPL; }

STDMETHODIMP SetAccessRights(ACTRL_ACCESSW *)

{ return E_NOTIMPL; }

STDMETHODIMP SetOwner(PTRUSTEEW, PTRUSTEEW)

{ return E_NOTIMPL; }

STDMETHODIMP RevokeAccessRights(LPWSTR, ULONG, TRUSTEEW[])

{ return E_NOTIMPL; }

STDMETHODIMP GetAllAccessRights(LPWSTR, PACTRL_ACCESSW_ALLOCATE_ALL_NODES *,

PTRUSTEEW *, PTRUSTEEW *)

{ return E_NOTIMPL; }

// this is the only IAccessControl method called by COM

// это единственный метод IAccessControl, вызванный COM

STDMETHODIMP IsAccessAllowed(

PTRUSTEEW pTrustee,

LPWSTR lpProperty,

ACCESS_RIGHTS AccessRights,

BOOL *pbIsAllowed)

{

// verify that trustee contains a string

// удостоверяемся, что опекун содержит строку

if (pTrustee == 0 || pTrustee->TrusteeForm != TRUSTEE_IS_NAME)

return E_UNEXPECTED;

// look for X or x and grant/deny based on presence

// ищем "X" или "x" и в зависимости от его наличия

// предоставляем или запрещаем

*pbIsAllowed = wcsstr(pTrustee->ptstrName, L"x") != 0 ||

wcsstr(pTrustee->ptstrName, L"X") != 0;

return S_OK;

}

}

Если экземпляр вышеприведенного класса C++ зарегистрирован c CoInitializeSecurity:

XOnly xo;

// declare an instance of the C++ class

// объявляем экземпляр класса C++

hr = CoInitializeSecurity(static_cast(&xo),

–1, 0, 0, RPC_C_AUTHN_LEVEL_PKT,

RPC_C_IMP_LEVEL_IDENTIFY, 0,

EOAC_ACCESS_CONTROL,

// use IAccessControl

// используем IAccessControl

0);

assert(SUCCEEDED(hr));

то от пользователей, не имеющих "x" в именах своих учетных записей, никакие поступающие вызовы не будут приняты. Поскольку имя опекуна содержит в качестве префикса имя домена, этот простой тест также предоставит доступ учетным записям пользователей, принадлежащих к доменам, содержащим "x" в своих именах. Хотя этот тест доступа вряд ли будет слишком полезен, он демонстрирует технологию использования специального объекта IAccessControl с CoInitializeSecurity.

 

Управление маркерами

Под Windows NT каждый процесс имеет маркер доступа (access token), представляющий полномочия принципала защиты. Этот маркер доступа создается во время инициализации процесса и содержит различные виды информации о пользователе, в том числе его идентификатор защиты NT (SID), список групп, к которым принадлежит пользователь, а также список привилегий, которыми он обладает (например, может ли пользователь прекращать работу системы, может ли он менять значение системных часов). Когда процесс пытается получить доступ к ресурсам ядра безопасности (например, к файлам, ключам реестра, семафорам), контрольный монитор защиты NT (SRM – Security Reference Monitor) использует маркер вызывающей программы в целях аудита (отслеживания действий пользователей путем записи в журнал безопасности выбранных типов событий безопасности) и контроля доступа.

Когда в процесс поступает сообщение об ORPC-запросе, COM организует выполнение вызова соответствующего метода или в RPC-потоке (в случае объектов, расположенных в МТА), или в потоке, созданном пользователем (в случае объектов, расположенных в STA). В любом случае метод выполняется с использованием маркера доступа, соответствующего данному процессу. В целом этого достаточно, так как это позволяет разработчикам объекта прогнозировать, какие привилегии и права будут иметь их объекты, независимо от того, какой пользователь осуществляет запрос. В то же время иногда бывает полезно, чтобы метод выполнялся с использованием прав доступа клиента, вызывающего метод; чтобы можно было либо ограничить, либо усилить обычные права и привилегии объекта. Для поддержки такого стиля программирования в Windows NT допускается присвоение маркеров защиты отдельным потокам. Если поток имеет свой собственный маркер, контрольный монитор защиты не использует маркер процесса. Вместо него для выполнения аудита и контроля доступа используется маркер, присвоенный потоку. Хотя есть возможность программно создавать маркеры и присваивать их потокам, в COM предусмотрен гораздо более прямой механизм создания маркера на основе ORPC-запроса, обслуживаемого текущим потоком. Этот механизм раскрывается разработчикам объекта посредством контекстного объекта вызова, то есть вспомогательного объекта, который содержит информацию об операционном окружении серверного объекта.

Напоминаем, что контекстный объект вызова сопоставляется с потоком, когда ORPC-запрос направляется на интерфейсную заглушку. Разработчики объекта получают доступ к контексту вызова через API-функцию CoGetCallContext. Контекстный объект вызова реализует интерфейс IServerSecurity:

[local, object, uuid(0000013E-0000-0000-C000-000000000046)]

interface IServerSecurity : IUnknown {

// get caller's security settings

// получаем установки защиты вызывающей программы HRESULT

QueryBlanket(

[out] DWORD *pAuthnSvc, // authentication pkg

// модуль аутентификации

[out] DWORD *pAuthzSvc, // authorization pkg

// модуль авторизации

[out] OLECHAR **pServerName, // server principal

// серверный принципал

[out] DWORD *pAuthnLevel, // authentication level

// уровень аутентификации

[out] DWORD *pImpLevel, // impersonation level

// уровень заимствования прав

[out] void **pPrivs, // client principal

// клиентский принципал

[out] DWORD *pCaps // EOAC flags

// флаги EOAC

);

// start running with credentials of caller

// начинаем выполнение с полномочиями вызывающей программы

HRESULT ImpersonateClient(void);

// stop running with credentials of caller

// заканчиваем выполнение с полномочиями вызывающей программы

HRESULT RevertToSelf(void);

// test for impersonation

// проверка заимствования прав

BOOL IsImpersonating(void);

}

В одном из предыдущих разделов этой главы уже рассматривался метод QueryBlanket. Остальные три метода используются для управления маркерами потока во время выполнения метода. Метод ImpersonateClient создает маркер доступа, основанный на полномочиях клиента, и присваивает этот маркер текущему потоку. Как только возвращается IServerSecurity::ImpersonateClient, все попытки доступа к ресурсам операционной системы будут разрешаться или запрещаться в соответствии с полномочиями клиента, а не объекта. Метод RevertToSelf заставляет текущий процесс вернуться к использованию маркера доступа, принадлежащего процессу. Если текущий вызов метода заканчивает работу во время режима заимствования прав, то COM неявно вернет поток к использованию маркера процесса. И наконец, метод IServerSecurity::IsImpersonating показывает, что использует текущий поток: полномочия клиента или маркер процесса объекта. Подобно методу QueryBlanket, два метода IServerSecurity также имеют удобные оболочки, которые вызывают CoGetCallContext изнутри и затем вызывают соответствующий метод:

HRESULT CoImpersonateClient(void);

HRESULT CoRevertToSelf(void);

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

Следующий код демонстрирует использование контекстного объекта вызова для выполнения части кода метода с полномочиями клиента:

STDMETHODIMP MyClass::ReadWrite(DWORD dwNew, DWORD *pdw0ld)

{

// execute using server's token to let anyone read the value

// выполняем с использованием маркера сервера, чтобы

// все могли прочитать данное значение

ULONG cb;

HANDLE hfile = CreateFile(«C:\\file1.bin», GENERIC_READ,

0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

if (hfile == INVALID_HANDLE_VALUE)

return MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, GetLastError());

ReadFile(hfile, pdwOld, sizeof(DWORD), &cb, 0);

CloseHandle(hfile);

// get call context object

// получаем контекстный объект вызова

IServerSecurlty *pss = 0;

HRESULT hr = CoGetCallContext(IID_IServerSecurity, (void**)&pss);

if (FAILED(hr)) return hr;

// set thread token to use caller's credentials

// устанавливаем маркер потока для использования

// полномочий вызывающей программы

hr = pss->ImpersonateClient();

assert(SUCCEEDED(hr));

// execute using client's token to let only users that can

// write to the file change the value

// выполняем с использованием маркера клиента, чтобы

// изменять это значение могли только те пользователи,

// которые имеют право записывать в файл

hfile = CreateFile(«C:\\file2.bin»,

GENERIC_READ | GENERIC_WRITE, 0, 0,

OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);

if (hfile == INVALID_HANDLE_VALUE)

hr = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32, GetLastError());

else {

WriteFile(hfile, &dwNew, sizeof(DWORD), &cb, 0);

CloseHandle(hfile);

}

// restore thread to use process-level token

// восстанавливаем режим использования потоком маркера процесса

pss->RevertToSelf();

// release call context

// освобождаем контекст вызова

pss->Release();

return hr;

}

Отметим, что первый вызов CreateFile выполняется с использованием полномочий процесса объекта, в то время как второй вызов – с полномочиями клиента. Если клиент имеет права доступа для чтения/записи в соответствующий файл, то второй вызов метода CreateFile может быть успешным, даже если обычно процесс объекта не имеет доступа к этому файлу.

Важно, что хотя методы IServerSecurity::ImpersonateClient всегда достигают цели, исключая катастрофический сбой, клиент объекта контролирует уровень заимствования прав, допускаемый результирующим маркером. Каждый интерфейсный заместитель имеет свой уровень заимствования прав, который должен быть равным одной из четырех констант (RPC_C_IMP_LEVEL_ANONYMOUS, RPC_C_IMP_LEVEL_IDENTIFY, RPC_C_IMP_LEVEL_IMPERSONATE или RPC_C_IMP_LEVEL_DELEGATE). Во время демаршалинга COM устанавливает этот уровень равным величине, определенной в клиентском вызове CoInitializeSecurity; однако данная установка может быть изменена вручную с помощью IClientSecurity::SetBlanket. Когда объект вызывает IServerSecurity::ImpersonateClient, новый маркер будет ограничен уровнем, заданном в интерфейсном заместителе, который использовался в данном вызове. Это означает, что если клиент задал только уровень RPC_C_IMP_LEVEL_IDENTIFY, то объект не может получить доступ к ресурсам ядра во время выполнения с полномочиями клиента. Объект, однако, может применить API-функции Win32 OpenThreadToken или GetTokenInformation для чтения информации о клиенте (например, ID защиты, групповое членство) из маркера режима анонимного воплощения (impersonation token). Важно отметить, что пока клиент не задал уровень RPC_C_IMP_LEVEL_DELEGATE, объект не может получить доступ ни к одному из удаленных ресурсов защиты, используя полномочия клиента. В их число входят открытие файлов в удаленной файловой системе, а также выполнение аутентифицированных COM-вызовов к удаленным объектам. К сожалению, протокол аутентификации NTLM не поддерживает уровень RPC_C_IMP_LEVEL_DELEGATE, так что под Windows NT 4.0 делегирование невозможно.

Во время предыдущего обсуждения акцент делался на том, что в нормальном режиме методы объекта выполняются с использованием маркера доступа процесса объекта. Однако не обсуждался вопрос о том, как проконтролировать, какой принципал защиты должен использоваться для создания начального маркера серверного процесса. Когда SCM запускает серверный процесс, то он присваивает новому серверному процессу маркер, основанный на конфигурации именованной величины RunAs из AppID. Если же в AppID нет величины RunAs, то считается, что сервер неправильно сконфигурирован для работы в режиме распределенного доступа. Для того чтобы этот тип серверного процесса не внедрял указанные «дыры» в защите в систему, SCM запускает такие процессы с использованием того принципала защиты, который произвел запрос на активацию. Такой тип активации часто называют активацией «как активизатор» («As Activator»), так как серверный процесс выполняет тот же принципал защиты, что и запускающий пользователь. Активация типа «как активизатор» предназначена для поддержки удаленной активации старых серверов и содержит несколько ловушек. Во-первых, чтобы придерживаться семантики типа «как активизатор», COM запустит отдельный серверный процесс для каждой активационной учетной записи пользователя, независимо от того, используется ли REGCLS_MULTIPLEUSE в CoRegisterClassObject. Это вступает в серьезный конфликт с принципом расширяемости и вдобавок делает невозможным сохранение всех экземпляров класса в одном и том же процессе. Во-вторых, каждый серверный процесс запускается с маркером, ограниченным уровнем RPC_C_IMP_LEVEL_IMPERSONATE, из чего следует, что серверные процессы не имеют доступа ни к каким удаленным ресурсам или объектам.

В идеале серверные процессы конфигурируются для запуска как отдельные принципалы защиты. Управлять этим можно, помещая именованную величину RunAs в имя учетной записи в AppID:

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]

RunAs="DomainX\UserY"

Если эта именованная величина присутствует, SCM будет использовать указанное имя учетной записи для создания нового регистрационного маркера (login token) и присвоит этот маркер серверному процессу. Для правильной работы этой схемы требуются два условия. Во-первых, соответствующий пароль должен быть записан в определенном месте реестра в качестве ключа локальных средств защиты (LSA – Local Security Authority). Во-вторых, указанная учетная запись пользователя должна иметь полномочия «Вход в систему как пакетное задание» («Logon as a batch job»). При установке значения RunAs утилита DCOMCNFG.EXE обеспечивает выполнение обоих этих условий.

Для предотвращения спуфинга (spoofing, получение доступа путем обмана) классов злонамеренными программами CoRegisterClassObject проверяет, зарегистрирован ли AppID данного класса. Если AppID имеет установку RunAs, то COM гарантирует, что принципал вызывающей программы совпадает с именем принципала, записанным в реестре. Если же вызывающая программа не имеет указанной учетной записи RunAs для AppID класса, то вызов метода CoRegisterСlassObject будет отклонен и возвратится известный HRESULT CO_E_WRONG_SERVER_IDENTITY. Поскольку конфигурационные установки COM записаны в защищенной части реестра, только привилегированные пользователи могут изменять список соответствия классов и пользователей.

Важно отметить, что когда в AppID имеется явная учетная запись пользователя RunAs, то SCM всегда будет запускать серверный процесс в его собственной отдельной window-станции (window station). Это означает, что серверный процесс не может с легкостью ни создавать окна, видимые для интерактивного пользователя на данной машине, ни принимать информацию с клавиатуры, от мыши или из буфера (clipboard). Вообще говоря, такая защита полезна, поскольку не дает простым (naive) серверам COM влиять на деятельность пользователя, работающего на машине. К сожалению, иногда серверному процессу бывает необходимо связаться с авторизовавшимся (logged on) в данный момент пользователем. Одним из способов достижения этого является использование для управления window-станциями и рабочими столами (desktop) явных API-функций COM, что дает потоку возможность временно выполняться на интерактивном рабочем столе. При выполнении на интерактивном рабочем столе любые окна, которые создает поток, будут видимы интерактивному пользователю, и, кроме того, поток может получать аппаратные сообщения (hardware messages) от клавиатуры и мыши. Если же все, что нужно, – это получить от пользователя ответ типа да/нет, то на этот случай в API-функции Win32 MessageBox имеется флаг MB_SERVICE_NOTIFICATION, при выставлении которого, без какого-либо добавочного кода, на интерактивном рабочем столе появится окно сообщения.

Если требуется расширенное взаимодействие с интерактивным пользователем, то использование Win32 API window-станции может стать весьма громоздким. Лучшим подходом могло бы стать выделение компонентов пользовательского интерфейса во второй внепроцессный сервер, который сможет работать на window-станции, отличной от той, на который запущена основная иерархия объектов. Чтобы заставить серверный процесс, содержащий компоненты пользовательского интерфейса, работать при интерактивной пользовательской window-станции, COM распознает характерное значение RunAs «Interactive User» («Интерактивный пользователь»):

[HKCR\AppID\{27EE6A4D-DF65-11d0-8C5F-0080C73925BA}]

RunAs="Interactive User"

При использовании этого значения COM запускает новый серверный процесс в window-станции, соответствующей подсоединенному в текущий момент пользователю. Для запроса полномочий для нового серверного процесса COM при создании этого нового серверного процесса просто копирует маркер текущего интерактивного сеанса. Это означает, что в реестр не требуется записывать никаких паролей. К сожалению, и этот режим активации не обходится без ловушек. Во-первых, если активационный запрос поступает в момент, когда на хост-машине не зарегистрировано ни одного пользователя, то активационный запрос даст сбой с результатом E_ACCESSDENIED. Кроме того, если интерактивный пользователь выйдет из сети в тот момент, когда у серверного процесса еще есть подключенные клиенты, то серверный процесс будет преждевременно прерван, что приведет к грубому отсоединению всех существующих в тот момент заместителей. И наконец, часто невозможно предсказать, какой пользователь будет подсоединен во время активации, что усложняет обеспечение достаточных прав и привилегий доступа ко всем необходимым ресурсам для данного объекта. Эти ограничения сводят применимость такого режима активации к простым компонентам пользовательского интерфейса.

Одна интересная разновидность управления маркером и window-станцией серверного процесса относится к службам NT. Напомним, что наличие именованной величины LocalService заставляет SCM использовать для запуска серверного процесса NT Service Control Manager вместо CreateProcess или CreateProcessAsUser. При запуске серверных процессов как сервисов NT COM не контролирует, с каким принципалом запускается этот процесс просто потому, что это жестко запрограммировано в конфигурации соответствующей запущенной службы NT. В этом случае COM игнорирует именованную величину RunAs, чтобы убедиться, что случайные процессы не могут имитировать вызовы CoRegisterClassObject. Наличие именованной величины LocalService требует, чтобы вызывающая программа выполнялась как сервис NT. Если сам этот сервис сконфигурирован на запуск как встроенная учетная запись SYSTEM, то серверный процесс либо запустит интерактивную window– станцию, либо будет запущена заранее определенная window-станция, совместно используемая всеми сервисами NT в качестве SYSTEM (это зависит от того, как именно сконфигурирован сервис NT). Если вместо этого сервис NT сконфигурирован для выполнения как отдельная учетная запись пользователя, то NT Service Control Manager будет всегда запускать сервис NT под новой window– станцией, специфической для данного серверного процесса.

Одно общее соображение в пользу реализации сервера COM как сервиса NT заключается в том, что только сервисы NT способны выполняться со встроенной учетной записью SYSTEM. Эта учетная запись обыкновенно имеет больший доступ к таким локальным ресурсам, как файлы и ключи реестра. Кроме того, эта учетная запись часто является единственной, которая может выступать как часть доверительной компьютерной базы (trusted computing base) и использовать низкоуровневые службы защиты, доступ к которым был бы опасен из обычных пользовательских учетных записей. К сожалению, хотя учетная запись SYSTEM воистину всемогуща в локальной системе, она полностью бессильна для доступа к защищенным удаленным ресурсам, в том числе к удаленным файловым системам и к удаленным объектам COM. Это обстоятельство делает учетную запись SYSTEM отчасти менее полезной для построения распределенных систем, чем можно было бы ожидать. Вне зависимости от того, используется ли сервер как сервис NT или в качестве традиционного процесса Win32, принято создавать отдельную учетную запись пользователя для каждого приложения COM, которое имеет полные полномочия для доступа в сеть.

 

Где мы находимся?

В данной главе рассматривались вопросы, относящиеся к выделению классов в отдельные серверные процессы. COM поддерживает запуск серверных процессов на основе запросов на активацию. Эти серверные процессы должны саморегистрироваться с помощью библиотеки COM, используя CoRegisterClassObject для того, чтобы обеспечить доступ к объектам своего класса со стороны внешних клиентов. Архитектура системы безопасности COM тесно связана с собственной моделью безопасности операционной системы и основывается на трех различных понятиях. Целостность и аутентичность сообщений ORPC, которыми обмениваются клиент и объект, обеспечивается аутентификацией. Контроль доступа выявляет, какие принципалы защиты могут иметь доступ к объектам, экспортированным из данного процесса. Управление маркерами отслеживает, какие полномочия используются для запуска серверных процессов и выполнения методов объекта.

 

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

 

Основы указателей

СОМ, подобно DCE (Distributed Computing Environment – среда распределенных вычислений), ведет свое начало от языка программирования С. Хотя лишь немногие разработчики используют С для создания или использования компонентов СОМ, именно от С СОМ унаследовала синтаксис для своего языка определений интерфейсов (Interface Definition Language – IDL). Одной из наиболее сложных проблем при разработке и использовании интерфейсов является управление указателями. Рассмотрим такое простое определение метода IDL:

HRESULT f([in] const short *ps);

Если бы вызывающая программа должна была запустить этот метод так:

short s = 10;

HRESULT hr = p->f(&s);

то величину 10 следовало бы послать объекту. Если бы этому методу нужно было выйти за границы апартамента, то интерфейсный заместитель был бы обязан разыменовать указатель и передать величину 10 в сообщение ORPC-запроса.

Следующий клиентский код, хотя и написан целиком в традициях С, представляет собой более интересный случай:

HRESULT hr = p->f(0);

// pass a null pointer

// передаем нулевой указатель

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

Для того чтобы удовлетворить этим столь различным требованиям, СОМ позволяет разработчикам интерфейсов указывать точную семантику каждого параметра указателя. Чтобы показать, что указатель никогда не должен принимать нулевого значения, разработчик интерфейса может применить атрибут [ref]:

HRESULT g([in, ref] short *ps);

// ps cannot be a null ptr.

// ps не может быть нулевым указателем

Указатели, использующие атрибут [ref], называются ссылочными указателями (reference pointers). При IDL-определении, приведенном выше, следующий код со стороны клиента:

HRESULT hr = p->g(0);

// danger: passing null [ref] ptr.

// опасность: передается нулевой указатель с атрибутом [ref]

является ошибочным. И если p указывает на интерфейсный заместитель, то данный интерфейсный заместитель обнаружит нулевой указатель и возвратит вызывающей программе ошибку маршалинга, даже не передав метод текущему объекту. А чтобы сделать нулевой указатель допустимым значением параметра, в IDL-определении следует использовать атрибут [unique]:

HRESULT h([in, unique] short *ps);

// ps can be a null ptr.

// ps может быть нулевым указателем

Указатели, использующие атрибут [unique], называются уникальными указателями (unique pointers). При IDL-определении, приведенном выше, следующий код со стороны клиента:

HRESULT hr = p->h(0);

// relax: passing null [unique] ptr.

// расслабьтесь: передается нулевой указатель с атрибутом [unique]

является допустимым. Это означает, что интерфейсный заместитель должен подробно исследовать указатель перед тем, как разыменовать его. И что более важно: это означает, что интерфейсному заместителю необходимо записывать в ответ на ORPC-запрос не только разыменованную величину. Кроме нее, он должен записать тег, указывающий, был или не был передан нулевой указатель. Это добавляет к размеру ORPC-сообщения четыре байта на каждый указатель. Для большинства приложений эти добавочные четыре байта и то процессорное время, которое необходимо для выявления нулевого указателя, пренебрежимо малы по сравнению с преимуществами использования нулевых указателей в качестве параметров.

Вообще говоря, схемы [ref] и [unique] мало отличаются по эффективности. Однако до сих пор не обсуждалась еще одна проблема, связанная с указателями. Рассмотрим следующий фрагмент на IDL:

HRESULT j([in] short *ps1, [in] short *ps2);

Имея такое IDL-определение, рассмотрим теперь следующий фрагмент кода со стороны клиента:

short x = 100;

HRESULT hr = p->j(&x, &х);

// note: same ptr. passed twice

// заметим: тот же самый указатель передан дважды

Естественный вопрос: что должен делать интерфейсный заместитель при наличии одинаковых указателей? Если интерфейсный заместитель не делает ничего, тогда значение 100 будет передано в ORPC-запросе дважды: один раз для *ps1 и один раз для *ps2. Это означает, что заместитель посылает одну и ту же информацию дважды, впустую занимая сеть и тем самым уменьшая ее пропускную способность. Конечно, число байтов, занятых величиной 100, невелико, но если бы ps1 и ps2 указывали на очень большие структуры данных, то повторная передача существенно повлияла бы на производительность. Другой побочный эффект от невыявления дублирующего указателя состоит в том, что интерфейсная заглушка будет демаршалировать эти значения в два различных места памяти. Если бы семантика метода изменилась из-за тождественности двух таких указателей:

STDMETHODIMP MyClass::j(short *ps1, short *ps2)

{

if (ps1 == ps2)

return this->OneKindOfBehavior(ps1);

else

return this->AnotherKindOfBehavior(ps1, ps2);

}

то интерфейсный маршалер нарушил бы семантический контракт (semantic contract) интерфейса, что нарушило бы прозрачность экспорта в СОМ.

Наличие атрибутов указателя [ref] и [unique] означает, что память, на которую ссылается указатель, не является ссылкой для какого-либо другого указателя в вызове метода и что интерфейсный маршалер не должен осуществлять проверку на дублирование указателей. Для того чтобы показать, что указатель может ссылаться на память, на которую ссылается другой указатель, разработчику IDL следует использовать атрибут [ptr]:

HRESULT k([in, ptr] short *ps1, [in, ptr] short *ps2);

Указатели, использующие атрибут [ptr], называются полными указателями (full pointers), потому что они наиболее близки к полному соответствию с семантикой языка программирования С. Имея такое IDL-определение, следующий код со стороны клиента:

short x = 100;

HRESULT hr = p->k(&x, &x);

// note: same ptr. passed twice

// заметим: тот же самый указатель передан дважды

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

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

 

Указатели и память

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

HRESULT f([out] short *ps);

При наличии такого прототипа нижеследующий код вполне допустим с точки зрения С:

short s;

HRESULT hr = p->f(&s);

// s now contains whatever f wrote

// s теперь содержит все, что написал f

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

short *ps;

// the function says it takes a short *, so ...

// функция говорит, что она берет * типа short, следовательно ...

HRESULT hr = p->f(ps);

При рассмотрении следующей допустимой реализации функции:

STDMETHODIMP MyClass::f(short *ps)

{

static short n = 0;

*ps = n++;

return S_OK;

}

очевидно, что выделение памяти для короткого целого числа и передача ссылки на память в качестве аргумента функции является обязанностью вызывающей программы. О только что приведенной реализации заметим, что для функции неважно, откуда взялась эта память (например, динамически выделена из «кучи», объявлена как переменная auto в стеке), до тех пор, пока текущий аргумент ссылается на допустимую область памяти. Для подкрепления этого положения СОМ требует, чтобы все параметры с атрибутами [out], являющиеся указателями, были ссылочными указателями.

Ситуация становится менее очевидной, когда вместо простых целых типов используются типы, определенные пользователем. Рассмотрим следующее IDL-определение:

typedef struct tagPoint {

short x;

short у;

} Point;

HRESULT g([out] Point *pPoint);

Как и в предыдущем примере, правильной является такая схема: вызывающая программа выделяет память для значений и передает ссылку на память, выделенную вызывающей программой:

Point pt;

HRESULT hr = p->g(&pt);

Если вызывающая программа передала неверный указатель:

Point *ppt;

// random unitialized pointer

// случайный неинициализированный указатель

HRESULT hr = p->g(ppt);

// where should proxy copy x & у to?

// куда заместитель должен копировать x и у ?

то не найдется легальной памяти, куда метод (или интерфейсный заместитель) мог бы записать значения x и y.

Чем более сложные типы определяются пользователем, тем интереснее становится сценарий. Рассмотрим следующий код IDL:

[uuid(E02E5345-l473-11d1-8C85-0080C73925BA),object ]

interface IDogManager : IUnknown {

typedef struct tagHUMAN {

long nHumanID;

} HUMAN;

typedef struct tagDOG {

long nDogID;

[unique] HUMAN *pOwner;

} DOG;

HRESULT GetFromPound([out] DOG *pDog);

HRESULT TakeToGroomer([in] const DOG *pDog);

HRESULT SendToVet([in, out] DOG *pDog);

}

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

DOG fido;

// argument is a DOG *, so caller needs a DOG

// аргументом является DOG *, поэтому вызывающей программе нужен DOG

HUMAN dummy;

// the DOG refers to an owner, so alloc space?

// DOG ссылается на владельца, поэтому выделяем память?

fido.pOwner = &dummy;

HRESULT hr = p->GetFromPound(&fido);

// is this correct?

// правильно ли это?

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

СОМ разделяет указатели, участвующие в вызове метода, на две категории. Любые именованные параметры метода, являющиеся указателями, относятся к указателям высшего уровня (top-level). Любой подчиненный указатель, который получен путем разыменования указателя высшего уровня, является вложенным (embedded) указателем. В методе GetFromPound параметр pDog считается указателем высшего уровня. Подчиненный указатель pDog->pOwner рассматривается как вложенный указатель. Отметим, что определение структуры DOG использует атрибут [unique] для явной квалификации семантики указателя для элемента структуры pOwner. Если бы семантика указателя не была квалифицирована явно, разработчик интерфейса мог бы применить принятый по умолчанию во всех интерфейсах для всех вложенных указателей атрибут [pointer_default]:

[ uuid(E02E5345-1473-11d1-8C85-0080C73925BA), object,

pointer_default(ref)

// default embedded ptrs to [ref]

// по умолчанию вложенные указатели [ref]

]

interface IUseStructs : IUnknown {

typedef struct tagNODE {

long val;

[unique] struct tagNODE *pNode;

// explicitly [unique]

// явно [unique]

} NODE;

typedef struct tagFOO {

long val;

long *pVal;

// implicitly [ref]

// неявно [ref]

} FOO;

HRESULT Method([in] FOO *pFoo, [in, unique] NODE *pHead);

}

Атрибут [pointer_default] применяется только к тем вложенным указателям, семантика которых не квалифицирована явно. В приведенном выше определении интерфейса единственный указатель, к которому это относится, – это элемент данных pVal структуры FOO. Элемент pNode структуры NODE явно квалифицирован как уникальный указатель, поэтому установка [pointer_default] на него не влияет. На параметры метода pFoo и pHead атрибут [pointer_default] также не влияет, поскольку они являются указателями высшего уровня и по умолчанию [ref], если только они не квалифицированы явно иным образом (как в случае с pHead).

Основная причина, по которой вложенные указатели имеют в СОМ отдельный статус, заключается в том, что они предъявляют особые требования к организации памяти. Для параметров с атрибутом [in] различие между указателями высшего уровня и вложенными указателями не слишком существенно, так как вызывающая программа обеспечивает метод всеми значениями и поэтому должна заранее выделить память, которую эти значения будут занимать:

HUMAN bob = { 2231 };

DOG fido = { 12288, &bob };

// fido is owned by bob

// fido принадлежит bob'y

HRESULT hr = p->TakeToGroomer(&fido);

// this is correct!

// это правильно!

В то же время разграничение между указателями высшего уровня и вложенными является существенным, когда оно касается организации памяти для параметров [out] и [in,out]. Для обоих параметров, [out] и [in,out], память, на которую ссылаются указатели высшего уровня, управляется вызывающим оператором, как и в случае параметров [in]. Для вложенных же указателей, которые появляются в параметрах [out] и [in, out], память управляется вызываемым оператором (самим методом). Причина появления этого правила заключается в том, что глубина вложения типов данных может быть сколь угодно большой. Например, в таком определении типа:

typedef struct tagNODE {

short value;

[unique] struct tagNODE *pNext;

} NODE:

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

При наличии правила, по которому разработчики метода должны выделять память при инициализации любых вложенных указателей, возникает естественный вопрос, откуда методы должны получить эту память, чтобы вызывающие операторы знали, как освободить ее после прочтения всех возвращенных значений? Ответом является распределитель памяти (task allocator) СОМ-задачи. Распределителем памяти задачи СОМ называется распределитель памяти, индивидуальный для каждого процесса, используемый исключительно для выделения памяти вложенным указателям с атрибутами [out] и [in,out]. Проще всего использовать этот распределитель памяти СОМ-задачи посредством применения трех API-функций СОМ:

void *CoTaskMemAlloc(DWORD cb);

// allocate cb bytes

// размещаем cb байтов

void CoTaskMemFree(void *pv);

// deallocate memory at *pv

// освобождаем память в *pv

void *CoTaskMemRealloc(void *pv,DWORD cb);

// grow/shrink *pv

// расширяем/сжимаем *pv

Семантика этих трех функций такая же, как у их эквивалентов из динамической библиотеки С: malloc, free и realloc. Разница состоит в том, что они предназначены исключительно для выделения памяти параметрам типа вложенных указателей с атрибутами [out] и [in,out]. Другое важное отличие состоит в том, что подпрограммы из динамической библиотеки С нельзя использовать для выделения памяти в одном модуле и освобождения ее в другом. Дело в том, что детали реализации каждой динамической библиотеки С являются специфическими и изменяются при смене компилятора. Так как все участники согласились использовать один и тот же распределитель, предлагаемый СОМ, нет проблемы с освобождением клиентом памяти, которая выделена объектом, скомпилированным в отдельной DLL.

Чтобы понять, как используются на практике блоки памяти, выделенные вызываемым оператором, рассмотрим приводившийся ранее метод GetFromPound:

HRESULT GetFromPound([out] DOG *pDog);

В то время как память для объекта DOG должна быть выделена вызывающей программой (pDog является указателем высшего уровня), память для объекта HUMAN должна быть выделена реализацией метода с использованием распределителя памяти задачи (pDog->pOwner является вложенным в [out]-параметр указателем). Реализация метода выглядела бы примерно так:

STDMETHODIMP GetFromPound(/*[out]*/DOG *pDog)

{

short did = LookupNewDogId();

short hid = LookupHumanId(did);

pDog->nDogID = did;

// allocate memory for embedded pointer

// выделяем память для вложенного указателя

pDog->pOwner = (HUMAN*) CoTaskMemAlloc(sizeof(HUMAN));

if (pDog->pOwner == 0)

// not enough memory

// недостаточно памяти

return R_OUTOFMEMORY;

pDog->pOwner->nHumanID = hid;

return S_OK;

}

Отметим, что метод возвращает специальный HRESULT E_OUTOFMEMORY, указывающий на то, что операция прервана из-за нехватки памяти.

Программа, вызывающая метод GetFromPound, ответственна за освобождение любой памяти, выделенной вызываемым методом, после использования соответствующих значений:

DOG fido;

HRESULT hr = p->GetFromPound(&fido);

if (SUCCEEDED(hr)) {

printf(«The dog %h is owned by %h», fido.nDogID, fido.pOwner->nHumanID);

// data has been consumed, so free the memory

// данные использованы, поэтому освобождаем память

CoTaskMemFree(fido.pOwner);

}

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

В только что приведенном примере использован чистый [out]-параметр. Управление [in, out]– параметрами несколько более сложно. Вложенные указатели для [in, out]-параметров должны быть размещены вызывающей программой с помощью распределителя памяти задачи. Если методу требуется повторно распределить память, переданную клиентом, то метод должен сделать это с использованием CoTaskMemRealloc. Если же вызывающая программа не имеет никакой информации для передачи методу, то она может передать ему на входе нулевой указатель, и тогда метод может использовать CoTaskMemRealloc (который без проблем принимает нулевой указатель и делает то, что нужно). Подобным же образом, если у метода нет информации для обратной передачи в вызывающую программу, он может просто освободить память, на которую ссылается вложенный указатель. Рассмотрим следующее определение метода IDL:

HRESULT SendToVet([in, out] DOG *pDog);

Пусть у вызывающей программы имеется легальное значение HUMAN, которое она хочет передать как параметр. Тогда клиентский код может выглядеть примерно так:

HUMAN *pHuman = (HUMAN*)CoTaskMemAllocc(sizeof(HUMAN));

pHuman->nHumanID = 1522;

DOG fido = { 4111, pHuman };

HRESULT hr = p->SendToVet(&fido); // [in, out]

if (SUCCEEDED(hr)) {

if (fido.pOwner)

printf(«Dog is now owned by %h», fido.pOwner->nHumanID);

CoTaskMemFree(fido.pOwner);

// OK to free null ptr.

// можно освободить нулевой указатель

}

Реализация метода могла бы повторно использовать буфер, используемый вызывающей программой, или выделить новый буфер в случае, если вызывающая программа передала нулевой вложенный указатель:

STDMETHODIMP MyClass::SendToVet(/*[in, out]*/DOG *pDog)

{

if (fido.pOwner == 0)

fido.pOwner = (HUMAN*)CoTaskMemAlloc(sizeof (HUMAN));

if (fido.pOwner == 0)

// alloc failed

// сбой выделения памяти

return E_OUTOFMEMORY;

fido.pOwner->nHumanID = 22;

return S_OK;

}

Поскольку работа с [in,out]-параметрами в качестве вложенных указателей имеет ряд тонкостей, в документации на интерфейс часто повторяются правила управления памятью для вложенных указателей.

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

[ uuid(00000002-0000-0000-C000-000000000046),local,object]

interface IMalloc : IUnknown {

void *Alloc([in] ULONG cb);

void *Realloc ([in, unique] void *pv, [in] ULONG cb);

void Free([in, unique] void *pv);

ULONG GetSize([in, unique] void *pv);

int DidAlloc([in, unique] void *pv);

void HeapMinimize(void);

}

Для получения доступа к интерфейсу IMalloc распределителя памяти задачи в СОМ имеется API-функция CoGetMalloc:

HRESULT CoGetMalloc(

[in] DWORD dwMemCtx, // reserved, must be one

// зарезервировано, должно равняться единице

[out] IMalloc **ppMalloc); // put it here!

// помещаем его здесь!

Это означает, что вместо вызова удобного метода CoTaskMemAlloc:

HUMAN *pHuman = (HUMAN*)CoTaskMemAlloc(sizeof(HUMAN));

можно использовать следующую менее удобную форму:

IMalloc *pMalloc = 0;

pHuman = 0;

HRESULT hr = CoGetMalloc(1, &pMalloc);

if (SUCCEEDED(hr)) {

pHuman = (HUMAN*)pMalloc->Alloc(sizeof(HUMAN));

pMalloc->Release();

}

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

До сих пор обсуждение распределителя памяти задачи было сфокусировано на вопросах, как и когда объекты выделяют память, а клиенты – освобождают ее. Однако не обсуждалось, что происходит, когда объект и клиент размещаются в различных адресных пространствах. Это во многом связано с отсутствием различия в способах реализации клиентов и объектов при использовании интерфейсных маршалеров. СОМ-распределитель памяти задачи получает свою память из закрытого адресного пространства процессов. С учетом этого сокрытие того обстоятельства, что распределитель памяти задачи не может охватить оба адресных пространства, является делом интерфейсной заглушки и интерфейсного заместителя. Когда интерфейсная заглушка вызывает метод объекта, она маршалирует любые [out]– или [in, out]-параметры в ответное ORPC-сообщение. Как показано на рис. 7.1, по завершении этого маршалинга интерфейсная заглушка (которая в конечном счете является внутриапартаментным клиентом данного объекта) освобождает с помощью метода CoTaskMemFree любую память, выделенную вызываемой программой. Это эффективно освобождает всю память, выделенную в течение вызова метода внутри адресного пространства объекта. При получении ответного ORPC-сообщения интерфейсный заместитель с помощью метода CoTaskMemAlloc выделяет пространство для всех параметров, размещаемых в вызываемой программе.

Когда эти блоки памяти освобождаются настоящим клиентом с помощью CoTaskMemFree, это эффективно освобождает всю память, выделенную в результате вызова метода, внутри адресного пространства клиента.

Поскольку программисты печально известны своим пренебрежением к освобождению памяти, иногда бывает полезно следить за активностью распределителя памяти задачи в процессе (или отсутствием таковой активности). Для обеспечения этого контроля СОМ предлагает подключить к распределителю памяти задачи определяемый пользователем шпионский объект (spy object), который будет уведомляться до и после каждого вызова распределителя памяти. Этот шпионский объект, определяемый пользователем, должен реализовать интерфейс IMallocSpy:

[ uuid(0000001d-0000-0000-C000-000000000046),local,object ]

interface IMallocSpy : IUnknown {

ULONG PreAlloc([in] ULONG cbRequest);

void *PostAlloc([in] void *pActual);

void *PreFree([in] void *pRequest,[in] BOOL fSpyed);

void PostFree([in] BOOL fSpyed);

ULONG PreRealloc([in] void *pRequest,[in] ULONG cbRequest,

[out] void **ppNewRequest,[in] BOOL fSpyed);

void *PostRealloc([in] void *pActual, [in] BOOL fSpyed);

void *PreGetSize([in] void *pRequest, [in] BOOL fSpyed);

ULONG PostGetSize([in] ULONG cbActual,[in] BOOL fSpyed);

void *PreDidAlloc([in] void *pRequest, [in] BOOL fSpyed);

int PostDidAlloc([in] void *pRequest, [in] BOOL fSpyed, [in] int fActual);

void PreHeapMinimize(void);

void PostHeapMinimize(void);

}

Отметим, что для каждого метода IMalloc интерфейс IMallocSpy имеет два метода: один, вызываемый СОМ до того, как действующий распределитель памяти задачи начнет свою работу, и второй, вызываемый СОМ после того, как распределитель памяти выполнил свою работу. В каждом «предметоде» (premethod) предусмотренный пользователем шпионский объект может изменять параметры, передаваемые пользователем распределителю памяти. В каждом «постметоде» (postmethod) шпионский объект может изменять результаты, возвращаемые действующим распределителем памяти задачи. Это дает возможность шпионскому объекту выделять дополнительную память, чтобы добавить к каждому блоку памяти отладочную информацию. В СОМ имеется API-функция для регистрации шпиона распределения памяти (Malloc spy) всего процесса:

HRESULT CoRegisterMallocSpy([in] IMallocSpy *pms);

В каждом процессе может быть зарегистрирован только один шпион распределения памяти (CoRegisterMallocSpy возвратит CO_E_OBJISREG в том случае, если уже зарегистрирован другой шпион). Для удаления шпиона распределения в СОМ предусмотрена API-функция CoRevokeMallocSpy:

HRESULT CoRevokeMallocSpy(void);

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