1.5.2 Ход выполнения работы

1. Ознакомиться с краткими теоретическими сведениями, текстом учебного проекта и материалами к данной лабораторной работе.

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

3. Разработать клиентское приложение, в котором будет осуществляться прием и отображение данных, получаемых по запросу от сервера.

4. Организовать обмен данными, возвращаемыми Вашими функциями Windows API, между серверным и клиентским приложениями с использованием технологии именованных каналов.

1.5.3 Контрольные вопросы к лабораторной работе 5

1. Чем является именованный канал с точки зрения операционной системы и в каких приложениях он используется?

2. Опишите порядок действий приложений при создания серверного конца канала, подключения к нему приложений и обмена данными между ними, а также завершения работы с каналом.

3. Опишите процесс организации отложенного ввода-вывода (режим overlapped) при чтении-записи данных в канал. Какие проблемы обмена данными требуют использования такого режима работы?

4. Каким образом многопоточность серверного приложения помогает при обмене данными через каналы с приложениями-клиентами?

5. Каковы особенности использования дескриптора доступа TSecurityDescriptor при создании и использовании каналов?

6. Как Вы считаете, на каком уровне семиуровневой модели OSI (модели сетевого взаимодействия открытых систем) находятся каналы Windows?

7. Запишите имя канала в соответствии с соглашением UNC для подключения клиента к серверу (сетевое имя сервера mycomp, имя канала mychannel).

8. Какие действия должно выполнить приложение для открытия серверного "конца" канала и его использования?

9. Что означают именованные константы, используемые при вызове функции CreateNamedPipe  для указания режима открытия канала?

10. Могут ли именованные каналы быть организованы и использованы в операционной системе Linux?

1.6 Лабораторная работа №6. Использование технологии сом при разработке приложений в Delphi. Создание и использование внутреннего сервера

Цель работы: получить навыки создания внутреннего сервера и клиентов СОМ при разработке приложений в Delphi.

1.6.1 Краткие теоретические сведения

Под термином СОМ-ориентированные технологии подразумевается набор разнообразных технологий, опирающихся на модель СОМ как на некий фундамент. В этот набор входят такие технологии, как серверы и клиенты СОМ, элементы управления ActiveX, связывание и внедрение объектов (Object Linking and Embedding, или OLE), автоматизация (Automation) u сервер транзакций Microsoft (Microsoft Transaction Server, или MTS). Еще несколько лет назад рассмотрение подобных тем касалось, в основном, технологии OLE, которая предоставляет метод совместного использования данных различными приложениями, главным образом, посредством внедрения или связывания данных, ассоциированных с одним приложением, с данными, ассоциированными с другим приложением (например, внедрение электронной таблицы в документ текстового процессора). Однако СОМ – это нечто гораздо большее, чем просто OLE-ориентированные операции с текстовым процессором.

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

Основы СОМ

COM: Component Object Model

Component Object Model (модель многокомпонентных объектов) – COM - представляет собой "фундамент", на котором построены технологии ActiveX и OLЕ. СОМ определяет API- и двоичный стандарты для связи объектов, не зависящих от языка программирования или платформы (теоретически). СОМ-объекты подобны уже известным вам VCL-объектам, за исключением того, что они содержат специализированные методы и свойства, а не поля данных.

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

Используемые объекты компонентов могут быть реализованы а любом файле .ехе или .dll. При этом реализация объекта остается дня вас, как для пользователя объекта, совершенно прозрачной, благодаря предлагаемому СОМ сервису, называемому маршалингом (marshalling). Механизм маршалинга СОМ берет на себя всю сложность организации вызова функции между независимыми процессами и даже различными компьютерами, благодаря чему становится возможным использование 32-разрядных объектов в 16-разрядных приложениях или доступ к объекту, расположенному на компьютере А, из приложения, запущенного на компьютере Б. Такое межкомпьютерное взаимодействие называется распределенной СОМ (Distributed COM - DCOM). Более детальное описание такого механизма взаимодействия приводится ниже.

СОМ - ActiveX - OLE

