Главная страница
Навигация по странице:

  • Удаленный вызов процедур

  • Удаленный вызов процедуры, его реализация и использование. Реферат_Худойназаров С1. Удаленный вызов процедуры, его реализация и использование


    Скачать 28.6 Kb.
    НазваниеУдаленный вызов процедуры, его реализация и использование
    АнкорУдаленный вызов процедуры, его реализация и использование
    Дата28.04.2022
    Размер28.6 Kb.
    Формат файлаdocx
    Имя файлаРеферат_Худойназаров С1.docx
    ТипРеферат
    #502239

    САМАРКАНДСКИЙ ФИЛИАЛ ТАШКЕНТСКОГО УНИВЕРСИТЕТА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ ИМЕНИ АЛЬ-ХОРАЗМИ

    Реферат

    ТЕМА: Удаленный вызов процедуры, его реализация и использование

    Выполнил:

    Студент STT-19-02 группы

    Худойназаров С.


    Удаленный вызов процедур


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

    Проблемы и задачи, которые необходимо решить при реализации RPC: 1. вызывающая и вызываемая процедуры выполняются на разных машинах и имеют разные адресные пространства, что создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру. 2. в отличие от локального вызова удалѐнный вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.
    3. в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: ‒ при аварии вызывающей процедуры удалѐнно вызванные процедуры станут
    «осиротевшими»; ‒ при аварийном завершении удалѐнных процедур вызывающие процедуры станут «обездоленными родителями», которые будут безрезультатно ожидать
    ответа от удалѐнных процедур.4. Неоднородность языков программирования и операционных сред => проблема
    совместимости, до сих пор не решѐнная ни с помощью введения одного
    общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.

    3Базовые операции RPC Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычном компьютере, работающем автономно. Чтобы осуществить вызов,
    вызывающая процедура помещает параметры в стек в обратном порядке. После того, как вызов выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Идея, положенная в основу RPC, состоит в том, чтобы сделать вызов удаленной процедуры выглядящим по возможности так же, как и вызов локальной процедуры. Другими словами - вызывающей процедуре не требуется знать, что вызываемая процедура находится на другой машине, и наоборот. RPC достигает прозрачности следующим путем. Когда вызываемая процедура действительно является удаленной, в библиотеку помещается вместо локальной процедуры другая версия процедуры, называемая клиентским стабом (англ. stub - заглушка). Подобно оригинальной процедуре, стаб вызывается с использованием вызывающей последовательности, так же происходит прерывание при обращении к
    ядру. Только в отличие от оригинальной процедуры он не помещает параметры в регистры и не запрашивает у ядра данные, вместо этого он формирует сообщение для отправки ядру удаленной машины. 4Взаимодействие программных компонентов при выполнении
    удаленного вызова процедуры 5Этапы выполнения процедуры RPC 8Реализации RPC Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM.
    Существует множество технологий, обеспечивающих RPC, например:
    DCE/RPC — Distributed Computing Environment / Remote Procedure Calls (бинарный протокол на базе различных транспортных протоколов, в том числе TCP/IP); DCOM — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объектно-ориентированное расширение DCE/RPC, позволяющее передавать ссылки на объекты и вызывать методы объектов через таковые ссылки);
    JSON-RPC— JavaScript Object Notation Remote Procedure Calls - протокол,
    использующий JSON (текстовый формат обмена данными, основанный на JavaScript) для кодирования сообщений; JSON-RPC определяет несколько типов данных и команд, поддерживает уведомления и множественные вызовы. .NET Remoting - созданный компанией Microsoft компонент, предоставляющий API для межпроцессного взаимодействия. Является частью пакета .NET Framework 1.0 и фактически представляет собой Microsoft-реализацию протокола SOAP. 9 Java RMI — Java Remote Method Invocation — программный интерфейс вызова удаленных методов в языке Java, представляющий собою распределенную объектную модель, специфицирующую, способы вызовов удаленных методов, работающих на
    другой виртуальной машине Java. XML RPC – XML-вызов удалѐнных процедур – протокол, использующий XML для кодирования своих сообщений и HTTP в качестве транспортного механизма. Является
    прародителем SOAP. SOAP — протокол обмена структурированными сообщениями в распределѐнной вычислительной среде. Первоначально SOAP предназначался в основном для реализации RPC, но сейчас используется для обмена произвольными сообщениями в
    формате XML, а не только для вызова процедур.
    Internet Communications Engine (Ice) – разработанная ZeroC объектная система промежуточного слоя, использующая механизм удаленного вызова процедур. Распространяется под двойной лицензией: GNU GPL (свободное ПО) или коммерческой. Ice поддерживает много платформ программирования, включая C++, Java, .NET, Visual Basic, Python, Ruby и PHP. Ice успешно конкурирует с SOAP, поскольку использует бинарный протокол передачи данных, обеспечивая меньшую
    нагрузку на сеть и процессор. 10Организация связи с использованием удаленных объектов Объектно-ориентированная технология в настоящее время широко применяется при разработке приложений, в том числе и распределенных. Одним из наиболее важных свойств объекта является то, что он скрывает особенности реализации, предоставляя для взаимодействия строго описанный интерфейс. Это позволяет заменять или изменять
    объекты, оставляя интерфейс неизменным. Развитие клиент-серверной архитектуры в начале 1990-х годов привело к формированию объектно-ориентированной концепции распределенных систем,
    ориентированной на инкапсуляцию механизма распределенных взаимодействий и уменьшение сложности разработки распределенных приложений посредством методов объектно-ориентированной разработки и удаленных вызовов методов объектов. Основными достоинствами данного подхода стали:  упрощение разработки распределенных приложений по сравнению склассическим клиент/серверным подходом; возможность разработки приложений для гетерогенных вычислительных сред (обеспечивалась применением виртуальных машин, например, Java, и независимым описанием интерфейсов взаимодействующих компонентов);  возможность отделения интерфейса удаленного объекта от его непосредственной реализации.11 Удаленный объект представляет собой некоторые данные, совокупность которых определяет его состояние. Это состояние можно изменять путем вызова его методов. Если возможен прямой доступ к данным удаленного объекта, это происходит посредством неявного удаленного вызова, необходимого для передачи значения поля данных объекта между процессами. Методы и поля объекта, которые могут использоваться через удаленные вызовы, доступны через некоторый внешний интерфейс класса объекта. Для передачи параметров по сети используется сериализация объектов и данных. Сериализация – это перевод состояния объекта в последовательность битов (чаще всего, бинарный или XML-файл), после чего его копия может быть
    передана в другой процесс. Обратный процесс - десериализация - это восстановление состояния объекта из принятой последовательности битов.

    14Java RMI Приложение Java RMI Клиент Сервер 1. Получение с сервера ссылки на УО. 2. Вызов методов УО. 1. Создание УО. 2. Публикация ссылки на УО: - с помощью специального регистра; - передача в виде части обычной
    операции. 3. Ожидание от клиентов вызова УО. Технология Java RMI
    Технология Java RMI (Remote Method Invocation - вызов удаленных методов) позволяет обеспечить прозрачный доступ к методам удаленных объектов (УО), обеспечивая доставку параметров вызываемого метода, сообщение объекту о необходимости выполнения метода и передачу возвращаемого значения клиенту обратно. Информация 15Достоинства:  возможность разрабатывать систему целиком основываясь на объектно-ориентированной концепции, не погружаясь в разработку собственных протоколов взаимодействия между распределенными компонентами систем;
    кроссплатформенность, предоставляемая виртуальной машиной
    Java. Недостатки: строгая ограниченность данной технологии платформой Java; необходимость обработки соединений между распределенными
    компонентами приложения = > ограничение масштабируемости. 16CORBA
    CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных запросов) - это технология разработки распределенных приложений, ориентированная на интеграцию распределенных изолированных систем. Разные аппаратные средства Разные операционные системы Разные языки программирования Обеспечение взаимодействия программ Проблема !!! 1989 г. - создание консорциума OMG – Object Management Group 17 Основная задача OMG – разработка и продвижение объектно-ориентированных технологий и стандартов. Это некоммерческое объединение, разрабатывающее стандарты для создания корпоративных платформо-независимых приложений. Консорциум OMG был создан 11 компаниями, среди которых были как разработчики, так и потребители программного обеспечения. Среди создателей OMG следует отметить такие компании как Hewlett-Packard, IBM, Sun Microsystems, Apple
    Computer, American Airlines и Data General. Долгое время будущее стандартов, продвигаемых OMG (в первую очередь CORBA), подвергалось сомнению в некоторых кругах. Однако сейчас консорциум включает порядка 800 компаний. Концептуальной инфраструктурой, на которой базируются все спецификации OMG, является Object Management Architecture (OMA). В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG сервисы, программные образцы и шаблоны, язык определения интерфейсов распределенных объектов IDL (Interface Definition Language), стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная
    модель CORBA. Главной особенностью CORBA является использование компонента ORB (Object Resource Broker - брокер ресурсов объектов) для создания экземпляров объектов и вызова их методов. Данный компонент формирует «мост» между приложением и инфраструктурой CORBA. 18 Основные понятия технологии CORBA В 1997 г. консорциум OMG опубликовал спецификацию CORBA 2.0. В ней
    определялись стандартный протокол и отображение для языка C++, а в 1998 г. Было определено отображение для Java. В результате разработчики получили инструментальное средство, позволяющее им относительно легко создавать неоднородные распределенные приложения. CORBA быстро завоевала популярность, и с использованием этой технологии был создан ряд критически важных приложений. 19 Технология CORBA Ядро архитектуры CORBA 20 Технологический стандарт CORBA определяет язык IDL применяемый для унифицированного описания интерфейсов распределенных объектов, и его отображения на языки Ada, C, C++, Java, Python, COBOL, Lisp, PL/1 и Smalltalk. Для преобразования описания интерфейса на языке IDL на требуемый язык программирования используется специальный компилятор. В дальнейшем построенный с его помощью программный код может быть преобразован любым стандартным компилятором в исполняемый код. Для создания экземпляров объектов и вызова их методов используется компонент ORB, который формирует «мост» между приложением и инфраструктурой CORBA. ORB поддерживает удаленное взаимодействие с другими ORB, а также обеспечивает управление УО, включая учет количества ссылок и времени жизни объекта.
    Для обеспечения взаимодействия между ORB используется протокол GIOP
    (General Inter-ORB Protocol - общий протокол для коммуникации между ORB). Наиболее распространенной реализацией данного протокола является протокол IIOP (Internet Inter-ORB Protocol - протокол взаимодействия ORB в сети интернет), обеспечивающий отображение сообщений GIOP на стек протоколов TCP/IP.


    написать администратору сайта