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

Объектный RPC

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

Вызов метода объекта, реализованного в удаленном сервере, также использует заместитель и заглушку, но в данном случае клиенту необходимо выполнить  вызов удаленной процедуры (RPC) сервера. Протоколов RPC хватает в избытке, и Microsoft решила не создавать новый, но адаптировать существующий. Этот протокол . Microsoft называет его MS RPC . заимствован из OSF DCE. Как сам MS RPC, так и его модификация для DCOM . объектный RPC (Object RPC) . посылают по сети информацию в том же формате, что и DCE RPC (т.е. используют ту же структуру пакета). Хотя ORPC включает ряд новых соглашений по взаимодействию клиента с сервером, добавляет несколько новых типов данных и использует некоторые поля пакета особым образом, сама структура пакетов осталась прежней.

DCE RPC и MS RPC на самом  деле включают в себя два  разных протокола, которые поддерживаются  и ORPC. Один из них . CN или СО . используется поверх протоколов с установлением логических соединений (connection-oriented protocols), таких как TCP (Transmission Control Protocol). Поскольку CN подразумевает, что нижележащий протокол гарантирует надежную доставку данных, то он не проверяет точность передачи. Другой протокол . DG или CL . используется поверх транспорта без установления логического соединения (также называемого протоколом дейтаграмм), такого как UDP (User Datagram Protocol). Рассматривая нижележащий протокол как совершенно ненадежный, DG реализует собственные механизмы, гарантирующие надежную доставку данных. Для выдающего запрос клиента оба протокола выглядят совершенно одинаково, хотя нижележащие транспортные протоколы ведут себя абсолютно по-разному. Эти различия скрываются соответствующим протоколом RPC.

Независимо от используемого  протокола клиент должен обладать информацией  связывания (binding information) с пунктом назначения, прежде чем он выполнит вызов ORPC. В составе этой информации обычно сетевой адрес удаленной машины (например, адрес IP) и указание, какая комбинация протоколов должна использоваться (например, CL RPC и UDP). Информация связывания может включать точку назначения транспорта (transport endpoint) . ее часто называют портом . задающую конкретный процесс на удаленной машине. Информацию связывания удобно представлять как строковое связывание (string binding) . символьной строкой, содержащей всю необходимую информацию.

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

OXID и разрешатели OXID

          Сервер, реализующий один или несколько объектов СОМ, доступных клиентам на других машинах, можно рассматривать как экспортер объектов (object exporter). Разрешая удаленным клиентам доступ к своим объектам, сервер в некотором смысле "экспортирует" эти объекты, обеспечивая их межмашинное использование. Если сервер . однопоточный процесс с одним или несколькими объектами, то в качестве экспортера выступает сервер в целом. Если же сервер . многопоточный процесс с одной или несколькими комнатами (apartment), содержащими различные объекты, то экспортером является каждая из комнат. В любом случае каждому экспортеру объектов присваивается 8-байтовое значение. идентификатор экспортера объектов (OXID . Object Exporter Identifier). У одного процесса с несколькими комнатами может быть несколько OXID.

Для доступа к удаленному объекту клиент вначале должен получить его OXID. Имея OXID, клиент может использовать разрешатель OXID для отображения OXID в информацию связывания с объектом. На любой машине, поддерживающей DCOM, имеется разрешатель OXID (OXID resolver), и каждый разрешатель OXID поддерживает интерфейс lObjectExporter. Несмотря на свое СОМ-подобное имя, lObjectExporter не является интерфейсом СОМ. На самом деле это интерфейс RPC, и обращение к нему выполняется через вызовы чистого RPC, а не вызовы ORPC. В его составе 3 "метода": ResolveOXID, SimplePing и ComplexPing.

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

OBJREF: передача  указателей интерфейсов

          Как и вызов локального метода, вызов удаленного метода может содержать параметры. Но разные машины иногда используют для представления одних и тех же данных разные форматы. Например, многие системы для представления символов применяют ASCII, тогда как мэйнфреймы IBM применяют для этого код EBCDIC. А разные компьютеры используют разные форматы представления целых и вещественных чисел. Для обеспечения взаимодействия машин, применяющих разные форматы данных, выполняется маршалинг параметров вызова ORPC с использованием сетевого формата NDR (Network Data Representation). NDR . стандартная часть DCE RPC (и, конечно же, MS RPC) . обеспечивает эффективный способ передачи параметров практически любых типов СОМ IDL между машинами, использующими разные представления этих типов данных. Необходимая трансляция параметров из NDR в локальное представление выполняется машиной, принимающей вызов.