Выше уже упоминалось, что СОМ - это API- и двоичный стандарты, которые служат основой для всех остальных "кирпичиков" этого семейства технологий. В 1995 году аббревиатура OLE была общим термином, использовавшимся для описания целого набора технологий, основанных на архитектуре СОМ. Тогда термин "OLE" использовался для обозначения только тех технологий, которые непосредственно имели дело со связыванием и внедрением, а именно: использование контейнеров и серверов, активизация по месту вставки или внедрения, технология "перетащить и опустить", слияние меню. В 1996 году Microsoft начинает маркетинговую кампанию no продвижению в язык разработчиков термина ActiveX. ActiveX становится всеобъемлющим термином, используемым для описания не OLE-технологий, основанных на использовании СОМ. Технология ActiveX включает автоматизацию (ранее называвшуюся OLЕ-автоматизацией), управляющие элементы, документы, контейнеры, сценарии и некоторые Internet-технологии. Поскольку появляется неразбериха, вызванная стремлением использовать термин '"ActiveX" для описания всех "семейных технологий", компания Microsoft называет любые отличные от OLE технологии, основанные на СОМ, просто - СОМ-ориентированные технологии (COM-based technologies).

Терминология

Экземпляр СОМ-объекта обычно называют просто объектом, а тип, который идентифицирует этот объект, компонентным классом (componens class. или coclass) Поэтому для создания экземпляра некоторого СОМ-объекта нужно предоставить идентификатор COM-класса (CLSID).

Часть данных, которая совместно используется несколькими приложениями, называется OLE-объектом (OLE object). Приложения, способные содержать OLE-объекты, называются OLE-контейнерами (OLE container), а приложения, способные содержать собственные данные в ОLE-контейнерах, называются OLE-серверами (OLE server).

Документ, который содержит один или более OLE-объектов, обычно называют составным документом (compound document). Хотя OLЕ-объекты могут содержаться внутри отдельных документов, полноценные приложения, с которыми можно работать в контексте другого документа, называют ActiveX-документами (ActiveX document).

Разработка приложений на основе СОМ

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

На заре существования Windows были внедрены разделяемые файлы, буфер обмена и технология динамического обмена данными (Dynamic Data Exchange, DDE).

Для обеспечения обмена данными и предоставления служб был разработан первый вариант технологии связывания и внедрения объектов (Object Linking and Embedding) — OLE 1. Она предназначалась для создания составных документов — того, к чему мы все уже давно привыкли. Эта технология была во многом несовершенной, и на смену ей пришла технология OLE 2. Она предоставляет способ решения более общей проблемы — как научить разные программы предоставлять друг другу собственные функции (службы) и как научить их правильно использовать эти функции.

Для решения этой проблемы помимо OLE был разработан целый ряд технологий. В основе этих разработок лежит базовая технология Component Object Model (COM) — Многокомпонентная Модель Объектов. Она описывает способ взаимодействия программ любого типа. Одна часть программного обеспечения предоставляет для использования собственные службы, а другая получает к ним доступ. При этом совершенно не важно, где расположены эти части — в одном процессе, в разных процессах на одном компьютере или на разных компьютерах.

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

Дополнительные возможности разработчикам распределенных приложений на основе СОМ дает модификация базовой технологии — распределенная модель COM (Distributed COM, DCOM).

В настоящее время СОМ используется в самых различных областях разработки программного обеспечения. На основе СОМ разработаны технологии Автоматизации (Automation), ActiveX, ActiveForm Microsoft Transaction Server. В составе Delphi работают две динамические библиотеки OLE32.DLL OLEAUT32.DLL, которые содержат базовые интерфейсы и общие функции СОМ.

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

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

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

Предположим, что объект СОМ встроен в электронную таблицу и обеспечивает доступ к математическим операциям. Будет логично разделить математические функции на группы по типам и создать для каждой группы собственный интерфейс. Например, можно выделить линейные, тригонометрические, агрегатные функции и т. д. На рис. 1 объект расположен внутри сервера — электронной таблицы. Интерфейсы обозначены маленькими кружками, связанными с объектом. Пусть интерфейс линейных функций называется ILinear, а интерфейс агрегатных функций — IAggregate.

Рисунок 1 – Сервер, объект и его интерфейсы

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

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

Рисунок 2 – Схема взаимодействия клиента и объекта СОМ

Взаимодействие между клиентом и объектом обеспечивается базовыми механизмами СОМ. При этом от клиента скрыто, где именно расположен объект: в адресном пространстве того же процесса, в другом процессе или на другом компьютере. Поэтому с точки зрения разработчика клиентского ПО использование функций электронной таблицы выглядит как обычное обращение к методу объекта. Механизм обеспечения взаимодействия между удаленными элементами СОМ называется маршалингом (marshalling). Возникает закономерный вопрос — как проходит создание и инициализация объекта СОМ при первом обращении клиента? Сомнительно, чтобы операционная система самостоятельно создавала экземпляры всех зарегистрированных в ней классов в надежде, что один из них понадобится. А ведь для работы объекта требуются еще и серверы. Представьте, что каждый раз при загрузке Windows настойчиво запускает Word, Excel, Internet Explorer и т. д. Любой объект СОМ является обычным экземпляром некоторого класса, описывающего его свойства и методы. Информация обо всех зарегистрированных и доступных в данной операционной системе классах СОМ собрана в специальной библиотеке СОМ, которая используется для запуска экземпляра класса — объекта.

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

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

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

