Можно выделить 4 основные фазы создания объекта COM.

1. Клиент вызывает функцию библиотеки COM CoCreatelnstance.

2. Библиотека СОМ находит в системном реестре запись, соответствующую классу данного объекта.

3. Библиотека COM запускает сервер COM и возвращает клиенту указатель на требуемый интерфейс.

4. Клиент вызывает требуемый метод.

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

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

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

Создание нескольких объектов одного класса; фабрики классов.Если нужно создать только один объект, то проще всего создать его с помощью CoCreatelnstance.

В случае, если требуется создать много экземпляров объектов одного и того же класса, то можно использовать фабрику класса (class factory) — объекту, способному создавать другие объекты. Каждая фабрика класса предназначена для создания объекта одного конкретного класса.

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

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

Чтобы COM объект являлся фабрикой класса, объект должен поддерживать интерфейс IClassFactory, который содержит два метода: CoCreatelnstance и LockServer.

Метод CoCreatelnstance создает новый экземпляр класса, объекты которого может создавать данная фабрика. Клиент не передает этому методу в качестве параметра CLSID, так как класс объекта неявно определяется самой фабрикой. И все же клиент задает IID, чтобы получить указатель на нужный ему интерфейс.

LockServer позволяет клиенту сохранить сервер загруженным в память. Объект-фабрика, как и другие объекты, поддерживает собственный счетчик ссылок, для учета количества использующих его клиентов. Однако по раз­ным (очень сложным) соображениям этого счетчика недо­статочно, чтобы удерживать сервер загруженным в память. Чтобы сервер гарантированно продолжал работать, можно использовать IClassFactory::LockServer.

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

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

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

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

В рамках СОМ в качестве базовых механизмов повторного применения выступают включение (containment), и агрегирование (aggregation), основе которых лежит некоторая взаимосвязь объектов. В терминологии СОМ "внешним" (outer) называется объект, использующий сервисы "внутреннего" (inner). Внешним объектом выступает клиент внутреннего, либо их взаимосвязь может быть несколько более тесной.

Основная идея включения состоит в том, что внешний объект использует внутренний объект в качестве сервера (рис. 4.6), при этом к методам внутреннего объекта обращаться может только внешний объект.

Рис. 4.6. Использование внешним объектом внутреннего объект в качестве сервера

Основная идея включения состоит в том, что внешний объект использует внутренний объект в качестве сервера (рис. 4.6), при этом к методам внутреннего объекта обращаться может только внешний объект.

Благодаря своей простоте, включение является широко распространенным механизмом повторного применения в СОМ.

Рис. 4.7. Добавление методов внутреннего объекта к методам внешнего объекта

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

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

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

Механизм, с помощью которого объекты сохраняют и загружают свои перманентные данные, иногда называют сервисом перманентности (persistent service).

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

СОМ-объекты предоставляют два разных наборов интерфейсов для поддержки перманентности. Первый предоставляет СОМ-объектам возможность работы со структурированным хранилищем (Structured Storage). Второй набор стандартных интерфейсов позволяет клиенту управлять перманентностью COM-объекта. COM-объект может поддерживать один или несколько таких интерфейсов, объединенных под общим названием интерфейсы IPersist*.

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

Рис. 4.8. Обобщенная структура хранилища

Структурированное хранилище используется для хранения перманентных данных нескольких компонентов в общем файле.

Обобщенная структура хранилища показана на рис. 4.8.

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

Хранилища и потоки рассматриваются как СОМ-объекты, и доступ к каждому из них осуществляется через соответству­ющий интерфейс. Хранилища поддерживают интерфейс IStorage, а потоки — интерфейс IStream.

Моникеры.При работе с компонентами крайне полезно иметь способ идентификации конкретного экземпляра объекта.

В общем случае для обращения к конкретному экземпляру компонента необходимо указать два элемента: методов объекта и его перманентных данных. Для объектов, не имеющих перманентных данных, достаточно указать методы. Но для большинства объектов необходимо и то и другое.

Сам по себе СОМ не предлагает способа именования экемпляра объекта.

Клиент может создать абстрактный экземпляр компонента, вызвав CoCreatelnstance и передав ей сответствующий CLSID. Если у компонента имеются перманентные данные, то клиент может использовать, например, один из интерфейсов IPersist*.

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

Моникер (moniker) — жаргонный эквивалент слова nickname (уменьшительное имя, прозвище).

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

Каждый моникер идентифицирует только один экземпляр объекта.

Типичный запрос, осуществляемый клиентом через моникер, будет выглядить следующим образом: "Создать и инициализировать объект, на который ссылается данный моникер."

Моникер создает и инициализирует объект, возвращает указатель на заданный клиентом интерфейс вновь запущенного объекта и затем (как правило) умирает в результате того, что клиент уменьшает его счетчик ссылок до 0.

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

Противоположный процесс называется демаршалингом (также называемый десериализацией).

Маршалинг задействуется при использовании различных механизмов RPC, где есть необходимость в передаче данных между процессами и потоками. Переход от неуправляемого типа в тип CLR, как, например, в процессах P/Invoke, используемых в платформе .NET Framework, является подходящим примером, демонстрирующим применение маршалинга.

Кроме того, маршалинг широко используется в скриптах и приложениях, применяющих технологии XPCOM, поставляемой в составе Mozilla application framework. Браузер Mozilla Firefox — одно из самых известных приложений, созданных с применением этой платформы, что позволило скриптовым языкам использовать технологию XPCOM через Cross-Platform Connect (XPConnect).

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

IDL, или язык описания интерфейсов (англ. Interface Description Language или Interface Definition Language) — язык спецификаций для описания интерфейсов, синтаксически похожий на описание классов в языке C++.

Реализации

CORBA IDL — язык описания интерфейсов распределённых объектов, разработанный рабочей группой OMG. Создан в рамках обобщённой архитектуры CORBA.

IDL DCE, язык описания интерфейсов спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group).

MIDL (Microsoft Interface Definition Language) — язык описания интерфейсов для платформы Win32 определяет интерфейс между клиентом и сервером. Предложенная от Microsoft технология использует реестр Windows и используется для создания файлов и файлов конфигурации приложений (ACF), необходимых для дистанционного вызова процедуры интерфейсов (RPC) и COM/DCOM интерфейсов.

COM IDL — язык описания интерфейсов между модулями COM. Является преемником языка IDL в технологии DCE (англ. среда распределённых вычислений) — спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group).

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

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

Механизм, с помощью которого объекты сохраняют и загружают свои перманентные данные, иногда называют сервисом перманентности (persistent service).

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

СОМ-объекты предоставляют два разных наборов интерфейсов для поддержки перманентности. Первый предоставляет СОМ-объектам возможность работы со структурированным хранилищем (Structured Storage). Второй набор стандартных интерфейсов позволяет клиенту управлять перманентностью COM-объекта. COM-объект может поддерживать один или несколько таких интерфейсов, объединенных под общим названием интерфейсы IPersist*.