Однако один тип параметров, часто передаваемый в вызовах ORPC, не имеет прямой поддержки NDR . это указатели на интерфейсы. Объекты часто передают указатели на интерфейсы своим клиентам, а клиент имеет право передать имеющийся у него указатель на интерфейс любому другому объекту. Когда указатель на интерфейс ссылается на объект в том же процессе, проблем не возникает: указатель передается, как есть. Когда указатель на интерфейс ссылается на объект в другом процессе на той же машине, передается ссылка на данный интерфейс внутри соответствующего процесса. Но когда указатель на интерфейс ссылается на объект, расположенный на другой машине, то, что должно быть передано, является весьма сложной конструкцией . объектной ссылкой (object reference . OBJREF).

Согласно протоколу DCOM в состав OBJREF входят:

• OXID;
• уникальный идентификатор данного интерфейса объекта . идентификатор указателя интерфейса (interface pointer identifier . IPID);
• идентификатор объекта (object identifier . OID), определяющий объект;
• строковое связывание для разрешателя OXID на той машине, где исполняется объект.

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

Но как объект, получающий указатель на интерфейс, определяет, как связаться с объектом, заданным этим указателем? Точнее, откуда берется  информация связывания с объектом, не являющаяся частью самой OBJREF? Есть два  варианта. Если любой объект на локальной  машине уже связывался недавно с  объектом, имеющим тот же OXID, что  и объект, на который ссылается  указатель, то данный OXID уже есть в  таблице локального разрешателя OXID. Если же информация связывания в таблице отсутствует, ее надо запросить у машины, на которой исполняется объект, заданный данной OBJREF.

Чтобы получить необходимую  для использования новой OBJREF информацию связывания, DCOM на машине клиента, получившего OBJREF, обращается за помощью к локальному разрешателю OXID, передавая ему эту OBJREF. (Все это, конечно, скрыто от программиста и является частью инфраструктуры, обеспечиваемой DCOM.) Разрешатель OXID выделяет OXID из OBJREF и пытается отыскать его в собственной таблице OXID. Если объект с тем же OXID уже используется кем-то на этой машине, то в таблице будет запись для данного OXID с необходимым строковым связыванием. Предположим, объект А получил OBJREF интерфейса, поддерживаемого объектом X, расположенным на другой машине. Чтобы получить информацию связывания для осуществления вызовов с помощью нового указателя, реципиент передает OBJREF своему локальному разрешателю OXID. В данном случае разрешатель OXID может сразу возвратить нужную информацию.

Однако допустим, что OBJREF ссылается на интерфейс удаленного объекта Q, для которого у локального разрешателя OXID информации нет. Тогда разрешатель OXID извлекает из OBJREF информацию связывания с разрешателем OXID на машине, где исполняется объект Q, и с помощью ее связывается с этим разрешателем. Для этого локальный разрешатель OXID вызывает метод ResolveOxid интерфейса lObjectExporter разрешателя OXID на удаленной машине. В качестве параметра этого вызова передается OXID, выделенный из только что полученной OBJREF. Данный вызов возвращает строковое связывание для данного OXID, которое затем добавляется локальным разрешателем в свою таблицу. Вновь полученный указатель на интерфейс теперь можно использовать.

Здесь возникает естественный вопрос: почему в составе OBJREF передается не строковое связывание самого объекта, но связывание разрешателя OXID на машине объекта? Ведь тогда клиентскому разрешателю OXID вообще не пришлось бы связываться с разрешателем OXID объекта . полученная OBJREF уже содержала бы все необходимое для связи с объектом.

