Указанные выше моникеры типов queue и new являются встроенными, т. е. мы можем использовать их не заботясь о их реализации. Моникер освобождает клиента от участия в процессе активации объекта. Этот процесс зависит от типа объекта, и без использования моникеров клиент должен входить во все детали (например, как активировать объект, состояние которого хранится в заданном файле). Каждый моникер реализует интерфейс IMoniker, скрывающий за стандартным фасадом все детали конкретного алгоритма активации.

Функция CoGetObject в нашем случае делает следующее:

1. Создает контекст связывания.

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

2. Создает моникер по его строке инициализации (текстовое представление моникера, display name).

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

Вызывается функция MkParseDispiayName, которая получает на входе

— Указатель на контекст связывания (полученный в предыдущем пункте)

— Строку инициализации формируемого моникера

Выходными параметрами являются

— Длина начальной части строки инициализации, распознанная данной функцией

— Указатель на построенный моникер

В нашем случае строкой инициализации моникера является строка "queue: /new: Mу_Арр. My_Class". Слева от первого разделителя "стоит префикс — тип моникера (в нашем случае queue), который должен быть зарегистрирован как ProgID в реестре. Справа от этого разделителя стоит специфичное для данного типа моникера строка, которая хранит некоторую информацию об объекте, с которым должен быть связан этот моникер. В нашем случае эта строка является строкой инициализации еще одного моникера, тип которого new. Таким образом, в данном случае мы имеем композицию двух моникеров.

Алгоритм работы функции MkParseDispiayName:

5. Сканируется строка инициализации моникера и выделяется ее префикс — queue.

6. В реестре для ProgID queue ищется путь к реализации соответствующего класса моникера типа queue. Либо объект этого класса, либо его экземпляр реализует интерфейс IParseDisplayName.

7. В функцию IParseDisplayName::ParseDisplayName (с такими же параметрами, как и у функции MkParseDispiayName) передается еще не обработанный остаток строки инициализации — "new: Му_Арр. Му_Сlass".

8. Функция IParseDisplayName:: ParseDisplayName сканирует эту строку и выделяет тип нового моникера new и строку, описывающую объект, с которым должен связываться моникер типа new — "Mу_Арр. My_ciass". Ну и, конечно, формируется моникер типа queue.

9. В реестре для ProgID new ищется путь к реализации соответствующего класса моникера типа new. Либо объект этого класса, либо его экземпляр реализует интерфейс IParseDisplayName.

10. В функцию IParseDisplayName::ParseDisplayName передается еще не обработанный остаток строки инициализации — "Mу_Арр. My_ciass", который уже не содержит префикса - типа еще одного моникера. Формируется моникер типа new, который должен будет связываться с СОМ объектом с ProgID My_App.My_ciass.

11. В результате вызова функции CreateGenericComposite формируется моникер, являющийся композицией двух построенных выше моникеров типов queue и new. Указатель на этот моникер возвращается как результат работы функции MkParseDispiayName. Возвращается и число обработанных символов в строке инициализации (все символы обработаны).

3. Выполняет связывание построенного в предыдущем пункте моникера — композиции моникеров queue и new с СОМ объектом.

Для композиции моникеров вызывается функция IMoniker::BindToObject. Входными параметрами этой функции являются:

— Указатель на контекст связывания

— Указатель на моникер, стоящий в композиции слева от данного (в нашем случае такого нет)

— GUID запрашиваемого интерфейса объекта, с которым выполняется связывание.

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

Алгоритм работы функции IMoniker::BindToObject в случае композиции моникеров queue и new:

3. Вызывается функция IMoniker::BindToObject для ранее построенного (ссылка хранится в контексте связывания) моникера new.

При вызове задается ненулевой указатель на моникер, стоящий в композиции слева — моникер queue.

Если бы этот указатель был нулевым, то вызов функции IMoniker::BindToObject для МОНИКера new привел бы К построению нового экземпляра класса с ProgID Mу_Арр. Mу_сlass" (этот класс обязательно должен иметь фабрику класса С реализованным интерфейсом IClassFactory).

В нашем случае вызов функции IMoniker::BindToObject для моникера new сводится к преобразованию ProgID Mу_Арр. Mу_Class" в соответствующий CLSID, который передается МОНИКеру queue.

4. Вызывается функция IMoniker::BindToObject для ранее построенного (ссылка хранится в контексте связывания) моникера queue.

Моникер queue всегда используется в композиции со стоящим справа от него моникером типа new. Получив от последнего CLSID асинхронного компонента с ProgID "My_App.My_ciass", моникер queue формирует на стороне клиента прокси особого вида — Recorder, о котором речь пойдет в следующем пункте и который и обеспечивает асинхронность работы клиента и асинхронного компонента. Указатель на Recoder возвращается клиенту как указатель на запрошенный интерфейс асинхронного компонента.

Здесь надо еще упомянуть о параметрах, которые можно передавать моникеру типа queue. При обсуждении технологии MSMQ уже приводился некоторый (неполный) список свойств, которые можно приписывать передаваемому сообщению. Выбор значений этих свойств определяет время жизни сообщения до момента получения, необходимость аутентификации на отправителя на стороне получателя, использованные алгоритмы хеширования и шифрования, имя очереди назначения и т. п. Ясно, что упомянутый выше Recoder должен формироваться с учетом этих требований. Собственно, именно Recoder и будет формировать сообщения на стороне клиента. В связи с этим, уже при вызове функции coGetobject нужно иметь возможность задавать свойства отправляемых сообщений (в противном случае, они будут определены по умолчанию). Эти свойства можно указать в строке инициализации композитного моникера между "queue: " и "/" и в виде списка пар свойство = значение.

• Recorder

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

Только после того, как все вызовы данного интерфейса со стороны клиента выполнены (клиент освобождает ссылку на интерфейс асинхронного компонента и подтверждает завершение транзакции), во время своей деактивации Recoder отправляет (через MSMQ) построенное сообщение в очередь назначения принимающего приложения. Именно это приложение содержит данный асинхронный компонент, а имя этой очереди совпадает с именем данного приложения.

Выше уже обсуждались вопросы безопасности в MSMQ. В случае асинхронных компонент все проще. Как правило, Recoder выполняется в процессе клиента и имеет одинаковый с клиентом SID. SID клиента записывается Recorder в сообщение.