Структура и назначение программ в области информационных технологий (стр. 7 из 29)

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

Несмотря на отдельные сложные моменты, DCOM вообще проста для понимания. Она добавляет к знакомым основам СОМ всего 3 основных элемента: способ создания удаленного объекта, протокол вызова методов этого объекта и механизмы обеспечения безопасного доступа к нему.2 новых типа мнемоник : URL, асинхронная мнемоника

27. Компоненты DCOM

DCOM – система распределения приложений внутрипроцессных и внепроцессных серверов. Все компоненты подлежат регистрации, информация о нахождении компоненты прописывается в реестре клиентского компьютера или сервера. Используя эту информацию, клиентское программное обеспечение узнаѐт, с каким компьютером оно должно контактировать. Используемая система рассматривает системный реестр и ищет в нем запись того компьютера, который используется в данное время клиентским компьютером. После этого, происходит связывание с компьютером по сети, на котором распознается компонента, затем передаются данные непосредственно. Непосредственно механизмом соединения занимается операционная система.

28. Внутрипроцессные и внепроцессные компоненты DCOM.

Внутрипроцессные компоненты исполняются в том же пространстве процесса, что и приложение, которое его использует. Компоненты приложений используют совместно адресное пространство. DLL

Внепроцессные компоненты исполняются в другом пространстве процесса, чем приложение, которое его использует. Компонент не использует совместное адресное пространство с процессом. Они строятся как модули EXE.

29.Удаленный вызов процедур (RРС).

30. Функции RРС.

Рассмотренные методы синхронизации процессов и коммуникаций предполагали использование одного компьютера. Однако, часто приложения должны работать в пределах локальной или распределенной сети. Одним из методов реализации взаимодействия является удаленный вызов процедур remote procedure calls (RPC). Вызов процедуры представляет собой классическую форму синхронной коммуникации: вызывающий процесс передает управление подпроцессу и ждет возвращения результатов. Используя RPC, программисты распределенных приложений могут не учитывать деталей при обеспечении интерфейса с сетью. Транспортная независимость RPC изолирует приложение от физических и логических элементов механизма коммуникаций данных и позволяет ему использовать разнообразие транспортных протоколов. RPC делает модель вычислений клиент/сервер более мощной и более простой для программирования. Использование компиляторов протоколов ONC RPCGEN позволяет клиентам прозрачное осуществление удаленных вызовов через локальный интерфейс процедуры. Как и при обычном вызове функции, при вызове RPC аргументы вызова передаются удаленной процедуре, и вызывающий процесс ждет ответа, который будет возвращен из удаленной процедуры. Порядок действий следующий:

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

Удаленная процедура уникально идентифицируется тройкой: (номер программы, номер версии, номер процедуры). Номер программы идентифицирует группу соотносящихся удаленных процедур, каждая из которых имеет уникальный номер процедуры. Программа может состоять из одной или более версий. Каждая версия состоит из множества процедур, которые могут быть вызваны удаленно. Номера версии позволяют использоваться одновременно нескольким версиям RPC протокола. Каждая версия содержит множество процедур, которые можно вызвать удаленно. Каждая процедура имеет свой номер процедуры.

Для разработки приложения RPC необходимо выполнить следующие шаги:

Определить протокол для связи клиент-сервер.

Разработать программу клиента.

Разработать программу сервера.

Вызов удаленных процедур (RPC)

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

Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

Асимметричность, то есть одна из взаимодействующих сторон является инициатором; Синхронность, то есть выполнение вызывающей процедуры при останавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры. Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующим отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса - по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут "осиротевшими", а при аварийном завершении удаленных процедур станут "обездоленными родителями" вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.

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

Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем.

31. Маршаллинг.

Для передачи данных от пользовательского приложения обычному внутрипроцессному компоненту СОМ, а также для сохранения параметров используется стек данного компонента. Однако при передаче аргумента внепроцессному компоненту DCOM это невозможно. Разница между внутренним и удаленным серверами в том, какой тип межпроцессной связи используется. В данном случае существует необходимость использования посредников, которые обеспечивают передачу параметров и вызов функций. Для передачи параметров нужен механизм, позволяющий передавать данные за пределы процесса. Этот механизм называется маршализацией. Т.к. в случае, когда клиент и сервер находятся в разных адресных пространствах, доступ к ресурсам не может быть осуществлен непосредственно через указатели, то маршализация работает с помощью механизма, к-рый использует объекты заместители proxies и суррогаты stub. Они обеспечивают функцию представительства (proxy function), встроенную в клиент, и суррогатную, встроенную в компонет. Заместитель (proxy) маршализирует данные и подготавливает их для отправки за проделы компонент процессов.

Соответсвеноо, суррогатная функция демаршализирует данные для использования компонет. Использование заместителей и суррогатов показано на рисунке:

посредники со стороны клиента (proxy) осуществляют упаковку аргументов в пакеты маршаллинга (marshalling packets), и обеспечивают удаленный вызов процедур

(Remote Procedure Call). Посредник со стороны сервера (stub) реализуют распаковку параметров, и помещение их в стек. Далее осуществляется вызов непосредственно реализации метода. По сути, сервер создает клиентский вызов процедуры в своем собственном адресном пространстве. Посредники используют COM-средства, для осуществления взаимодействия в разных процессах. Для взаимодействия объектов, находящихся на разных машинах, используются средства расширения COM – распределенная COM (Distributed COM или DCOM). COM предлагает стандартный механизм маршаллинга – интерфейс диспетчеризации (Dispatch Interface).