Файл: Технология COM (Предпосылки возникновения COM).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 29.03.2023

Просмотров: 90

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

COM является одновременно и спецификацией и реализацией[18]. Спецификация COM определяет правила создания объектов и их взаимодействия, способ связи между объектами. В соответствии со спецификацией объекты COM могут быть написаны на различных языках, выполняться в адресном пространстве различных процессов и на разнообразных платформах. До тех пор, пока объекты полностью соответствуют спецификации, они могут взаимодействовать. Это позволяет объединять унаследованный код как компонент с новыми компонентами, разработанными в любом из объектно-ориентированных языков.

COM как реализация представляет собой библиотеку (файлы OLE32.dll OLEAut32.dll), которая предоставляет ряд основных служб, поддерживающих описанные спецификации. Библиотека COM содержит набор стандартных интерфейсов, определяющих основную функциональность объектов COM, и небольшой набор функций API, разработанных для целей создания и управления объектами COM[19].

Интерфейсы объектов Delphi, как и язык Object Pascal, соответствуют COM спецификации. Реализация COM в Delphi называется DAX (Delphi ActiveX framework – базовая структура (каркас) элементов ActiveX Delphi)[20]. Основная часть реализации этой структуры находится в модуле AxCtrls.

Когда программист использует мастеров Delphi или объекты библиотеки VCL в своем приложении, он использует реализацию COM спецификаций. Кроме того, Delphi предоставляет ряд упаковщиков (wrapper) для таких служб COM, которые не реализуются непосредственно, например, активные документы (Active Documents). Эти упаковщики включены в модуль ComObj

Так как COM является развивающейся технологией, она может быть расширена за рамки базисных служб[21]. COM является основой для других технологий, таких как автоматизация (Automation – вместо прежнего термина OLE Automation), элементы ActiveX и активные документы (Active Documents).

Кроме того, в настоящее время возможно создание таких объектов COM, которые могут взаимодействовать с Microsoft Transaction Server (MTS). MTS – это система обработки транзакций, предназначенная для построения, развертывания и управления большими Intranet и Internet приложениями-серверами. Хотя MTS архитектурно и не является частью COM, она разработана для расширения возможностей COM в большой, распределенной среде.

Delphi снабжает программиста мастерами, облегчающими разработку приложений, которые объединяют упомянутые выше технологии – Automation, ActiveX, Active Documents и MTS.


2.1. Составляющие приложений COM

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

Таблица 1

Структурные элементы COM

Элемент

Назначение

COM Interface

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

COM server

Некоторый модуль (EXE, DLL или OCX), который содержит код для объекта COM

COM client

Программный код, который получает требуемые услуги от сервера через интерфейс(ы) объекта COM. Клиент знает, что он хочет получить от сервера, но не знает как его запрос выполняется внутри сервера. В большинстве случаев клиент реализуется как Automation controller (то же, что и ActiveX-клиент)

Type Library

Библиотека типов, которая содержит описание COM объекта, его интерфейсов и методов, а также их GUID идентификаторы. Информация из библиотеки записывается в системный реестр и используется клиентским приложением. Delphi предоставляет специальный редактор библиотеки типов, а содержимое библиотеки типов представляет в виде обычного модуля на языке Object Pascal

Class Factory

Фабрика классов, экземпляр объекта которой создает COM объект. Сам объект фабрики классов создается COM сервером при запросе клиентским приложением первого интерфейса

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

Рис. 1. Изображение интерфейса

Например, каждый COM объект имеет базовый интерфейс IUnknown, который сообщает, какие интерфейсы объекта доступны клиенту. Любой интерфейс сообщает клиенту, какие возможности он предоставляет[23].

Ключевыми аспектами интерфейсов объектов COM являются следующие:

  • будучи однажды опубликованным, интерфейс не должен изменяться ни при каких обстоятельствах. При необходимости расширение функциональности должно быть выполнено за счет добавления других интерфейсов[24];
  • по соглашению, имя интерфейса должен начинаться с заглавной буквы I, например, IMalloc или IPersist;
  • интерфейс имеет гарантированный уникальный идентификатор GUID (Globally Unique Identifier), который представляет собой 128-битное случайное число. Эти идентификаторы называют Interface Identifiers (IIDs). Использование таких идентификаторов ограничивает возможность конфликтов между разными версиями или продуктами[25];
  • интерфейсы обладают языковой независимостью. Для реализации интерфейса может быть использован любой язык программирования, который поддерживает указатели и структуры и позволяет вызвать функцию по указателю на нее[26];
  • сами по себе интерфейсы не являются объектами, а предоставляют способ получения доступ к объекту, а клиент получает доступ к данным объекта посредством вызова функций;
  • любой интерфейс является наследником базового интерфейса IUnknown;
  • обращения к интерфейсам могут перенаправляться между потоками, процессами и сетевыми компьютерами невидимо для клиента[27].
  • Базовый интерфейс IUnknown. Этот интерфейс, который должны поддерживать все COM объекты, включает следующие подпрограммы:
  • QueryInterface;
  • AddRef;
  • Release.

Метод QueryInterface, объявленный как

Function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;

возвращает клиенту указатель на запрошенный интерфейс IID. С помощью полученного указателя клиент может вызвать любой из реализованных методов интерфейса. В качестве IID клиент может указать тип класса интерфейс – в этом случае компилятор самостоятельно извлекает соответствующий GUID.

Методы AddRef и Release используются для того, чтобы объект COM мог самостоятельно отслеживать продолжительность своего существования[28]. Эти методы просто изменяют число ссылок на объект. Когда число ссылок на объект становится равным нулю, объект удаляется из памяти COM сервером.