Эта информация содержится в библиотеке типов, которая создается при помощи специального языка описания интерфейса (Interface Definition Language, IDL).

Объект

Центральным элементом СОМ является объект. Приложения, поддерживающие СОМ, имеют в своем составе один или несколько объектов СОМ. Каждый объект представляет собой экземпляр соответствующего класса и содержит один или несколько интерфейсов. Что же такое объект СОМ?

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

Любой объект является экземпляром некоторого класса, т. е. представляет собой переменную объектного типа. Поэтому объект обладает набором свойств и методов, которые работают с этими свойствами. К объектам применимы три основные характеристики: инкапсуляция, наследование и полиморфизм. Объекты СОМ всем этим требованиям удовлетворяют (существуют особенности наследования).

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

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

Некоторые языки программирования, например, Java, позволяют объекту иметь несколько интерфейсов.

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

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

Таким образом, объект СОМ с точки зрения ООП несомненно является объектом. Однако, как ключевой элемент технологии СОМ, он обладает рядом особенностей реализации базовых механизмов.

Интерфейс

Общие принципы использования интерфейсов

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

Для идентификации каждый интерфейс имеет два атрибута. Во-первых, это его имя, составленное из символов в соответствии с правилами используемого языка программирования. Каждое имя должно начинаться с символа "I". Это имя используется в программном коде. Во-вторых, это глобальный уникальный идентификатор (Globally Unique IDentifier, GUID), который представляет собой гарантированно уникальное сочетание символов, практически не повторяемое ни на одном компьютере в мире. Для интерфейсов такой идентификатор носит название IID (Interface Identifier). В общем случае клиент может не знать, какие интерфейсы имеются у объекта. Для получения их перечня используется базовый интерфейс IUnknown (см. ниже), который есть у любого объекта СОМ.

Затем клиенту необходимо знать, какие методы имеет выбранный им интерфейс. Для этого разработчик должен распространять описание методов интерфейсов вместе с объектом. Эту задачу помогает решать язык IDL (он также используется в библиотеках типов). Его синтаксис очень похож на C++.

Теперь осталось сделать самое важное — правильно вызвать сам метод. Для этого в СОМ описана реализация интерфейса на основе стандартного двоичного формата. Это обеспечивает независимость от языка программирования.

Доступный клиенту указатель интерфейса ссылается на внутренний указатель объекта и, через него, на специальную виртуальную таблицу (рис. 3).

Рисунок 3 – Формат интерфейса СОМ

Эта таблица содержит указатели на все методы интерфейса (похоже на организацию таблицы виртуальных методов объекта в ООП).

Первые три строки таблицы интерфейса всегда заняты под методы интерфейса IUnknown, так как любой интерфейс СОМ является его наследником этого интерфейса.

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

Интерфейс IUnknown

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

Метод QueryInterface возвращает указатель на интерфейс объекта, идентификатор IID которого передается в параметре метода. Если такого интерфейса объект не имеет, метод возвращает null.

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

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

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

При завершении работы с интерфейсом клиент обязан вызвать метод Release интерфейса IUnknown. Этот метод уменьшает счетчик ссылок на единицу. После обнуления счетчика объект уничтожает себя.

Сервер СОМ

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

Внутренний сервер (inprocess server) реализуется динамическими библиотеками, которые подключаются к клиенту и работают в одном адресном пространстве.

Локальный сервер (local server) создается отдельным процессом, который работает на одном компьютере с клиентом.

Удаленный сервер (remote server) создается процессом, который работает на другом компьютере по отношению к клиенту.

Рассмотрим локальный сервер. Получаемый клиентом указатель интерфейса в этом случае ссылается на специальный proxy-объект СОМ (назовем его заместителем), который функционирует внутри клиентского процесса. Заместитель предоставляет клиенту те же интерфейсы, что и вызываемый объект СОМ на локальном сервере. Получив вызов от клиента, заместитель упаковывает его параметры и при помощи служб операционной системы передает вызов в процесс сервера. В локальном сервере вызов передается еще одному специализированному объекту — заглушке (stub), который распаковывает вызов и передает его требуемому объекту СОМ. Результат вызова возвращается клиенту в обратном порядке.

Рассмотрим удаленный сервер. Он функционирует так же, как и локальный сервер. Однако передача вызовов между двумя компьютерами осуществляется средствами DCOM — с помощью механизма вызова удаленных процедур (Remote Procedure Call, RPC).

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

Библиотека СОМ

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

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

• идентификатор класса (Class Identifier, CLSID), который однозначно определяет класс объекта;

• тип сервера объекта — внутренний, локальный или удаленный;

• для локальных и внутренних серверов сохраняется полное имя динами­ческой библиотеки или исполняемого файла;

• для удаленных серверов записывается полный сетевой адрес.

Предположим, что клиент пытается использовать некоторый объект СОМ, который до этого момента не использовался. Следовательно, клиент не мо­жет получить указатели на объект и интерфейс. В этом случае он обращает­ся к библиотеке СОМ и вызывает метод coCreateinstance, передавая ей в качестве параметра CLSID нужного класса, IID интерфейса и требуемый тип сервера.

Библиотека при помощи диспетчера управления службами (Service Control Manager, SCM) обращается к системному реестру, по идентификатору клас­са находит информацию о сервере и запускает его. Сервер создает экземп­ляр класса — объект, и возвращает библиотеке указатель на запрошенный интерфейс.

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

Рисунок 4 – Создание первого экземпляра объекта с помощью библиотеки СОМ и системного реестра

Для неявной инициализации созданного объекта (установки значений свойств) может использоваться специальный объект — моникер. Или же клиент может инициализировать объект самостоятельно, применив специ­альные интерфейсы (iPersistFile, IPersistStorage, IPersistStream).

Фабрика класса

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

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

coCreateinstance — создает новый экземпляр класса. Все необходимые параметры, кроме iid, метод получает от фабрики класса. В этом его отличие от одноименного общего метода библиотеки

Lockserver — оставляет сервер функционировать после создания объекта

Ha самом деле общий метод CoCreateinstance при помощи переданного ему clsid осуществляет вызов соответствующей фабрики класса и метода CoCreateinstance интерфейса IClassFactory.

Для вызова фабрики класса существует специальный общий метод CoGetClassObject. В качестве параметра ему передается clsid нужного класса и iid интерфейса (IClassFactory). Метод ищет требуемую фабрику и возвращает указатель на интерфейс. С его помощью и используя метод CoCreateinstance, клиент заставляет фабрику класса создать объект.

Библиотека типов

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

Для создания библиотеки типов, описанной при помощи операторов IDL, используются специальные компиляторы. Доступ к библиотеке осуществляется по clsid класса объекта. Кроме того, библиотека имеет собственный GUID, который сохраняется в системном реестре при регистрации объекта. Каждая библиотека типов имеет интерфейс iTypeLib, который работает с ней, как с единым объектом. Для доступа к информации об отдельном интерфейсе используется интерфейс ITypeInfo.

Для доступа к библиотеке по GUID используется общий метод LoadRegTypeLib. Если клиенту известно имя файла библиотеки, то можно воспользоваться методом LoadTypeLib.

Объект СОМ в Delphi

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

Реализовать такое требование напрямую в рамках стандартных подходов ООП довольно затруднительно. И разработчики Delphi нашли следующий выход.

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

При создании объекта СОМ с ним связывается еще один класс, который описывает все интерфейсы. Этот класс носит общее название CoClass, а при создании реального объекта к его имени добавляется приставка со. CoClass объединяет всю информацию о типах, которая представлена в библиотеке типов. Объявление и описание CoClass содержится в библиотеке типов. Итак, стандартное объявление класса на Object Pascal обеспечивает создание кода объекта — именно оно компилируется в двоичный код. CoClass является надстройкой или оболочкой этого кода, он обеспечивает представление экземпляра объекта в соответствии со спецификацией СОМ и гарантирует, что обращение клиента к объекту будет обработано корректно. Класс TComObject в совокупности с создаваемым для каждого объекта экземпляром CoClass обладает всеми рассмотренными выше признаками объекта СОМ. Он может поддерживать произвольное число интерфейсов и обладает базовым интерфейсом IUnknown.

Для обеспечения работы объекта СОМ с библиотекой типов от базового класса TComObject порожден новый класс TTypedComobject. Дополнительно он имеет еще один интерфейс — IProvideClassInfo. Если этот интерфейс имеет доступ к библиотеке типов, то для получения полной информации об объекте достаточно знать его идентификатор класса. Этот класс используется для создания объектов с использованием библиотеки типов.