4.3.1.2. Элементы com-приложения

Разработчик стандартного COM-приложения в любом случае столкнется с двумя его элементами:

- сервер COM

- клиент COM.

Сервер COM представляет собой отдельный модуль, реализованный в виде самостоятельного исполняемого EXE-файла или файла динамической библиотеки DLL.

Моделью COM предусмотрены две разновидности сервера: внутренний и внешний.

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

В отличие от внутреннего сервера, внешний COM-сервер выполняется в своем собственном адресном пространстве. Допускается, чтобы внешний сервер порождался процессом, выполняющимся на другом компьютере. В этом случае вернее говорить не просто о COM, а о распределенной COM (Distributed COM, DCOM). При этом передача вызовов между двумя машинами осуществляется с помощью механизма удаленного вызова процедур RPC (Remote Procedure Call).

Рассмотрим классы VCL, поставленные на службу технологии COM.

В состав COM-сервера как минимум входят:

1. Один - единственный экземпляр класса TcomServer, инкапсулирующий сам COM-сервер. Доступ к этому объекту обеспечивает создаваемая при запуске сервера глобальная переменная ComServer.

2. Описание COM-объекта (или нескольких объектов), прототипом которого служит класс TComObject.

3. Фабрика класса (по одной на каждый тип COM-объекта). Основой фабрики класса служит класс TComObjectFactory. Единственная задача фабрики класса заключается в создании других объектов – экземпляров класса TComObject.

С выходом очередной версии библиотеки не надо обновлять все свое программное обеспечение.

В COM-модели процессом создания нового объекта ведает не среда программирования и даже не сам объект, а третья (в какой-то степени нейтральная) сторона – фабрика класса (class factories). Именно фабрика целиком и полностью отвечает за распределение памяти для будущего COM-объекта, и при этом, как бы это нам не показалось парадоксальным, о подробностях построения этого объекта не имеет ни малейшего представления.

Для каждого отдельного COM-класса предназначена отдельная фабрика.

Для создания нового экземпляра класса фабрика пользуется шаблоном класса, или фабричным образцом (factory pattern).

Фабричный образец - это особый класс, применяемый для создания экземпляра другого класса.

Благодаря «фабричному» подходу процесс создания нового объекта отделяется от особенностей его реализации.

Обслуживанием фабрик ведает менеджер фабрик - объект класса TComClass - Manager. Экземпляр менеджера создается автоматически и доступен в приложении COM - сервера благодаря глобальной переменной ComClassManager.

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

4.3.1.3. COM – объект

В основе многокомпонентной модели лежит понятие COM-объекта.

Физически COM-объект представляет собой совокупность данных и методов, управляющих этими данными. Структура COM-объекта существенно отличается от кнопок и строк ввода, привычных нам по библиотеке VCL. Ключевое отличие COM от знакомого нам объекта Delphi в том, каким образом COM-объект предоставляет доступ к своим данным.

Структура COM-объекта материализует идею сказки о Кощее Бессмертном. Помните: смерть в игле, игла в яйце, яйцо в утке, утка в зайце, заяц в сундуке, сундук на дубе... Неизвестно, читали в Microsoft русские народные сказки или нет, но проектируя COM-объект, программисты корпорации уверенно пошли по проторенному Кощеем пути - прямого доступа к данным COM- объекта извне в принципе не существует. Каждое поле объекта скрыто в его недрах и может обслуживаться только методами COM-объекта. Методы объекта также особой коммуникабельностью не отличаются; они упакованы так глубоко, что доступны лишь через свои указатели.

Рис. 6. Модель COM-объекта

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

Сколько у объекта таблиц, столько у него интерфейсов. В свете вышесказанного не стоит удивляться, что непосредственно к интерфейсу (указателю на виртуальную таблицу адресов методов) обратиться нельзя - вместо этого можно работать лишь с указателем на интерфейс; это единственное, что доступно извне COM-объекта. На рис. 6 представлена модель COM-объекта.

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

Рис. 7. Представление COM-объекта в виде схемы

В среде программирования Delphi в основу COM-объекта положен класс TCOMObject. Его интерфейсная часть создается на базе опорного для всех интерфейсных классов IInterface.