5.6.2 Составляющие com-приложений

В общем случае, при создании СОМ-приложения необходимо обеспечить наличие трех составляющих:

- СОМ-интерфейс;

- СОМ-сервер;

- СОМ-клиент.

Краткая информация о СОМ-интерфейсах приведена выше в п. 5.6.1. За более подробной информацией следует обратиться к [11], а также к соответствующей литературе и документации.

К ак отмечалось выше, один или несколько СОМ-объектов, помещаются в программный контейнер, называемый СОМ-сервером. Это могут быть как независимые выполняемые приложения (EXE-), так и библиотеки (DLL). СОМ-клиентами называются приложения, которые могут запрашивать интерфейсы объектов, чтобы определить те услуги, которые может предоставить СОМ-объект. При этом, приложение обращается к сервисам объекта (независимо от того, где последний расположен), вызывая методы некоторого интерфейса. На рис 5.3 представлены возможные способы доступа СОМ-клиента (Приложение 1) к сервисам других приложений (СОМ-серверов) при использовании COM-технологии.

5.6.2.1 Способы взаимодействия com-клиентов с com-серверами

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

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

Рассмотрим подробнее виды процесса взаимодействия COM-клиентов с COM-серверами. Каждый сервер, как правило, может поддерживать несколько объектов одного класса или даже несколько различных классов, каждый из которых может иметь (а может и не иметь) свой CLSID. Как видно из рис. 5.3, в зависимости от места выполнения сервера, возможны три типа серверов автоматизации:

1) Сервер автоматизации может выполняться в адресном пространстве клиента. В этом случае он называется внутренним (in-process) сервером и реализуется в виде библиотеки (DLL). Этот случай показан на рис 5.4. На рис 5.3 он соответствует процессу взаимодействия клиента (Приложение 1) с библиотечным COM-объектом;

2) Помимо этого, сервер автоматизации может выполняться в собственном адресном пространстве, отличном от адресного пространства контроллера. В этом случае он называется локальным (out-of-process) сервером и реализуется в виде EXE-файла. Этот случай показан на рис. 5.5. На рис 5.3 он соответствует процессу взаимодействия клиента (Приложение 1) с COM-сервером (Приложение 2);

3) Если же сервер автоматизации выполняется на компьютере, отличном от компьютера, на котором выполняется контроллер, он называется удаленным (remote) сервером (рис. 5.6). Такой сервер может быть реализован как в виде EXE-файла, так и в виде DLL. Многие локальные серверы автоматизации могут быть запущены как удаленные. Они могут быть реализованы как отдельный процесс или динамически подключаемая библиотека на удаленной машине (так называемый, суррогатный процесс). Возможность создания таких серверов обеспечивается технологиями DCOM и старше (COM+, .net). Стандарт DCOM позволяет заменить обращение к объекту на Remote Procedure Call (RPC) – вызовы удаленных процедур. На рис 5.3 удаленный сервер соответствует процессу взаимодействия клиента (Приложение 1) с COM-сервером (УДАЛЕННОЕ Приложение);

С точки зрения клиента все три сервера выглядят одинаково - как серверы "в процессе" (in-process). Это объясняется тем, что в случае локального или удаленного сервера, СОМ создает внутри процесса-клиента специальный объект-заместитель – Object Proxy (внутрипроцессный прокси) представляющий клиенту интерфейс объекта на локальном или удаленном сервере. Object Proxy связывается с другим объектом-заглушкой (Stub) через RPC. При передаче информации Object Proxy производит ее упаковку, а Stub – распаковывает ее, преобразуя в стандартный формат, понятный взаимодействующему процессу. Процесс упаковки информации называется маршалингом (marshaling) или выстаивание, а процесс распаковки - демаршалингом (demarshaling). Необходимость стандартного формата обусловлена тем, что разные процессы, выполняемые на одной машине, могут быть реализованы на разных языках программирования, и иметь разный формат представления одной и той же информации, например, вещественных чисел и т. п. Еще более существенны различия в случае обмена данными между ЭВМ с различными платформами.

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

Загрузка СОМ-сервера зависит от его типа - внутренний ли это сервер (DLL) или внешний (приложение).

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

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