КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Интерфейс ICIassFactory и использование системного реестра
СОМ-сервер Модель СОМ предоставляет возможность создания многократно используемых компонентов, независимых от языка программирования. Такие компоненты называются СОМ-серверами и представляют собой исполняемые файлы (ЕХЕ) или динамически загружаемые библиотеки (DLL), специальным образом оформленные для обеспечения возможности их универсального вызова из любой программы, написанной на поддерживающем СОМ языке программирования. При этом СОМ-сервер может выполняться как в адресном пространстве вызывающей программы (внутрипроцессный сервер — in-process server), так и в виде самостоятельного процесса (внепроцессный сервер — out-of-process server) или даже на другом компьютере (в этом случае говорят о распределенной модели СОМ — Distributed СОМ, а сервер называют удаленным). СОМ автоматически разрешает вопросы, связанные с передачей параметров (маршаллингом — marshalling) и согласованием моделей потоков клиента и сервера. СОМ-сервер — это специальным образом оформленное и зарегистрированное приложение, которое позволяет клиентам создавать реализованные на сервере объекты. Сервер в виде DLL всегда выполняется в адресном пространстве активизировавшего его приложения, то есть является внутрипроцесспым сервером. За счет этого, как правило, снижаются накладные расходы на вызов методов сервера. В то же время такой сервер менее надежен, поскольку его память не защищена от ошибок в вызывающем приложении. Кроме того, он не может выполняться на удаленной машине без приложения-посредника, создающего процесс, в который может быть загружена библиотека сервера. Примерами таких приложений могут служить службы компонентов (СОМ+) и Internet Information Services. Сервер в виде исполняемого файла представляет собой обычный исполняемый файл Windows, в котором реализована возможность создания СОМ-объектов но запросу других приложений. Примерами таких серверов являются приложения Microsoft Office. Очевидно, что для автоматизации запуска сервера необходимо где-то хранить полный путь к серверу. Для этих целей используется системный реестр. В нем можно указать имя и полный путь к СОМ-серверу. Таким образом, при обращении к серверу его местонахождение будет извлечено из системного реестра, и сервер будет запущен. Далее, у клиента должна быть возможность обратиться к СОМ-серверу для получения ссылки на интерфейсы. Для этого необходимо вернуть ссылку на некий интерфейс, он называется фабрикой классов (class factory) — IClassFactory, а затем, воспользовавшись его методом QueryInterface, можно затребовать у этого интерфейса другие интерфейсы и начать вызывать их методы. Это означает, что экземпляр объекта, реализующего данный интерфейс, должен быть создан немедленно после старта СОМ-сервера. Соответственно, экземпляр объекта должен удаляться только при окончании работы СОМ-сервера. Кроме того, интерфейс данного типа должен быть способен создавать экземпляры объектов, реализующих другие интерфейсы, в ответ на вызов метода QueryInterface. Для того чтобы он был создан при старте СОМ-сервера, конструктор класса, реализующий фабрику классов, обычно помещается в секции Initialization какого-нибудь модуля. Главный метод интерфейса IClassFactory — метод CreateInstance. В качестве параметра он принимает IID интерфейса, ссылку на который необходимо вернуть клиенту, и переменную, куда помещается ссылка на требуемый интерфейс. При реализации метода CreateInstance необходимо проверить IID всех интерфейсов, экспонируемых данной фабрикой классов. При совпадении с передаваемым в качестве параметра идентификатором возможно несколько вариантов реализации. · Если ранее не был создан экземпляр класса, реализующий требуемый интерфейс, то вызывается его конструктор. · Если уже имеется экземпляр класса, то возвращается ссылка на него и счетчик ссылок увеличивается на 1. В этом случае класс реализуется таким образом, чтобы одновременно обслуживать нескольких клиентов. · Альтернативный вариант — при наличии уже работающей копии класса все равно создается новая копия. При таком способе работы число ссылок на каждую рабочую копию всегда равно единице (при равенстве нулю рабочая копия удаляется). Класс реализуется таким образом, чтобы обслуживать одного клиента.
Для запуска СОМ-сервера могут использоваться два способа. · Вызов функции CoGetClassObject, которой в качестве параметра передается IID фабрики классов. Эта функция находит в системном реестре имя и путь к серверу, который реализует данную фабрику классов, загружает и запускает его. Ссылка на фабрику классов передается клиенту. Клиент далее может вызывать метод CreateInstance фабрики классов для получения экземпляров требуемых СОМ-объектов. Этот способ рекомендуется, если предполагается создать большое количество одинаковых объектов. · Вызов функции CoCreateInstance, которая внутри себя вызывает метод CoGetClassObject, а затем автоматически вызывает метод CreateInstance фабрики классов для получения ссылки на требуемый интерфейс. Этот способ проще и его лучше использовать, если объект создается в одном экземпляре.
Теперь следует рассмотреть данные, которые заносятся в системный реестр при регистрации СОМ-сервера. Данные о СОМ-сервере содержатся в секции HKEY_ CLASSES_ROOT. Первая секция сопоставляет CLSID объекта его строковому наименованию (рис. 3.1).
Рис. 3.1. Регистрация строкового имени СОМ-сервера в секции HKEY_CLASSES_ROOT Если СОМ-сервер имеет несколько фабрик классов, то для каждой из них создается такая секция. Следующая информация, которая помещается в системный реестр, — путь к СОМ-серверу и его имя (рис. 3.2). Эта информация помещается в секцию, заголовок которой совпадает с идентификатором CLSID объекта.
Рис. 3.2. Регистрация имени и пути к СОМ-серверу в секции HKEY_CLASSES_ROOT.
Фабрика классов может поддерживать режим отдельного экземпляра (single instance), либо режим множественных экземпляров (multiple instances). Режим отдельного экземпляра означает, что в ответ на требование клиентов о передаче ссылки на фабрику классов запускается отдельная копия сервера. В этом случае при работе с многочисленными клиентами на компьютере выполняется несколько копий сервера одновременно. Если же фабрика классов поддерживает режим множественных экземпляров (multiple instances), то первоначально проверяется, выполняется ли уже СОМ-сервер на данном компьютере. Если сервер уже запущен, то клиенту передается ссылка на требуемую фабрику классов, а если нет — то происходит загрузка, запуск и передача ссылки. В таком режиме на компьютере выполняется всегда одна копия сервера, независимо от того, сколько клиентов к нему обратилось. Серверы в виде исполняемых файлов, написанные на Delphi, автоматически регистрируются при первом запуске программы на компьютере. Для регистрации серверов DLL служит утилита Regsvr32, поставляемая в составе Windows, либо TRegSvr из поставки Delphi.
Дата добавления: 2014-01-05; Просмотров: 432; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |