DCOM (курсовая работа) (548068), страница 2
Текст из файла (страница 2)
И хотяCoCreatelnstanceEx создана для работы с удаленными объектами, нет причин, по которым клиенты немогли бы использовать ее для эффективного создания экземпляров объектов, реализованныхлокальными серверами и серверами "в процессе".CoCreateInstanceEx также имеет параметр, позволяющий клиенту указать машину, на которойдолжен быть создан объект. Вместо того, чтобы полагаться в определении удаленной системы налокальный реестр, клиент может динамически выбирать удаленную машину во время создания объекта.Имя машины задается, как и в предыдущем случае, —доменным именем, адресом IP или в другомформате, поддерживаемом сетевыми протоколами.
Поскольку CoCreateInstanceEx, как иCoCreateInstance, использует CoGetClassObject для получения указателя на интерфейс соответствующейфабрики класса, постольку имя машины необходимо передать при вызове CoGetClassObject. Для этогоиспользуется зарезервированный ранее параметр, так что необходимость в новой функцииCoGetClassObjectEx отпадает.Объединение создания и инициализацииПосле того, как объект создан клиентом, следующим шагом обычно является инициализацияобъекта путем выдачи ему команды загрузить перманентные данные. Например, клиент может вызватьметод IPersistFile::Load вновь созданного объекта для загрузки данных из файла. Если объект хранитсвои перманентные данные, используя структурированное хранилище, клиент может вызватьIPersistStorage::Load, передав указатель на соответствующее хранилище.Этот двухэтапный процесс создания и затем инициализации при использовании удаленногообъекта не претерпевает никаких изменений — клиент по-прежнему выполняет оба шага и волен делатьэто традиционным способом, вызвав сначала СоCreateInstance или CoCreateInstanceEx и обратившисьзатем к соответствующему методу интерфейса IPersist для инициализации объекта.
Но если объектвыполняется на удаленной машине, то выполнение этих шагов требует серии циклов "запрос-ответ", чтоможет быть неприемлемо медленно. Чтобы улучшить ситуацию, DCOM предоставляет клиентам двеальтернативные функции, каждая из которых создает и инициализирует объект за один прием. Еслиобъект выполняется локально, то использование этих функций представляет собой главным образомлишь дополнительное удобство (хотя некоторый выигрыш в производительности достигается и здесь засчет сокращений числа вызовов между процессами), но для удаленных объектов реализация этихфункций оптимизирована.Первая функция — CoGetInstanceFromFile — создает новый объект и инициализирует егоданными из файла.
Параметры функции включают машину, на которой создается объект, CLSID, имяфайла и, подобно CoCreateInstanceEx, список IID нужных клиенту интерфейсов. Если CLSID не задан,функция пытается определить его по имени файла так, как это делает файловый моникер.Использование этой функции аналогично вызову CoCreateInstanceEx и последующему обращению кметоду IPersistFile::Load объекта.
Вторая функция — CoGetInstanceFromIStorage — работает сходнымобразом за исключением того, что ей передается указатель на IStorage (он задает соответствующее4хранилище), а не имя файла. Вызов второй функции аналогичен вызову CoCreateInstanceEx споследующим обращением к методу IPersistStorage::Load объекта.Хотя обе функции позволяют указать машину, на которой должен быть создан объект, ни длятой, ни для другой эта информация не обязательна. Если имя машины не задано, место созданияобъекта зависит от нескольких факторов.
Когда в локальном реестре данный CLSID связан с именемудаленной машины, как было описано выше, объект создается на указанном компьютере. А если записьдля класса в реестре содержит значение ActivateAtStorage, то объект создается на той машине, гдерасположен заданный файл или хранилище.Возможно также, что машина, на которой вызывается CoGetInstanceFromFile илиCoGetInstanceFromIStorage, вообще не имеет информации о данном классе — локальный реестр можетне содержать записи для соответствующего CLSID.
Тогда предпринимается попытка создать объект натой машине, где находится указанный файл или хранилище. Если и в реестре той машины нет никакойинформации о данном классе, вызов функции завершается с ошибкой. В противном случае объектсоздается на той же машине, где находится файл или хранилище, как если бы в локальном реестре былозначение ActivateAtStorage.Использование моникераЧтобы создать удаленный объект, клиент может воспользоваться и моникером — объектом,который знает, как создать и инициализировать один экземпляр другого объекта.
Моникеры могутвыполнять создание экземпляров и инициализацию объектов как на локальных, так и на удаленныхмашинах. Для клиента моникера невидимо, исполняется созданный моникером объект локально илиудаленно. Место, где выполняется объект, может быть невидимо и самому моникеру.Когда клиент вызывает для моникера IMoniker::BindToObject, последний обычно вызываетCoCreateInstance с CLSID, полученным из своих перманентных данных. Затем моникер инициализируетвновь созданный объект, используя информацию своих перманентных данных — например, имя файла.Если для CLSID, передаваемого моникером CoCreateInstance, в реестре указана удаленная машина, тообъект будет создан на этой машине.
При этом сам моникер не узнает, что он создал удаленный объект.Но моникер может быть в курсе того, что создает объект на удаленном компьютере. Привызове клиентом метода моникера IMoniker::BindToObject есть вероятность, что перманентноехранилище объекта, указываемого моникером, находится на удаленной машине и что в реестреклиентской машины для класса объекта указано ActivateAtStorage. В этом случае моникер создаетобъект на той машине, где находится перманентное хранилище объекта, подобно CoGetInstanceFromFileи СоGetInstanceFromIStorage.Файловый моникер содержит имя файла, которое обычно задает и местонахождениеперманентных данных объекта (файл) и класс объекта (определяется по расширению имени файла или,возможно, по содержимому файла).
Если данный файл хранится на удаленном файл-сервере, а не налокальной машине и если в реестре локальной машины присутствует ActivateAtStorage, моникерсоздаст объект на файл-сервере, а не на локальном компьютере.Моникер URL содержит URL, определяющий местонахождение перманентного хранилищаобъекта. Если в локальном реестре для класса объекта, идентифицируемого этим моникером URL,задано ActivateAtStorage, то вызов метода моникера IMoniker::BindToObject создаст объект накомпьютере, указанном URL, а не на машине, где исполняются моникер и/или его клиент.
Затем,моникер приказывает объекту загрузить его перманентные данные по информации, заданной URL. И,подобно CoGetInstanceFromFile и CoGetInstanceFromIStorage, файловый моникер или моникер URLавтоматически пытаются создать объект на той же машине, где находится его перманентное хранилище,если в локальном реестре моникером не найдено информации о классе объекта.Доступ к удаленному объектуВозможность удаленного создания объекта СОМ — первое, что нужно для работы враспределенной среде. С точки зрения клиента, доступ к такому удаленному объекту осуществляетсятак же, как и к локальному — все абсолютно одинаково.
Однако скрывающаяся за этим реальностьгораздо сложнее — ведь для доступа к удаленным методам используются механизмы, совершенноотличные от механизмов работы с локальными объектами.5Объектный RPCПосле запуска удаленного объекта и получения указателей его интерфейсов клиент можетвызывать методы этих интерфейсов. Вызов метода объекта "в процессе", по сути, означаетнепосредственное обращение к нему через виртуальную таблицу (а в случае диспинтерфейса и черезIDispatch::Invoke). Обращение к методу объекта, реализованного в локальном сервере, требует участиязаместителя, заглушки и некоторого механизма коммуникаций между процессами.Вызов метода объекта, реализованного в удаленном сервере, также использует заместитель изаглушку, но в данном случае клиенту необходимо выполнить вызов удаленной процедуры (RPC)сервера.
Протоколов RPC хватает в избытке, и Microsoft решила не создавать новый, но адаптироватьсуществующий. Этот протокол — Microsoft называет его MS RPC — заимствован из OSF DCE(Microsoft, однако, не заимствовала у OSF реализацию протокола; MS RPC представляет собой другуюреализацию DCE RPC, созданную на основе общедоступной спецификации). Как сам MS RPC, так и егомодификация для DCOM — объектный RPC (Object RPC) — посылают по сети информацию в том жеформате, что и DCE RPC (т.е.
используют ту же структуру пакета). Хотя ORPC включает ряд новыхсоглашений по взаимодействию клиента с сервером, добавляет несколько новых типов данных ииспользует некоторые поля пакета особым образом, сама структура пакетов осталась прежней.DCE RPC и MS RPC на самом деле включают в себя два разных протокола, которыеподдерживаются и ORPC. Один из них — CN или СО — используется поверх протоколов сустановлением логических соединений (connection-oriented protocols), таких как TCP (TransmissionControl Protocol).
Поскольку CN подразумевает, что нижележащий протокол гарантирует надежнуюдоставку данных, то он не проверяет точность передачи. Другой протокол — DG или CL —используется поверх транспорта без установления логического соединения (также называемогопротоколом дейтаграмм), такого как UDP (User Datagram Protocol). Рассматривая нижележащийпротокол как совершенно ненадежный, DG реализует собственные механизмы, гарантирующиенадежную доставку данных.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
