Технологии программирования СОМ

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

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

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

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

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

В настоящее время СОМ используется в самых различных областях разработки программного обеспечения. На основе СОМ разработаны технологии Автоматизации (Automation), Active X, Active Form Microsoft transaction Server.

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

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

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

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

Например, объект СОМ встроен в электронную таблицу и обеспечивает доступ к математическим операциям. Будет логично разделить математические функции на группы по типам и создать для каждой группы собственный интерфейс. Так, выделяются линейные, тригонометрические, агрегатные функции и т.д. (СЛАЙД 1).

Схема взаимодействия клиента с объектом СОМ приведена на (СЛАЙДЕ 2).

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

Чтобы получить доступ к агрегатной функции расчета среднего, клиент должен получить указатель на интерфейс IAggregate, а затем обратиться к этой функции.

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

Создание и инициализация объекта СОМ при первом обращении

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

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

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

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

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

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

Объект.

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

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

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

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

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

Интерфейс.

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

Для идентификации каждый интерфейс имеет два атрибута.

Во-первых, это его имя, составленное в соответствии с правилами используемого языка программирования. Каждое имя должно начинаться с символа «I». Это имя используется в программном коде.

Во-вторых, это глобальный уникальный идентификатор (GUID), который представляет собой гарантированно уникальное сочетание символов, практически не повторяемое ни на одном компьютере в мире. Для интерфейсов такой идентификатор носит название IID.

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

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

Для правильного вызова метода объекта СОМ используется реализация интерфейса на основе стандартного двоичного формата. Это обеспечивает независимость от языка программирования (СЛАЙД 3).

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

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

Интерфейс IUnkown.

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

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

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

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

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

Сервер.

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

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

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

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

Локальный сервер.

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

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

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

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

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

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

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

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

· Тип сервера – внутренний, локальный, удаленный;

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

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

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

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

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

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

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

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

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

· CoCreateInstance – создает новый экземпляр класса. Все необходимые параметры, кроме IID, метод получает от фабрики класса. В этом его отличие от одноименного общего метода библиотеки;

· LockServer – оставляет сервер функционировать после создания объекта.

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

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

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

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

Расширение COM-технологии посредством службы, обеспечивающей создание COM-объектов для совместного использования многими клиентами, авторизованный доступ к этим объектам, а при необходимости также обработку транзакций этими объектами. Расширенная таким образом технология COM стала именоваться COM+, а сам сервис, реализующий это расширение и являющийся составной частью Windows 2000, получил название Microsoft Component Services (службы компонентов).

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

Рассмотрим типичный сценарий работы приложения, использующего службы компонентов (MCS). Пользователь запускает клиентское приложение, реализованное в виде исполняемого файла или Web-приложения. Клиентское приложение пытается установить соединение с объектом COM+. Если компонент COM+, содержащий такой объект, реализован в виде внутрипроцессного сервера, этот объект может выполняться в адресном пространстве приложения dllhost.exe или в адресном пространстве клиентского приложения. (Если речь идет о Windows NT и Microsoft Transaction Server, то компонент, содержащий такой объект, обязательно должен быть реализован во внутрипроцессном сервере, а выполняется он в адресном пространстве приложения mtx.exe; объект MTS также может выполняться и в адресном пространстве клиентского приложения). В общем случае в объекте COM+ может быть реализована практически любая функциональность, например такой объект вполне может быть сервером доступа к данным.

Если запрос на установку соединения корректен, то в адресном пространстве того приложения, в котором должен функционировать объект, создается так называемый контекст объекта (если при этом приложение dllhost.exe не запущено, происходит его запуск). Контекст объекта содержит такие дополнительные сведения, которые не предусмотрены спецификацией COM и потому не содержатся в COM-объектах, — это правила доступа к объекту и способ участия его в транзакциях. Контекст создается для каждого клиента, обслуживает именно его (в отличие от, собственно, COM-объекта) и «по поручению» клиента взаимодействует с COM-объектом, который может быть и только что созданным, и взятым из имеющегося пула объектов.

После создания контекста клиентское приложение может посылать объекту COM+ запросы на выполнение его методов. Эти методы могут, например, выполнять запросы к СУБД или реализовывать какие-то иные действия, в том числе обращаться к другому объекту COM+ (в последнем случае мы можем говорить о «родительских» и «дочерних» объектах).

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

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

Требования к объектам COM+

Объекты COM+ являются серверами автоматизации и, как и другие подобные серверы, реализуют интерфейс IDispatch. Все объекты COM+ поддерживают специфический для них интерфейс IObjectControl, содержащий методы для активации и деактивации объекта COM+ и управления ресурсами, в том числе соединениями с базами данных.

Серверный объект COM+ должен иметь стандартную фабрику классов и библиотеку типов (и та и другая автоматически создаются при использовании эксперта Transactional Object wizard). Помимо этого компонент должен, как и все внутрипроцессные серверы автоматизации, экспортировать функцию DllRegisterServer и осуществлять автоматическую регистрацию его CLSID (эксперт Transactional Object wizard автоматически генерирует соответствующий код).

Если предполагается коллективное использование серверного объекта, он должен не хранить внутри себя сведения о состоянии данных, связанных с конкретным клиентом (например, результаты запросов, номера текущей записи в наборе данных и т.д.), а немедленно пересылать такие сведения клиентскому приложению. Объекты, удовлетворяющие этому требованию, обозначаются термином «не хранящие состояние» (stateless objects).

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

Особенности управления объектами COM+

Объекты COM+ объединяются в приложения COM+ — Applications (в MTS они назывались; «пакетами» — packages), каждый из которых может содержать один или несколько объектов. Управление объектами и приложениями COM+ осуществляется с помощью приложения Componet Services Explorer, которое доступно в разделе Administrative Tools панели управления Windows 2000.

Каждый объект, зарегистрированный как объект COM+, обладает свойством Transaction Support, определяющим правила участия объекта в транзакциях. Это свойство принимает пять возможных значений:

Disabled — для данного объекта не создается контекст транзакции;

Not Supported — службы Component Services не запускают компонент внутри контекста транзакции;

Supported — службы Component Services запускают компонент внутри контекста транзакции, если таковая запрошена, в противном случае — вне контекста;

Required — службы Component Services помещают объект в контекст транзакции при вызове любого из методов. Если для этого объекта транзакция недоступна, инициируется новая;

Requires new — службы Component Services инициирует новую транзакцию при создании объекта независимо от того, какие транзакции в этот момент выполняются.

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

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