void Disconnect(void);
// called when ORPC request arrives
// вызывается, когда поступает запрос ORPC
HRESULT Invoke ([in] RPCOLEMESSAGE *pmsg,
[in] IRpcChannelBuffer *pChannel);
// used to support multiple itf types per stub
// используется для поддержки нескольких типов интерфейсов
// для одной заглушки
IRpcStubBuffer *IsIIDSupported([in] REFIID riid);
// used to support multiple itf types per stub
// используется для поддержки нескольких интерфейсов
// для одной заглушки
ULONG CountRefs(vold);
// used by ORPC debugger to find pointer to object
// используется отладчиком ORPC для поиска указателя на объект
HRESULT DebugServerQueryInterface(void **ppv);
// used by ORPC debugger to release pointer to object
// используется отладчиком ORPC для освобождения указателя на объект
void DebugServerRelease(void *pv);
}
Метод Invoke будет вызываться библиотекой СОМ, когда поступит запрос ORPC на объект. При вводе маршалированные [in]-параметры будут находиться в RPCOLEMESSAGE, а при выводе заглушка должна маршалировать HRESULT метода и любые [out]-параметры, которые будут возвращены в блоке ответов ORPC.
Интерфейсный заместитель должен выставлять интерфейс (интерфейсы), за удаленный доступ к которым он отвечает, в дополнение к интерфейсу IRpcProxyBuffer:
[ uuid(D5F56A34-593B-101A-B569-08002B2DBF7A), local, object ]
interface IRpcProxyBuffer : IUnknown {
HRESULT Connect([in] IRpcChannelBuffer *pChannelBuffer);
void Disconnect(void);
}
Интерфейс IRpcPгoxуBuffer должен быть неделегирующим интерфейсом IUnknown интерфейсного заместителя. Все остальные интерфейсы, которые выставляет интерфейсный заместитель, должны делегировать администратору заместителей свои методы IUnknown. Именно в реализациях метода этих других интерфейсов интерфейсный заместитель должен использовать канал для посылки запросов ORPC на метод интерфейсной заглушки Invoke, который затем обрабатывает этот метод в апартаменте объекта.
Интерфейсные заместители и интерфейсные заглушки динамически связываются и совместно используют единый CLSID как для заместителя, так и для заглушки. Такую раздвоенную реализацию часто называют интерфейсным маршалером (interface marshaler). Объект класса интерфейсного маршалера выставляет интерфейс IPSFactoryBuffer:
[ uuid(D5F569DO-593B-101A-B569-08002B2DBF7A), local, object ]
interface IPSFactoryBuffer : IUnknown {
HRESULT CreateProxy(
[in] IUnknown *pUnkOuter,
// ptr to proxy manager
// указатель на администратор заместителей
[in] REFIID riid,
// the requested itf to remote
// запрошенный интерфейс для удаленного доступа
[out] IRpcProxyBuffer **ppProxy,
// ptr. to proxy itf.
// указатель на интерфейс заместителя
[out] void **ppv
// ptr to remoting interface
// указатель на удаленный интерфейс
);
HRESULT CreateStub(
[in] REFIID riid,
// the requested itf to remote
// запрошенный интерфейс для удаленного доступа
[in] IUnknown *pUnkServer,
// ptr to actual object
// указатель на действующий объект
[out] IRpcStubBuffer **ppStub
// ptr to stub on output
// указатель на заглушку на выходе
);
}
Администратор заместителей вызывает метод CreateProxy с целью агрегирования нового интерфейсного заместителя. Администратор заглушек вызывает метод CreateStub с целью создания новой интерфейсной заглушки.
Когда в объекте запрашивается новый интерфейс, то администраторы заместителей и заглушек должны преобразовать запрошенные IID и CLSID интерфейсного маршалера. Под Windows NT 5.0 хранилише класса совершает эти преобразования в директории NT, и они кэшируются в локальном реестре каждой хост-машины. Отображения IID в CLSID всей машины кэшируются в
HKEY_CLASSES_ROOT\Interface
а отображения каждого пользователя кэшируются в
HKEY_CURRENT_USER\Software\Classes\Interface
Один из этих ключей или оба будут содержать подключи для каждого известного интерфейса. Под Windows NT 4.0 и в более ранних версиях не существует хранилища классов и используется только область локального реестра HKEY_CLASSES_ROOT\Interface.
Если в интерфейсе установлен интерфейсный маршалер, то в реестре будет дополнительный подключ (ProxyStubClsid32). который показывает CLSID интерфейсного маршалера. Ниже показаны необходимые ключи реестра для интерфейсного маршалера:
[HKCR\Interface\{1A3A29F0-D87E-11d0-8C4F-0080C73925BA}]
@="IRacer"
[HKCR\Interface\{1A3A29F0-D87E-11d0-8C4F-OB80C73925BA}\ProxyStubClsid32]
@="{1A3A29F3-D87E-lld0-8C4F-0080C73925BA}"
Эти элементы реестра означают, что существует внутрипроцессный сервер с CLSID, равным {1A3A29F3-D87E-11d0-8C4F-0080C73925BA}, который реализует интерфейсные заместитель и заглушку для интерфейса IRacer ({1A3A29F0-D87E-11d0-8C4F-0080C73925BA}). Из этого следует, что HKCR\CLSID будет иметь подключ для интерфейсного маршалера, отображающего CLSID в соответствующее имя файла DLL. Опять же под Windows NT 5.0 это отображение может содержаться в хранилище классов, которое способно динамически заполнять локальный реестр. Поскольку интерфейсный маршалер должен выполняться в том же апартаменте, что и администратор заместителей или администратор заглушек, они должны использовать (флаг) ThreadingModel="Both" для гарантии того, что они всегда могут загрузиться в нужный апартамент.
Реализация интерфейсных маршалеров
В предыдущем разделе было показано четыре интерфейса, используемых архитектурой стандартного маршалинга. Хотя и допустимо реализовать интерфейсные маршалеры с помощью ручного кодирования на C++, на практике это осуществляется редко. Дело в том, что компилятор IDL может автоматически генерировать исходный С-код для интерфейсного маршалера на основе IDL-определения интерфейса. Созданные MIDL интерфейсные маршалеры преобразуют параметры метода в последовательную форму, используя протокол Сетевого Представления Данных (Network Data Representation – NDR), который допускает демаршалинг этих параметров при различных архитектурах хост-машин. NDR учитывает различия в порядке следования байтов, в формате с плавающей точкой, в наборе символов и в расположении результатов. NDR поддерживает фактически все совместимые с C типы данных. Для того чтобы обеспечить передачу интерфейсных указателей как параметров, MIDL генерирует вызовы CoMarshalInterface / CoUnmarshalInterface для маршалинга любых параметров интерфейсных указателей. Если параметр является статически типизированным интерфейсным указателем:
HRESULT Method([out] IRacer **ppRacer);
то сгенерированный код маршалера будет маршалировать параметр ppRacer путем передачи IID IRacer (IID_IRacer) вызовам CoMarshalInterface / CoUnmarshalInterface . Если же интерфейсный указатель типизирован динамически:
HRESULT Method([in] REFIID riid, [out, iid_is(riid)] void **ppv);
то сгенерированный код маршалера будет маршалировать интерфейс, используя IID, переданный динамически в первый параметр метода.
MIDL генерирует исходный код интерфейсного маршалера для каждого нелокального интерфейса, определенного вне области действия оператора library . В следующем псевдо-IDL коде
// sports.idl
// виды спорта. Язык описания интерфейсов
[local, object] interface IBoxer : IUnknown { … }
[object] interface IRacer : IUnknown { … }
[object] interface ISwimmer : IUnknown { … }
[helpstring(«Sports Lib»)]
library SportsLibrary {