Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Вопросы_РСОИ.doc
Скачиваний:
51
Добавлен:
21.12.2018
Размер:
1.23 Mб
Скачать
  1. Связь посредством сообщений

Вызовы удаленных процедур и обращения к удаленным объектам способствуют сокрытию взаимодействия в распределенных системах, то есть повышают прозрачность доступа. К сожалению, ни один из этих механизмов не идеален. Кроме того, синхронную по определению природу RPC и RMI, при которой на время осуществления операции необходимо блокировать клиента, временами тоже хочется заменить чем-то другим. Это «что-то другое» обмен сообщениями.

Приложения всегда выполняются на хостах, а каждый хост предоставляет интерфейс с коммуникационной системой, через который сообщения могут передаваться. Хосты соединены сетью коммуникационных серверов, которые отвечают за передачу (или маршрутизацию) сообщения между хостами. Без потери общности можно предположить, что каждый из хостов связан только с одним коммуникационным сервером.

В качестве примера рассмотрим разработанную в подобном стиле систему электронной почты. Хосты работают как пользовательские агенты

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

Система электронной почты это типичный пример сохранной

связи (persistent communication). При сохранной связи сообщение, предназначенное для отсылки, хранится в коммуникационной системе до тех пор, пока его не удастся передать получателю. Сообщение сохраняется на коммуникационном сервере до тех пор, пока его не удастся передать на следующий коммуникационный сервер. Поэтому у отправляющего сообщение приложения нет необходимости после отправки сообщения продолжать работу. Аналогично, у приложения, принимающего сообщения, также нет необходимости находиться в рабочем состоянии во время отправки сообщения.

В противоположность сохранной связи при нерезидентнойсвязи (transient

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

Помимо сохранной и нерезидентной связи существует деление на синхронную и асинхронную связь. Характерной чертой асинхронной связи (asynchronous

communication) является немедленное после отправки письма продолжение работы отправителя. Это означает, что письмо сохраняется в локальном буфере передающего хоста или на ближайшем коммуникационном сервере. В случае синхронной связи (synchronous communication) отправитель блокируется до того момента пока его сообщение не будет сохранено в локальном буфере принимающего хоста или доставлено реальному получателю. Наиболее жесткая форма синхронного взаимодействия предполагает, что отправитель остается блокированным и на время обработки его сообщения получателем.

Интерфейс передачи сообщений

Требование независимости от аппаратного обеспечения постепенно привело к созданию стандарта пересылки сообщений, названному просто интерфейсом передачи сообщений (Message-Passing Interface, MPI).

MPI разрабатывался для параллельных приложений, но затем был перенесен на нерезидентное взаимодействие. Он предполагает использование базовых сетей. Кроме того, он предусматривает, что серьезные сбои в системе, такие как аварии процессов или участков сети, фатальны и не могут быть восстановлены автоматически. MPI предполагает, что связь происходит в пределах известной группы процессов. Каждая группа получает идентификатор. Каждый процесс в группе также получает идентификатор (локальный). Пара идентификаторов (groupID, processID), таким образом, однозначно определяет источник или получателя сообщения и используется вместо адреса транспортного уровня. В вычислениях может участвовать несколько, возможно перекрывающихся, групп процессов, исполняемых одновременно.

Сокеты Беркли (разработаны в университете Беркли)

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

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

Система очередей сообщений

Важный класс ориентированных на сообщения служб промежуточного уровня, известных как системы очередей сообщений (message-queuing systems), или ориентированный на сообщения промежуточный уровень (Message-Onented Middleware, MOM). Системы очередей сообщений создают расширенную поддержку асинхронной сохранной связи. Смысл этих систем заключается в том, что они предоставляют возможность промежуточного хранения сообщений, не требуя активности во время передачи сообщений ни от отправителя, ни от получателя. Их существенное отличие от сокетов Беркли и интерфейса MPI состоит в том, что системы очередей сообщений обычно предназначены для поддержки обмена сообщениями, занимающего минуты, а не секунды или миллисекунды.