Файл: Учебное пособие издано при поддержке образовательной программы Формирование.docx

доставки сообщений без изменения самих компонентов, генерирующих и получающих эти сообщения.

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

На практике применяются различные комбинации этих типов взаимодействия. В случае сохранной асинхронной связи(Рис. 1.5-а) сообщение сохраняется в буфере сервера. Именно этот вид связи используется в системах электронной почты. В случае сохраннойсинхроннойсвязи(Рис.1.5-б) сообщения хранятся только на принимающем прикладном комплексе. Отправитель блокируется на все время, пока сообщение не попадет в этот буфер. Усеченный вариант сохранной синхронной связи заключается в том, что блокировка отправителя осуществляется до доставки сообщения серверу получателя.



Рис.1.5.Сохраннаяасинхроннаяисохраннаясинхроннаясвязьмежду подсистемами А и Б.

При асинхронной несохранной связи(Рис. 1.6-а) приложение отправляет сообщение, временно сохраняемое в локальном буфере передающего комплекса, а отправитель продолжает свою работу. Параллельно коммуникационная система направляет сообщение в точку, из которой оно может достигнуть места назначения, возможно с сохранением в локальном буфере. Если получатель в момент прихода сообщения на принимающий комплекс этого получателя не активен, передача обрывается. Другой пример этого вида связи – асинхронный удаленный вызов процедуры.




Рис.

---

1.6.Несохраннаяасинхроннаясвязьинесохраннаясинхроннаясвязьмежду подсистемами А и Б распределенной системы, ориентированная на прием.

Синхроннаянесохраннаясвязьсуществует в нескольких вариантах. В наиболее слабой форме, основанной наподтвержденияхприема

сообщений (Рис. 1.6-б), отправитель блокируется до тех пор, пока сообщение не окажется в локальном буфере принимающего комплекса. После получения подтверждения отправитель продолжает свою работу. Другая форма этой связи, ориентированная на доставку(Рис. 1.7-а), предполагает, что отправитель должен быть заблокирован до момента доставки сообщения самому получателю, который продолжит свою часть работы по его обработке. Наиболее жесткий вариант синхронной несохранной связи, ориентированный на ответ(Рис. 1.7-б), предполагает блокировку отправителя до получения ответного сообщения с другой стороны, как при работе систем клиент/сервер в режиме запрос/ответ. Эта же схема взаимодействия характерна и для систем, построенных на базе моделей удаленного вызова процедуры и удаленного обращения к методу. Каждый вид связи находит свое применение в распределенных системах на том или ином уровне составляющих их компонентов.




Рис.1.7.ВидынесохраннойсинхроннойсвязимеждуподсистемамиАиБ распределенной системы.

2. 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, МОМ). Они обеспечили транзакционный доступ к очередям, сохранные очереди и большое количество примитивов для чтения и записи в локальные и удаленные очереди.

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

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

2. 1   2   3   4   5   6   7   8   9   ...   36

---