Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

9.1.C0RBA 571

Клиентское приложение

Перехватчик

контроля

доступа

f Объект!

доступа

Перехватчик

{защищенных

обращений

Сейфовый

объект

Контекст

защиты

Локальная ОС

Обращение

Сейфовый объект

создает контекст

защиты

Реализация объекта

Объект!

доступа

Сейфовый

объект

Перехватчик

контроля

доступа

Контекст

защиты

Перехватчик

защищенных

обращений

Локальная ОС

Сеть

Рис. 9.16. Роль перехватчиков защиты в CORBA

Перехватчик защищенных обращений играет здесь основную роль, поскольку

он отвечает за организацию

коптексша защиты {security

context) клиента, кото-

рый собирается осуществлять защищенные обращения к нужному ему объекту.

Этот контекст защиты, представленный в виде объекта контекста защиты, содер-

жит всю необходимую информацию и методы, необходимые для защищенного

обращения к целевому объекту. Так, например, он определяет, какой при этом

обращении используется механизм, предоставляет методы шифрования и рас-

шифровки сообщений, хранит ссылки на сертификаты и т. д.

Сервер объекта также создает свои объекты контекста защиты. Перехватчик

клиента сначала обычно посылает серверу объекта сообщение, содержащее всю

необходимую для аутентификации клиента информацию, таким образом, застав-

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

перехватчик защищенных обращений сервера объекта проверяет правила объек-

та, чтобы проверить, все ли требования соблюдены. Ответ, возвращаемый клиен-

ту, может содержать дополнительную информацию, которая позволит клиенту

аутентифицировать сервер.

После этого исходного обмена сообщениями клиент выполняет привязку к

нужному объекту, и вместе они создают то, что обычно называется

ассоциацией

защиты (security

association).

После этого можно выполнять защищенные обра-

щения, и перехватчики защищенных обращений будут оберегать запросы и отве-

ты в соответствии с правилами, о которых договорились между собой клиент и

сервер объекта.

Критически важную роль в организации ассоциации защиты играет отдель-

ный объект со стандартизованным интерфейсом, именуемый

сейфовым объектом

(vault object). Сейфовый объект вызывается перехватчиком защищенных сооб-

щений для создания объекта контекста защиты. Перехватчик читает информа-

цию о правилах из ассоциированных с клиентом объектов правил и передает эту

информацию в сейфовый объект. Понятно, что сейфовый объект должен быть

реализован в виде части ORB, чтобы его невозможно было подделать, и относит-

ся к доверенной вычислительной базе каждой системы CORBA.

572 Глава 9. Распределенные системы объектов

9.2.

DCOM

Вторая распределенная система объектов, которую мы рассмотрим,

— это

распре-

деленная модель СОМ (Distributed

СОМ,

DCOM) корпорации Microsoft. Как мож-

но понять

PI3

ее названия, модель DCOM выросла из

модели компонентных

объек-

тов (Component

Object

Model,

COM). COM

—

это технология, лежащая в основе

различных версий операционных систем Windows от Microsoft, начиная с Win-

dows 95. В противоположность CORBA, DCOM не является результатом дея-

тельности комитета. Это, в частности, видно из того факта, что существует всего

лишь 300-страничное черновое описание СОМ, датированное октябрем 1995 года

[292].

К сожалению, то, что модель DCOM избежала обсуждения в комитете, по-

влекло за собой отсутствие хорошо спроектированной архитектуры с минималь-

ным набором базовых элементов, из которых строятся компоненты и службы.

Наоборот, в настоящее время DCOM

—

крайне запутанная система, в которой

множество сходных действий выполняются множеством разных способов, и по-

добное сосуществование различных решений временами кажется невозможным.

Критиковать модель DCOM нетрудно. Однако сравнивая ее с CORBA, мож-

но обоснованно утверждать, что DCOM

—

это технология, которая в значитель-

ной степени доказала свое право на существование. Десятки миллионов человек

каждый день используют Windows в сетевой среде, а значит, DCOM

—

широко

распространенная система. В этом смысле CORBA или любым другим распреде-

ленным системам до нее еще идти и рщти.

Далее мы рассмотрим наиболее важные части DCOM, следуя тому же поряд-

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

Чтобы понять, что такое DCOM, лучше всего обратиться к одной из книг для

программистов, такой как [357] или

[386].

Хорошее введение в различные техни-

ческие аспекты DCOM имеется в

[132].

Обзор DCOM с точки зрения распреде-

ленной модели Windows 2000 можно найти в [92].

9.2.1.

Обзор

Как уже упоминалось, модель DCOM базируется на модели СОМ. Целью созда-

ния СОМ была поддержка разработки компонентов, которые могли бы динамиче-

ски активизироваться и взаимодействовать друг с другом. Компонент в СОМ

—

это исполняемый код, содержащийся в динамически компонуемой библиотеке

(DLL) или исполняемой программе.

Сама по себе модель СОМ существует в виде библиотек, компонуемых с про-

цессом. Изначально она разрабатывалась для поддержки так называемых со-

ставных

документов

(compound

documents).

Как мы говорили в главе 3, состав-

ные документы

—

это документы, построенные из разнородных частей, таких как

текст (форматированный), изображения, электронные таблицы и т. п. Каждая из

этих частей может быть отредактирована при помощи ассоциированного с ней

приложения.

Для поддержки бесчисленного множества составных документов Microsoft

нужен был обобщенный метод для разделения отдельных частей и объединения

9.2.

DCOM

573

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

ния

объектов {Object Linking

and

Embedding,

OLE), Первая версия OLE использо-

вала для передачи информации между частями документа примитивный и не-

гибкий способ обмена сообщениями. Вскоре она была заменена следующей

версией, также называвшейся OLE, но построенной на базе более гибкого меха-

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

ActiveX

OLE

•

Документы

Внедрение

Группировка Г

(Элементы управления)

Связывание

Перенос данных

между процессами

1 Долговременная

память

Сценарии

Редактирование

на месте

Перетаскивание

Сохраненные

ссылки

Активизация

объектов

Библиотека ядра СОМ

СОМ

Рис. 9.17. Общая структура ActiveX, OLE и СОМ

На рисунке также показан элемент ActiveX

—

этим термином в настоящее

время называют все, что относится к OLE, плюс некоторые новшества, к кото-

рым относят гибкую (как правило) способность компонентов выполняться в

разных процессах, поддержку сценариев и более или менее стандартную группи-

ровку объектов в так называемые элементы управления ActiveX. Среди экспер-

тов по DCOM (даже внутри Microsoft) не существует согласия по вопросу о точ-

ном определении ActiveX, поэтому мы даже не будем пытаться дать подобное

определение.

Модель DCOM добавила к этой структуре весьма существенную вещь

—

спо-

собность процесса работать с компонентами, размещенными на другой маши-

не.

Однако базовый механизм обмена информацией между компонентами, прин-

ятый в DCOM, очень часто совпадает с соответствующими механизмами СОМ.

Другими словами, для программиста разница между СОМ и DCOM часто скры-

та за различными интерфейсами. Как мы увидим, DCOM в первую очередь пре-

доставляет прозрачность доступа. Другие виды прозрачности менее очевидны.

Объектная модель

Как фактически и все остальные распределенные системы объектов, DCOM со-

ответствует модели удаленных объектов. Фактически объекты в DCOM могут

размещаться как в одном процессе с клиентом, так и на одной машине с ним,

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

все эти варианты.

574 Глава 9. Распределенные системы объектов

Как и в CORBA, объектная модель в DCOM построена на реализации интер-

фейсов. Грубо говоря, объект DCOM — это просто реализация интерфейса.

Один объект может реализовывать одновременно несколько интерфейсов. Одна-

ко в отличие от CORBA в DCOM имеются только

бинарные интерфейсы

(binary

interfaces).

Такой интерфейс, в сущности, представляет собой таблицу с указате-

лями на реализации методов, которые являются частью интерфейса. Разумеется,

для определения интерфейса по-прежнему удобно использовать специальный

язык определения интерфейса (IDL). В DCOM также имеется такой язык под

названием MIDL (Microsoft IDL

—

язык IDL от

Microsoft),

при помощи которого

генерируются бинарные интерфейсы стандартного формата.

Достоинство бинарных интерфейсов состоит в том, что они не зависят от

языка программирования. В случае CORBA каждый раз для поддержки нового

языка программирования необходимо отображать описания IDL на конструкции

этого языка. Подобная стандартизация в случае бинарных интерфейсов не нуж-

на. Разницу между этими двумя подходами иллюстрирует рис. 9.18.

Бинарные интерфейсы

Спецификация

IDL

Указатель

на реализацию метода

Компиляция

с языка IDL

в интерфейс

Таблица

памяти

Компиляция

с языка IDL

в программу

на конкретном

языке

Объявления

классов Java

Объявления

классов

С++

Прототипы С

Стандартный

компилятор

языка

программирования

Код.

зависящий

от компилятора

Описания интерфейсов

для конкретного языка

программирования

Интерфейсы, определяемые для каждого конкретного языка

Рис. 9.18. Разница между интерфейсами, определяемыми для каждого конкретного языка,

и бинарными интерфейсами

Каждый интерфейс в DCOM имеет уникальный 128-битный идентификатор,

который называется

идентификатором интерфейса (Interface

Identifier,

IID), Каж-

дый I ID абсолютно уникален, не существует двух интерфейсов с одинаковым

9.2.

DCOM 575

идентификатором IID. Этот идентификатор создается путем комбинирования

большого случайного числа, локального времени и адреса сетевого интерфейса

текущего хоста. Вероятность того, что два сгенерированных индикатора совпа-

дут, практически равна нулю.

Объект DCOM создается как экземпляр класса. Чтобы создать такой объект,

необходимо иметь доступ к соответствующему классу. Для этой цели DCOM со-

держит

объекты

класса (class

objects).

Формально таким объектом может быть

все,

что поддерживает интерфейс IClassFactory. Этот интерфейс содержит метод

Createlnstance, который похож на оператор

new

в языках C++

Java. Вызов мето-

да Createlnstance для объекта класса приводит к созданию объекта DCOM, со-

держащего реализацию интерфейсов объекта класса.

Таким образом, объект класса представляет собой коллекцию объектов одного

типа, то есть реализующих один и тот же набор интерфейсов. Объекты, принад-

лежащие к одному классу, обычно различаются только в части текущего состоя-

ния. Путем создания экземпляров объекта класса становится возможным обра-

щение к методам этих интерфейсов. В DCOM на любой объект класса можно

сослаться по его глобальному уникальному

идентификатору

класса

(Class

Iden-

tifier, CLSID).

Все объекты реализуют стандартный объектный интерфейс lUnknown. Когда пу-

тем вызова Createlnstance создается новый объект, объект класса возвращает ука-

затель на этот интерфейс. Самый важный метод, содержащийся в lUnknown,

—

ме-

тод Querylnterface, который на основании IID возвращает указатель на другой

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

Важное отличие от объектной модели CORBA состоит в том, что все объекты

в DCOM нерезидентные. Другими словами, как только у объекта не остается

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

дится путем вызова методов AddRef и Release, входящих в интерфейс lUnknown. На-

личие исключительно нерезидентных объектов делает невозможным хранение

каждым из объектов своего глобально уникального идентификатора. По этой

причине объекты в DCOM могут вызываться только по указателям на интер-

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

другому процессу необходимо предпринять специальные меры.

DCOM также требует динамического обращения к объектам. Объекты, запро-

сы к которым могут создаваться динамически, во время выполнения, должны

иметь реализацию интерфейса IDispatch. Этот интерфейс подобен интерфейсу

динамического обращения (DII) в системе CORBA.

Библиотека типов и системный реестр

Эквивалент хранилища интерфейсов CORBA в DCOM называется

библиотекой

типов

(type

library).

Библиотека типов обычно ассоциируется с приложением или

другим крупным компонентом, содержащим различные объекты классов. Сама по

себе библиотека может храниться в отдельном файле или быть частью приложе-

ния. В любом случае библиотека типов в первую очередь требуется для точного

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

типов могут использоваться в системах программирования, например, для ото-

бражения структуры разрабатываемых интерфейсов на экране.

576 Глава

Распределенные системы объектов

Для того чтобы действительно активизировать объект, то есть гарантировать,

что он создан и помещен в процесс, из которого будет в состоянии принимать

обращения к методам, DCOM использует реестр Windows в комбинации со спе-

циальным процессом

— менеджером

управления

службами

{Service

Control

Ma-

nager,

SCM). Кроме всего прочего, реестр используется для записи отображения

идентификаторов классов (CLSID) на локальные имена файлов, содержащих

реализации классов. Чтобы создать объект, процесс сначала должен убедиться,

что соответствующий объект класса загружен.

Если объект выполняется на удаленном хосте, дело происходит иначе. В этом

случае клиент контактирует с менеджером управления службами этого хоста,

который представляет собой процесс, ответственный за активизацию объектов,

подобно хранилищу реализаций в CORBA. SCM этого удаленного хоста про-

сматривает свой локальный реестр в поисках файла, ассоциированного с CLSID,

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

шалинг указателя на интерфейс и возвращает его клиенту, который выполняет

демаршалинг указателя и передает его заместителю.

Общая архитектура DCOM, включая объекты классов, реальные объекты и

заместители, представлена на рис. 9.19

[105].

Процесс клиента получает доступ

к SCM и реестру, что помогает ему найти удаленный объект и выполнить при-

вязку к нему. Клиенту предлагается заместитель, реализующий интерфейсы это-

го объекта.

Клиентская машина

Сервер объекта

SCM

Приложение клиента

Маршалинг/

Демаршалинг!

Реестр

Заместитель!

клиента

СОМ

Локальная

ОС

(объект)

класса

Объект

Маршалинг/

Демаршалинг

Заглушка'

объекта

Локальная

ОС

СОМ

SCM

Реестр[

"Г"

Сеть

Microsoft RPC

Рис. 9.19. Общая архитектура DCOM

Сервер объектов содержит заглушку для маршалинга и демаршалинга обра-

щений, которые он будет передавать реальному объекту. Связь между клиентом

и сервером обычно реализуется путем вызовов RPC, но, как мы увидим чуть ни-

же,

в определенных случаях могут быть использованы и другие способы связи.

Службы DCOM

Модель DCOM можно рассматривать как расширенную за счет добавления

средств сообщения с удаленными объектами модель СОМ. Однако СОМ и сама

по себе стала иной, и новая ее версия называется СОМ+. Модель СОМ+ тоже

можно рассматривать как расширенный вариант модели СОМ, содержащий раз-

9.2.

DCOM

577

личные службы, которые ранее были полезными дополнениями к СОМ. Так,

частности, СОМ+ включает расширения, которые позволяют серверу успешно

поддерживать одновременно несколько объектов. Кроме того, добавлены служ-

бы,

реализуемые на внешних серверах, например системы очередей сообщений.

Провести черту между СОМ, DCOM, СОМ+ и внешними службами часто

бывает затруднительно, и подобные попытки лишь способствуют путанице. Да-

лее мы будем просто ссылаться на DCOM как на расширение, включающее и

СОМ, и СОМ+, и ActiveX. Там, где это возможно и имеет смысл, мы будем раз-

делять службы, просто помогающие DCOM, и компоненты, фактически являю-

щиеся частями DCOM. Чтобы понять, какие службы непосредственно входят в

DCOM, рассмотрим табл. 9.4, в которой перечислены службы CORBA и соответ-

ствующие им службы DCOM. Также в этой таблице приводятся службы Win-

dows 2000, обычно доступные клиентам модели DCOM, но не являющиеся ее

частями.

Таблица 9.4. Обзор служб CORBA, DCOM и Windows 2000

Служба CORBA

Служба DCOM/COM+ Служба Windows 2000

Служба коллекций

Служба запросов

Служба параллельного

доступа

Служба транзакций

Служба событий

Служба уведомлений

Служба внешних связей

Служба жизненного цикла

Служба лицензирования

Служба именования

Служба свойств

Служба обмена

Служба сохранности

Служба отношений

Служба защиты

Служба времени

Объекты данных ActiveX

Нет

Параллельные потоки

выполнения

Автоматические транзакции

СОМ+

События СОМ+

Утилиты маршалинга

Фабрики классов,

ЛТ-активизация

Специальные фабрики

классов

Моникеры

Специальное хранилище

Авторизация

Координатор распределенных

транзакций

Active Directory

Доступ к базам данных

SSL,

Kerberos

Ниже мы рассмотрим большую часть этих служб. Следует отметить, что сама

по себе модель DCOM, в отличие от CORBA, не является законченной распре-

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

очевидно, что служба именования является неотъемлемой частью распределен-

ной системы. Именование в Windows 2000 поддерживается при помощи службы

Active Directory. Эта служба, в сущности, состоит из набора серверов каталогов

578 Глава 9. Распределенные системы объектов

LDAP, которые именуются

просматриваются

при

помощи системы DNS.

Мы

говорили

о DNS и

LDAP

главе

Однако Active Directory

не

является частью

DCOM. Соответственно,

при

запуске приложений DCOM

среде UNIX

эти

приложения

не в

состоянии использовать

ту же

самую службу именования,

что

среде Windows 2000.

переносимости всегда есть некоторые границы.

Очевидно,

что

подобный подход препятствует межоперационной совмести-

мости.

другой стороны, учитывая,

что

фактически

все

приложения DCOM

рассчитаны

на

работу

среде Windows, непонятно, насколько этот недостаток

совместимости действительно можно считать проблемой.

9.2.2. Связь

Как

и в

CORBA,

базовом варианте DCOM поддерживает только синхронное

взаимодействие: клиент обращается

объекту

блокируется

до

получения отве-

та. Синхронные обращения такого рода поддерживаются

системе

по

умолча-

нию.

Однако,

как мы

увидим далее, DCOM обслуживает также

другие формы

взаимодействия.

Модели обращения

объектам

Как

мы

говорили, синхронные обращения являются стандартными

для

DCOM.

Если что-нибудь пойдет

не

так,

как

ожидалось

(а в

распределенных системах

это

обычное дело), клиент получает

код

ошибки. DCOM

не

может самостоятельно

повторить обращение

объекту, поскольку использует семантику «максимум

однажды».

Одно

из

самых ранних расширений «чистых» синхронных обращений

—

ин-

терфейсы обратного вызова. Интерфейсы обратного вызова поддерживаются

связующими

объектами (connectable

objects).

Это

специальные объекты DCOM,

которые могут содержать указатели

на

интерфейсы обратного вызова, реализуе-

мые клиентами. Связующрп! объект описывает интерфейс обратного вызова, реа-

лизацию которого

он

ожидает найти

на

стороне клиента. Когда клиент выполня-

ет привязку

связующему объекту,

он

должен предоставить

ему

указатель

на

интерфейс обратного вызова. Если связующий объект находится

на

удаленном

хосте,

для

передачи

ему

указателя

на

интерфейс сначала нужно выполнить

мар-

шалинг. Маршалинг указателей

на

интерфейсы

мы

рассмотрим чуть ниже.

После появления модели СОМ+

интеграции

ее в

систему Windows 2000

в DCOM появилась поддержка

других моделей обращения. Одно

из

таких рас-

ширений

—

возможность отмены затянувшегося синхронного вызова. Когда

по-

ток выполнения

начинает синхронное обращение, создается

объект

отмены

{cancel

object),

реализующий метод Cancel. Этот метод может быть вызван

из

дру-

гого потока выполнения

В с

передачей

качестве параметра идентификатора

по-

тока выполнения

А.

В результате поток выполнения

будет немедленно разбло-

кирован.

Также поддерживаются

асинхронные вызовы, соответствующие модели

оп-

роса CORBA

для

асинхронного обращения

методам.

На

самом деле, подход,

связанный

созданием интерфейсов, поддерживающих асинхронные вызовы.

9.2.

DCOM 579

имеет определенные отличия от модели опроса С ORB А. Взяв за отправную точ-

ку описание интерфейса на MIDL, компилятор MIDL для каждого метода т в

этом интерфейсе генерирует два других метода

—

Beg1n_m и Fin1sh_m. Первый из

них содержит только входные параметры метода

т,

а второй

—

только его выход-

ные параметры.

Клиент начинает взаимодействие с вызова метода Beg1n_/7Z, после чего немед-

ленно продолжает свою работу. Для объекта нет никакой разницы между син-

хронными и асинхронными вызовами, единственное, что он может увидеть,

—

это обращение к методу т. Результаты этого обращения пересылаются обратно

клиенту, где буферизуются до момента вызова клиентом метода F1n1sh_m.

Асинхронные вызовы в DCOM требуют, чтобы клиенты и объекты были ак-

тивны и работали. Другими словами, связь является нерезидентной. Сохранная

связь поддерживается с помощью очередей сообщений, о которых мы поговорим

чуть позже.

События

Изначально для реализации событий в DCOM использовались связующие объ-

екты, однако при этом требовалось, чтобы и клиент, и объект были активны. Од-

нако также имелась возможность соединения нескольких клиентов с одним свя-

зующим объектом, причем по их требованию объект мог выполнить обратный

вызов всех клиентов одновременно. В этом смысле можно сказать, что связую-

щие объекты предоставляют серверам простой способ раздачи событий несколь-

ким клиентам.

DCOM средствами СОМ+ поддерживает более сложную (и более практич-

ную) модель событий, известную под названием систем публикации/подписки

{publish/subscribe

systems). Мы будем ее обсуждать в главе 12. Основная идея

примерно та же, что и в модели продвижения сообщений CORBA. Событие мо-

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

тия группируются в класс событий {event class), который представляет собой

обычный объект класса DCOM со своим идентификатором CLSID. Нет никакой

необходимости реализовывать класс событий самостоятельно: в DCOM для него

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

поставщик событий может просто генерировать их вызовом соответствующих

методов этого объекта. Отметим, что само событие объектом не является.

Подписка на события также проста. Предположим, что событие представлено

методом m^event. Подписчик поддерживает реализацию этого метода. Для под-

писки на событие он передает указатель на интерфейс, реализующий этот метод,

в систему событий. Таким образом, когда поставщик вызывает m_event, систе-

ма событий отвечает за то, чтобы при этом произошли также обращения к вер-

сии m_event каждого подписчика. Рисунок 9.20 иллюстрирует принципы, лежа-

щие в основе механизма событий DCOM. Очевидно, этот подход действительно

похож на продвижение событий в системе CORBA.

События в DCOM можно сохранять. Благодаря такой возможности, даже ко-

гда подписчик в момент события неактивен, он все равно сможет, если пожелает,

получить событие позднее. Для этого система событий создает экземпляр класса

580 Глава 9. Распределенные системы объектов

событий поставщика

воспроизводит очередь событий, вызывая соответствую-

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

с этими событиями методы так, как если бы он имел дело

обычными резидент-

ными событиями.

Поставщик Потребитель

Интерфейс,^

содержащий

m event

Объект

класса

событий

Объект

события

Сохранение

обращения

|m_event

)

Потребитель

Хранилище

Объект,

.Обращение реализующий

передается

m_event

потребителю

Рис. 9.20. Обработка событий в DOOM

Передача сообщений

Кроме нерезидентной асинхронной связи DCOM также поддерживает

сохран-

ную асинхронную связь, используя

для

этого компоненты очередей {Queued

Components,

QC), QC

—

это на самом деле интерфейс

системе

очередей

сообще-

ний Microsoft {Microsoft Message Queuing, MSMQ), очень похожей

на

систему

MQSeries компании IBM, которую

мы

обсуждали

главе

Назначение

—

полностью скрыть MSMQ

и от

клиентов,

и от

объектов. Взамен

им

предостав-

ляются точно такие

же

обращения

методам,

как и

при асинхронных вызовах,

о которых мы уже говорили. Основная деятельность компонентов очередей про-

исходит следующим образом.

Асинхронные вызовы

случае

урезаются

до

интерфейсов, содержащих

методы, которые имеют только входные параметры. Методы, содержащие воз-

вращаемые значения или выходные параметры, недопустимы. Другими словами,

QC допускает только однонаправленное обращение

асинхронным методам, что

концептуально совпадает

подходом, принятым

асинхронных вызовах RPC.

Когда клиент выполняет привязку

объекту, поддерживающему QC, объект

возвращает указатель

на

интерфейс, содержащий методы, которые можно вызы-

вать асинхронно. Каждый раз, когда клиент обращается

одному

из

этих мето-

дов,

автоматически выполняется маршалинг

локальное сохранение обращения

в подсистеме

клиента. После того

как

клиент завершает обращение

мето-

дам

демонстрирует это, освобождая интерфейс вызовом метода Release, сохра-

ненные методы передаются объекту через MSMQ.

После прихода сообщений

обращениями

месту назначения подсистема QC

выполняет демаршалинг каждого обращения, после чего вызывает объект. Ника-