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

  • Системы на базе удаленного вызова процедуры

  • Транзакционные

  • Брокеры

  • Мониторы

  • Системы

  • Архитектура распределенных систем программного обеспечения. Учебное пособие издано при поддержке образовательной программы Формирование


    Скачать 1 Mb.
    НазваниеУчебное пособие издано при поддержке образовательной программы Формирование
    АнкорАрхитектура распределенных систем программного обеспечения
    Дата13.01.2023
    Размер1 Mb.
    Формат файлаdocx
    Имя файлаmdwrbook.docx
    ТипУчебное пособие
    #885216
    страница5 из 36
    1   2   3   4   5   6   7   8   9   ...   36

    Основные механизмы в распределенных системах


    1. Формыреализациисистемнойподдержки

    Примером того, как абстракции системной поддержки могут оказаться полезными при разработке программ взаимодействия, служит понятие удаленного вызова процедуры (Remote Procedure Call, RPC). Пользуясь абстракцией RPC можно полностью отвлечься от необходимости беспокоиться о каналах связи, об ошибках, возникающих при передаче, о согласовании действий двух прикладных систем, работающих на разных ЭВМ, о разнице в форматах представления данных на разных ЭВМ. Все, что требуется при пользовании системной поддержкой RPC, это сформулировать запрос в виде обращения к процедуре с параметрами, которая скроет нижние уровни сетевого взаимодействия (Рис. 2.1).
    Удаленный вызов процедуры: упрятывает детали взаимодействия за вызовом процедуры помогает связать гетерогенные платформы
    Сокеты:

    интерфейс уровня операционной системы, предоставляемый нижним коммуникационным протоколам
    TCP, UDP:

    Универсальный протокол датаграмм (UDP) передает пакеты данных без каких-либо гарантий. Протокол управления передачей (TCP) проверяет правильность доставки потоков данных
    Межсетевой протокол (IP): перемещает пакет данных от одного узла на другой
    Рис.2.1.Удаленныйвызовпроцедурыкакпрограммнаяабстракция,построеннаяна базе других коммуникационных слоев.

    Если необходимо обеспечить поддержку управления ошибками и сбоями, можно использовать транзакционный вариант удаленного вызова процедур. Делая транзакционные вызовы, можно не беспокоиться о состоянии вызова или взаимодействия, если в процессе их выполнения произошла ошибка. Если приложение или какая-нибудь его часть не срабатывает, транзакционные гарантии означают, что не возникнет никаких нежелательных побочных эффектов. Транзакционные гарантии в

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

    гарантии, обычно дающиеся на транспортном уровне (например, в транспортном протоколе TCP, и даже в его транзакционном варианте T/TCP, гарантирующем надежную доставку отдельных пакетов данных, составляющих отдельное сообщение).

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

    • Системы на базе удаленного вызова процедуры. Наиболее общая форма взаимодействия. В настоящее время системы RPC лежат в основе почти всех других форм системного программного обеспечения, включая и сетевые службы.

    • Транзакционныемониторы наиболее надежная и наиболее

    стабильная технология, применяемая при интеграции прикладных систем. Транзакционные мониторы выполняют удаленные процедуры с транзакционными расширениями. В зависимости от реализации в двух- или трехъярусной архитектуре, транзакционные мониторы делятся на легкие и тяжелые. Легкие мониторы обеспечивают RPC-интерфейс к базам данных, а тяжелые представляют собой наиболее содержательные системы с огромным числом программных инструментов, которые часто превосходят инструментарий операционных систем.

    • Брокерыобъектов. Системы RPC появились в те времена, когда

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

    • Мониторыобъектов. Развитие функциональности брокеров объектов

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

    • Системынабазеобменасообщениями. Еще в первых RPC-системах

    выяснилось, что синхронное взаимодействие не всегда обязательно.

    Асинхронное взаимодействие было обеспечено транзакционными мониторами с системами сохранных очередей. Однако такие системы очередей имеют собственную ценность. Их стали называть системами на основе обмена сообщениями (Message Oriented Middleware, МОМ). Они обеспечили транзакционный доступ к очередям, сохранные очереди и большое количество примитивов для чтения и записи в локальные и удаленные очереди.

    • Брокерысообщений это отдельная форма систем на основе обмена

    сообщениями, дополнительно выполняющая преобразования и фильтрацию сообщений при прохождении через систему очередей. На основе содержания сообщений они могут динамически выбирать их получателей. Единственным их отличием от систем очередей является то, что здесь к очередям добавлена дополнительная функциональность, а это допускает более сложное асинхронное взаимодействие.
      1. 1   2   3   4   5   6   7   8   9   ...   36


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