Указатели на интерфейсы COM объекта.

Указатель на интерфейс является 32-битным указателем, который ссылается на указатель на таблицу vtable[29] (рис. 2.). Эта таблица является массивом указателей, каждый из которых, в свою очередь, указывает на реализацию метода. Таблица vtable является общей для всех экземпляров объекта, но для каждого из экземпляров создается свой набор данных.

Рис. 2. Указатели на интерфейсы COM объекта

COM серверы. Сервер COM является приложением или библиотекой, которая предоставляет сервис клиентскому приложению (или библиотеке)[30]. Сервер включает по крайней мере один объект COM, который в свою очередь представляет собой совокупность методов и свойств. Клиент не обязан знать, где в памяти располагаются объекты COM.

Когда клиент запрашивает сервис у объекта COM, он (клиент) должен передать идентификатор класса CLSID (class identifier)[31]. Идентификатор класса CLSID создается на основе GUID интерфейса объекта COM.

По идентификатору класса CLSID COM определяет соответствующий сервер, загружает его в память и сервер создает экземпляр объекта COM. Экземпляры объектов COM создает фабрика классов (class factory), к которой обращается сервер. Фабрика классов имеет свой интерфейс IClassFactory.

Фабрика классов и класс CoClass. COM объект является экземпляром класса CoClass, в котором реализованы один или более интерфейсов COM[32]. Объект COM обеспечивает те сервисы, которые определены в интерфейсах класса CoClass.

Экземпляры класса CoClass создаются специальным типом объекта, который называется фабрикой класса. Когда клиент обращается к COM объекту, фабрика класса создает экземпляр объекта и регистрирует экземпляр объекта для этого конкретного клиента. Если в это время другой клиент обращается к объекту, фабрика классов для него также создает (другой) экземпляр объекта.


Любой класс CoClass должен иметь фабрику классов и идентификатор класса CLSID, так что экземпляр COM объекта этого класса может быть создан извне, т.е. из другого модуля[33]. Благодаря наличию у классов CoClass уникального идентификатора CLSID, они могут быть обновлены в любое время, как только для класса разработан новый интерфейс. Новый интерфейс может использовать модифицированные или новые методы и это не оказывает никакого влияния на прежние версии. В случае использования обычных библиотек DLL подобная ситуация прежде была типичной проблемой[34].

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

2.2. Способы реализации СОМ серверов

При работе с объектами COM клиент не знает, где находится объект[35]. Он просто обращается к объекту посредством его интерфейса. Далее библиотека COM выполняет все необходимые шаги для удовлетворения вызова клиента.

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

Сервер в клиентском процессе (In-process server). Это библиотека DLL, которая выполняется в адресном пространстве процесса клиента[36]. Например, элемент ActiveX, внедренный в Web страницу, выполняется в Internet Explorer или другом браузере[37]. Это значит, что объект ActiveX загружается на машину клиента и выполняется в том же процессе, что и Web браузер. Клиент обращается к объекту COM путем прямого вызова интерфейса COM.

Рис. 4. Сервер в клиентском процессе

Локальный сервер (local server). Он представляет собой другое приложение (файл *.exe), которое выполняется в другом адресном пространстве, но на том же компьютере, что и клиентское приложение[38]. Например, обработка таблицы Excel, внедренной в документ Word, выполняется приложением Excel. Локальный сервер связывается с клиентом посредством COM библиотек.

Когда объект COM принадлежит другому процессу на том же компьютере, что и клиентское приложение, или вовсе на другом компьютере (в сети), COM использует так называемого "заместителя" (proxy) для того, чтобы инициировать удаленный вызов процедуры (remote procedure call – RPC)[39]. Так как заместитель находится в клиентском процессе, то с точки зрения клиента обращения к интерфейсам выглядят так же, как и для случая размещения сервера в клиентском процессе. Заместитель перехватывает вызовы клиента и отправляет их туда, где находится сервер. Механизм, который позволяет клиенту получить доступ к объекту, находящемуся в другом процессе или на другом компьютере (невидимо для клиента), называется маршалингом или маршализацией.


Рис. 6. Удаленный сервер

Удаленный сервер (remote server). Он представляет собой библиотеку (DLL или OCX) или другое приложение, которые выполняются на другом компьютере, а не на машине клиента[40]. Например, клиентское приложение, использующее базу данных, связывается с приложением, выполняемым на другом компьютере в сети. В этом случае удаленный сервер использует интерфейсы DCOM.

Различие между локальным и удаленным сервером состоит в применяемом способе (и инструментальных средствах) взаимодействия клиента и сервера: в первом случае используется COM, а во втором – DCOM[41].

Если сервер реализован как библиотека (а библиотека не может выполняться как самостоятельное приложение), то COM создает специальное приложение-суррогат (surrogate), в рамках которого и выполняется библиотека[42].

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

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

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

Необходимо отметить, что технология Microsoft Transaction Server (MTS) обеспечивает дополнительную поддержку для удаленных объектов[43].

2.3. Пример реализации и использования COM класса в С++

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

Описание класса IUnknown в файле Unknwn.h:

struct IUnknown

{

virtual HRESULT STDMETHODCALLTYPE QueryInterface(

/* [in] */ REFIID riid,

/* [iid_is][out] */ void __RPC_FAR *__RPC_FAR *ppvObject)=0 ;

virtual ULONG STDMETHODCALLTYPE AddRef( void) =0;

virtual ULONG STDMETHODCALLTYPE Release( void) =0;

};

Смысл использованных макросов:

HRESULT – long;

STDMETHODCALLTYPE – _stdcall