Маршалинг и взаимодействие клиента с сервером

Дуальные интерфейсы

Диспинтерфейс

Диспинтерфейс (dispinterface) — это декларация методов, доступных через интерфейс IDispatch. Объявляется диспинтерфейс, например, таким образом:

type IMyDisp = dispinterface

['{EE05DFE2-5549-11D0-9EA9-0020AF3D82DA}']

property Count: Integer dispid 1;

procedure Clear dispid 2;

end;

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

type IIE = dispinterface

['{0002DF05-0000-0000-C000-000000000046}']

property Visible: WordBool dispid 402;

end;

procedure TForm1.Button1Click(Sender: TObject);

var

IE:IIE;

begin

IE:= Create0le0bject('InternetExplorer.Application') as IIE;

IE.Visible:= True;

end;

Эта программа успешно компилируется и работает, несмотря на то, что в интерфейсе объявлено только одно свойство из множества имеющихся свойств и методов. Это происходит благодаря тому, что Delphi не вызывает методы диспинтерфейса напрямую и поэтому не требует полного описания всех методов в правильном порядке. При вызове метода диспинтерфейса Delphi просто вызывает метод Invoke соответствующего метода IDispatch, передавая ему идентификатор метода, указанный в параметре dispid. В результате программист получает возможность строго контролировать типы при вызове методов интерфейса IDispatch и вызывать методы, описанные в диспинтерфейсе, без формирования сложных структур данных, требующихся для вызова метода Invoke. Необходимо лишь указать (или импортировать из библиотеки типов сервера) описание диспинтерфейса.

В описании диспинтерфейса допустимо использовать только OLE-совместимые типы данных.

Идея дуальных интерфейсов (dual interfaces) очень проста. Сервер реализует одновременно некоторый интерфейс VTable, оформленный но стандартам СОМ, и диспинтерфейс, доступный через интерфейс IDispatch. При этом интерфейс VTable должен наследоваться от IDispatch и иметь идентичный с диспинтерфейсом набор методов. Такое оформление сервера позволяет клиентам работать с ним наиболее удобным для каждого клиента образом.

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

Большинство OLE-серверов реализуют дуальный интерфейс.

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

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

Рис. 3.3. Структура интерфейса.

Эта структура позволяет обеспечить маршалинг — пересылку указателя между процессами (и в общем случае между компьютерами).

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

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

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

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

Если СОМ-сервер является внепроцессным, СОМ использует функцию CreateProcess, загружая исполняемый файл и инициализируя СОМ-сервер в его адресном пространстве. В этом случае нет возможности передать клиенту значение указателя на интерфейс, так как этот указатель идентифицирует объект, находящийся в другом адресном пространстве. Поэтому в адресных пространствах клиента и сервера создаются два объекта: стаб (stub) — представитель клиента в адресном пространстве сервера, имеющий дело с реальным указателем на интерфейс, и прокси (proxy) — представитель сервера в адресном пространстве клиента. Эти два объекта путем маршалинга связываются между собой с целью передачи клиентскому процессу указателя на интерфейс. При этом создается так называемый пакет маршалинга (marshalling packet) — пакет данных, содержащий необходимую информацию для соединения с процессом, в котором создан объект. Этот пакет создается с помощью функции CoMarshalInterface СОМ API, затем он передается процессу клиента любым доступным способом, где другая функция CoUnMarshalInterface превращает этот пакет в указатель на интерфейс. Стандартный маршалинг осуществляется с помощью автоматически генерируемого интерфейса IMarshal (рис. 3.5).

Рис. 3.4. Взаимодействие клиента с внутрипроцессным сервером.

Рис. 3.5. Взаимодействие клиента с внепроцессным сервером.

Сходная технология используется при вызовах удаленных процедур (Remote Procedure Calls, RPC), откуда она и была заимствована корпорацией Microsoft.

Естественно, прокси не содержит реализации методов интерфейса. Все аргументы вызываемых методов помещаются в пакет, передаваемый стабу посредством RPC. Прокси (таки стаб?) распаковывает переданные аргументы, помещает их в стек и обращается к реальному объекту, используя существующий указатель на интерфейс. Результат выполнения метода упаковывается в пакет и посылается обратно стабу, который распаковывает его и передает клиенту.

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

Рис. 3.6. Удаленный доступ к СОМ-серверу

Дата добавления: 2014-01-05