Чтобы понять, почему архитекторы DCOM приняли иное решение, вспомним, что DCOM позволяет клиенту работать с удаленным объектом с помощью  разных протоколов: TCP/IP, UDP/IP, IPX/SPX и др. Для каждого поддерживаемого  объектом протокола может потребоваться  загрузка отдельной DLL, которой обычно необходимы дополнительные потоки для  ожидания поступления запросов по данному  протоколу. Так что объекту, работающему  с несколькими протоколами, это  может дорого обойтись. Не удивительно, что архитекторы DCOM стремились снизить  накладные расходы, загружая протоколы  только тогда, когда это необходимо, и пытаясь обойтись их минимальным  количеством.

С этой целью объекты используют отложенную регистрацию протоколов (lazy protocol registration). Другими словами, объект загружает необходимый для протокола код, лишь когда клиент захочет работать с ним по данному протоколу. Например, когда разрешатель OXID объекта получает от клиентской машины вызов lObjectExporter::ResolveOxid, этот запрос выполняется с помощью протокола, скажем, TCP/IP. Разрешатель OXID на машине объекта может определить, загружен ли уже объектом код TCP/IP. Если нет, разрешатель приказывает объекту загрузить соответствующий код, после чего клиент и объект могут взаимодействовать по TCP/IP. Если затем другой разрешатель OXID запросит связь с тем же объектом по UDP/ IP, объект получит указание загрузить код и этого протокола. В то время как разрешатели OXID обязаны ожидать вызовы по всем протоколам, поддерживаемым данной машиной, конкретный объект загружает код только протоколов, явно запрошенных его клиентами. Данный подход иногда требует дополнительного обмена данными при установлении соединения, но он позволяет объектам избежать напрасной траты ресурсов на не используемые ими протоколы.

Обеспечение безопасного  доступа к удаленному объекту

          Объектный RPC предоставляет клиентам способ создания удаленных объектов и вызова их методов. Но возможность доступа к объектам на других системах повышает риск создания или использования таких объектов процессами или личностями, не имеющими соответствующих прав. Для минимизации подобного риска DCOM определяет стандартный способ доступа к сервисам защиты и их использования.

Здесь имеют место две  проблемы. Первая заключается в контроле над тем, кто имеет право запускать  серверы различных классов на данной удаленной машине . это сфера действия защиты активизации (activation security). Вторая проблема, состоящая в том, чтобы гарантировать контроль прав на вызовы клиентами методов уже исполняющихся объектов, известна как защита вызовов (call security). DCOM предоставляет решения обеих проблем.

Защита активизации

          Параметры реестра машины в точности определяют, кто имеет право запуска серверов на данном компьютере. Более общая установка разрешает или запрещает удаленную активизацию вообще. Если она отключена, ни один удаленный клиент не сможет запускать серверы или подсоединяться к какому-либо объекту на данной машине. Возможно также определение защиты активизации на уровне класса, что позволяет контролировать, какие удаленные клиенты имеют право на запуск сервера некоторого класса. Перечень имеющих разрешение на это содержит список управления доступом (access control list . ACL). И наконец, к классам, для которых не установлена защита активизации на уровне класса, может применяться защита активизации по умолчанию. Как и при защите активизации на уровне класса, защита активизации по умолчанию определяет тех, кто имеет право на запуск сервера в данной системе, с помощью ACL.

Всегда, когда используется ACL, необходимо определить личность пользователя или объекта, выполняющего запрос. Но это приводит к другому вопросу: что такое личность объекта? Или  что на жаргоне контроля прав доступа  означает слово принципал (principal). По сути, принципал. это некто (например, пользователь) или нечто (например, выполняющийся процесс), имеющий учетную запись (account) в данной среде независимо от его природы. Регистрируясь в системе, Вы идентифицируете своего принципала, вводя свой идентификатор пользователя и пароль. Предположим, после регистрации Вы запустили некий клиент, который создал объект на другой машине. Кем является принципал этого объекта? Ответ на данный вопрос важен, так как принципал объекта может определять, что может делать этот объект.

DCOM предоставляет несколько  ответов, зависящих от конфигурационной  информации класса. Вновь создаваемый  объект может быть сконфигурирован  для исполнения как определенный принципал, аналогично сервису Microsoft Windows NT. Но он может выполняться как тот же принципал, что и создавший его клиент, или как принципал интерактивного пользователя, запустившего клиент (если они различаются). Если для данного класса в реестре ничего не задано, вновь созданному объекту по умолчанию присваивается принципал клиента, создавшего его.