Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

2.3.

Обращение к удаленным объектам 121

ческого объекта управление

РШ

переходит к исполняющей системе DCE, связы-

вающей его с тем клиентом, по требованию которого он был создан.

В противоположность динамическим объектам,

имеповапные распределенные

объекты {distributed

named

objects)

не предназначены для работы с едршственным

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

ми клртентами. Именованные объекты регистрируются службой каталогов, так

что клиент может найти объект и выполнить привязку к нему. Регистрация

означает сохранение уникального идентификатора объекта, а также информации

о том, как соединиться с сервером объекта. Разницу между динамическими и име-

нованными объектами иллюстрирует рис. 2.18.

Машина сервера Машина сервера

Динамический ^

(закрытый) объект!

\С Динамический Л

Цзакрытый) объект)

•

С Динамический ^

Цзакрытый) объект;

'^ S \

•

Удаленная

ссылка

Именованный

(совместно используемый)

объект

1< А W

/ , N

/ ' \

* 1 ^

~~~~~'~:^*' 1 ^

у'

1 ^v

•

•'^ 1

•

Клиент 1

Клиент 2

Клиент 3 Клиент 1 Клиент 2

Клиент 3

Рис. 2.18. Распределенные динамические объекты в DCE (а).

Распределенные именованные объекты (б)

Обращение к удаленным объектам в DCE

Как можно заметить, все обращения к удаленным объектам в DCE производятся

средствами RPC. Клиент, обращаясь к методу, передает серверу идентификатор

объекта, идентификатор интерфейса, содержащего метод, идентификацию само-

го метода и параметры. Сервер поддерживает таблицу объектов. С помощью этой

таблицы сервер, получив идентификатор объекта и идентификатор интерфейса,

идентифицирует объект, к которому обратился клиент. Затем он выбирает запро-

шенный метод и передает ему параметры.

Поскольку сервер может поддерживать тысячи объектов, DCE предоставляет

возможность не держать все объекты в памяти, а помещать их при необходимо-

сти во вспомогательное хранилище данных. Когда к серверу приходит запрос на

обращение к объекту, отсутствующему в таблице объектов, исполняющая систе-

ма может вызвать специализированную функцию поиска, которая извлечет объ-

ект из хранилища и поместит его в адресное пространство сервера. Обращение

к объекту произойдет после его помещения в оперативную память.

122 Глава 2. Связь

У распределенных объектов в DCE имеется одна проблема, связанная с их

чрезвычайной близостью с RPC: не существует механизма прозрачных ссылок

на объекты. Клиент имеет в лучшем случае

дескриптор

привязки

(binding

handle),

ассоциированный с именованным объектом. Дескриптор привязки содержит

идентификатор интерфейса, транспортный протокол, используемый для связи

с сервером объектов, а также адрес и конечную точку хоста сервера. Дескриптор

привязки может быть преобразован в строку и в таком виде передан другому

процессу.

Отсутствие приемлемого механизма ссылок на объекты в пределах системы

делает передачу параметров в DCE более сложной, чем в большинстве объектных

cpicTCM. Разработчик приложений для RFC должен сам придумывать механизм

передачи параметров. На деле это означает, что необходимо явно производить

маршалинг объектов для передачи их по значению и самостоятельно создавать

для этого соответствующие процедуры.

В качестве альтернативы разработчик может использовать делегирование.

Для этого из спецификации интерфейса объекта генерируется специальная за-

глушка. Заглушка работает как оболочка нужного объекта и содержит только те

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

быть скомпонована с любым процессом, который хочет использовать этот объ-

ект. Преимущества такого подхода становятся понятны, если вспомнить, что DCE

разрешает передавать удаленные ссылки на заглушки в качестве параметров вы-

зовов RFC. Соответственно, появляется возможность ссылаться на объекты сис-

темы при помощи ссылок на заглушки.

Дополнительную информацию по объектному программированию в DCE мож-

но найти в [335, 476].

2.3.6. Пример 2

—

Java RMI

в DCE распределенные объекты были добавлены в качестве расширения вызо-

вов удаленных процедур. Вместо того чтобы указывать удаленную процедуру на

сервере, клиент указывал удаленную процедуру для объекта на сервере. Отсутст-

вие подобающего механизма ссылок на объекты системы подчеркивало, что мы

действительно имеем дело с простым расширением RFC.

Взглянем теперь на распределенные объекты с абсолютно другой точки зре-

ния. В Java распределенные объекты интегрированы с языком. Основная цель

этого

—

сохранить, насколько это возможно, семантику нераспределенных объ-

ектов. Другими словами, создатели языка Java стремились к высокому уровню

прозрачности распределения. Однако, как мы увидим, создатели Java также

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

эффективна, затруднительна или нереализуема, распределенность может быть

явной.

Модель распределенных объектов Java

Язык Java также поддерживает распределенные объекты исключительно в форме

удаленных объектов. Напомним, что удаленный объект

—

это распределенный

2.3.

Обращение к удаленным объектам 123

объект, тело которого постоянно находится на одной и той же машине, а интер-

фейсы доступны удаленным процессам. Интерфейсы реализованы обычным об-

разом через заместителя, который предоставляет те же интерфейсы, что и уда-

ленный объект. Сам заместитель имеет вид локального объекта, находящегося

в адресном пространстве клиента.

Между удаленными и локальными объектами существует лишь несколько

различий, но различия эти тонки и важны. Во-первых, значительно различается

клонирование локальных и удаленных объектов. Клонирование локального объ-

екта О приводит к появлению нового объекта такого же типа, что и О, в точно

таком же состоянии. Процедура клонирования возвращает точную копию клони-

рованного объекта. Подобная семантика слабо применима к удаленным объек-

там. Если мы попытаемся создать точную копию удаленного объекта, нам потре-

буется клонировать не только сам объект на его сервере, но и заместитель на

каждом из клиентов, которые в этот момент привязаны к удаленному объекту.

Поэтому операция клонирования удаленного объекта производится только на

сервере. Она приводит к созданию точной копии объекта в адресном пространст-

ве сервера. Заместитель объекта не клонируется. Если клиент на удаленной ма-

шине хочет получить доступ к клону объекта на сервере, он должен сначала вы-

полнить повторную привязку к этому объекту.

Более существенное различие между локальными и удаленными объектами

в Java заключается в семантике блокировки объектов. Java позволяет построить

любой объект в виде

монитора.

Для этого достаточно объявить один из методов

синхронизируемым

{synchronized).

Если два процесса одновременно вызовут син-

хронизируемый метод, работать будет только один из них, в то время как второй

окажется заблокированным. Таким образом, мы можем гарантировать, что дос-

туп к внутренним данным объекта будет осуществляться только последовательно.

Как и в мониторе, процесс может быть заблокирован и изнутри объекта в ожида-

нии выполнения некоторого условия, как мы описывали в главе 1.

Рассуждая логически, блокировка в удаленных объектах

—

дело несложное.

Предположим, что клиент А вызвал синхронизируемый метод удаленного объек-

та. Чтобы получить доступ к удаленному объекту, который всегда выглядит так

же,

как локальный, необходимо блокировать А на уровне клиентской заглушки,

которая реализует интерфейс объекта и к которой А имеет прямой доступ. Точно

так же и другой клиент на другой машине должен быть блокирован до пересылки

запроса на сервер. Это означает, что нам необходимо блокировать разных клиен-

тов на различных машинах. Как мы увидим в главе 5, распределенная синхрони-

зация может оказаться довольно сложным делом.

Альтернативный подход состоит в том, чтобы производить блокировку толь-

ко на сервере. В принципе это неплохо работает, но возникают проблемы с нару-

шениями работы клиентов в момент обработки сервером их обращений. Как мы

увидим в главе 7, обработка подобных ситуаций требует достаточно хитроумно-

го протокола и способна значительно снизить общую производительность обра-

щений к удаленным методам.

Поэтому разработчики Java RMI ограничили блокировку удаленных объек-

тов блокировкой заместителей

[494].

На практике это означает, что просто путем

124 Глава 2. Связь

использования синхронизированных методов удаленные объекты невозможно

защитить от одновременного доступа процессов, работающих через разные за-

местители. Вместо этого следует использовать явные методы распределенной

блокировки.

Обращение к удаленным объектам в Java

Поскольку разница между локальными и удаленными объектами на уровне язы-

ка слабо заметна, Java может в ходе обращений к удаленным методам скрывать

большую часть различий между ними. Так, в ходе обращения RMI в качестве па-

раметра может быть передан любой простой или объектный тип, что предполага-

ет возможность маршалинга типов. В терминологии Java это означает, что типы

сериализуемы

(serializable).

Хотя в принципе сериализации можно подвергнуть

большинство объектов, она не всегда является допустимой или возможной.

Обычно зависящие от платформы объекты, такие как дескрипторы файлов или

сокеты, не сериализуются.

Единственное различие между локальными и удаленными объектами, наблю-

даемое в процессе RMI, состоит в том, что локальные объекты передаются по

значению (включая большие объекты, такие как массивы), в то время как удален-

ные объекты передаются по ссылке. Другими словами, локальные объекты копи-

руются, после чего копия используется в качестве параметра-значения. В случае

удаленных объектов в качестве параметра используется ссылка на объект, без

всякого копирования, как показано на рис. 2.17.

При обращении RMI

Java ссылка на удаленный объект реализуется именно

так, как мы говорили в пункте 2.3.2. Эта ссылка содержит сетевой адрес и конеч-

ную точку сервера, а также локальный идентификатор необходимого объекта

в адресном пространстве сервера. Как мы обсуждали, в ссылке на удаленный объ-

ект, кроме того, кодируется стек протоколов, используемых клиентом и серве-

ром для взаимодействия. Чтобы понять, как при обращении RMI в Java кодиру-

ется стек протоколов, необходимо учитывать, что каждый объект Java представ-

ляет собой экземпляр класса. Класс же, в свою очередь, содержит реализацию

одного или более интерфейсов.

В сущности, удаленный объект построен из двух различных классов. Один из

классов содержит реализацию кода сервера и называется

классом

сервера.

Класс

сервера содержит реализацию той части удаленного объекта, которая выполня-

ется на сервере. Другими словами, она содержит описание состояния (данных)

объекта, а также реализацию методов обработки этого состояния. Из специфика-

ции интерфейса объекта генерируется серверная заглушка, то есть скелетон.

Другой класс содержит реализацию кода клиента и называется

классом

клиен-

та. Класс клиента содержит реализацию заместителя. Как и скелетон, этот класс

также автоматически создается из спецификации интерфейса объекта. В своей

простейшей форме заместитель делает только одну вещь

—

превращает каждый

вызов метода в сообщение, пересылаемое реализации удаленного объекта, нахо-

дящейся на сервере, а каждое ответное сообщение

—

в результат вызова метода.

При каждом вызове он устанавливает связь с сервером, разрывая ее после завер-

2.3.

Обращение к удаленным объектам 125

шения вызова. Для этого, как уже говорилось, заместитель нуждается в сетевом

адресе и конечной точке сервера.

Таким образом, заместитель обладает всей информацией, необходимой для

обращения клиента к методу удаленного объекта. В Java заместители сериали-

зуются. Другими словами, заместитель можно подвергнуть маршалингу и пере-

слать в виде набора байтов другому процессу, в котором он может быть подвергнут

обратной операции (демаршалингу) и использован для обращения к методам

удаленного объекта. Косвенным результатом этого является тот факт, что замес-

титель может быть использован в качестве ссылки на удаленный объект.

Этот подход согласуется с методами интеграции локальных и распределен-

ных приложений в Java. Напомним, что при обращении RMI локальный объект

передается путем создания копии, а удаленный

—

через общесистемную ссылку

на объект. Заместитель представляет собой просто-напросто локальный объект.

Это означает, что сериализуемый заместитель можно передавать по сети как па-

раметр RMI. В результате появляется возможность использовать заместитель как

ссылку на удаленный объект.

В принципе nppi маршалинге заместР1теля вся его реализация, то есть его со-

стояние и код, превращаются в последовательность байтов. Маршалинг подоб-

ного кода не слишком эффектршен и может привести к слишком объемным

ссылкам. Поэтому при маршалинге заместителя

Java на самом деле происходит

генерация дескриптора реализации, точно определяющего, какие классы необхо-

димы для создания заместителя. Возможно, некоторые из этих классов придется

сперва загрузить из удаленного узла. Дескриптор реализации в качестве части

ссылки на удаленный объект заменяет передаваемый при маршалинге код. В ре-

зультате ссылки на удаленные объекты

Java имеют размер порядка нескольких

сотен байт.

Такой подход к ссылкам на удаленные объекты отличается высокой гиб-

костью и представляет собой одну из отличительных особенностей RMI в Java

[482].

В частности, это позволяет оптимизировать решение под конкретный объ-

ект. Так, рассмотрим удаленный объект, состояние которого изменяется только

один раз. Мы можем превратить этот объект в настоящий распределенный объ-

ект путем копирования в процессе привязки всего его состояния на клиентскую

машину. Каждый раз nppi обращении клиента к методу он работает с локальной

копией. Чтобы гарантировать согласованность данных, каждое обращение про-

веряет, не изменилось ли состояние объекта на сервере, и при необходимости об-

новляет локальную копию. Таким же образом методы, изменяющие состояние

объекта, передаются на сервер. Разработчик удаленного объекта должен разрабо-

тать только код, необходимый для клиента, и сделать его динамически подгру-

жаемым при присоединении клиента к объекту.

Возможность передавать заместителя в виде параметра существует только

в том случае, если все процессы работают под управлением одной и той же вир-

туальнор! машины. Другими словами, каждый процесс работает в одной и той же

среде исполнения. Переданный при маршалинге заместитель просто подвергает-

ся демаршалингу на приемной стороне, после чего полученный код заместителя

можно выполнять. В противоположность этому в DCE, например, передача за-

126 Глава 2. Связь

глушек невозможна, поскольку разные процессы могут запускаться в разных

средах исполнения, отличающртхся языком программирования, операционной

системой и аппаратным обеспечением. Вместо этого в DCE производится компо-

новка (динамическая) с локальной заглушкой, скомпилированной в расчете на

среду исполнения конкретного процесса. Путем передачи ссылки на заглушку

в виде параметра RPC достигается возможность выхода за границы процесса.

2.4. Связь посредством сообщений

Вызовы удаленных процедур и обращения к удаленным об7:.ектам способствуют

сокрытию взаимодействия в распределенных системах, то есть повышают про-

зрачность доступа. К сожалению, ни один из этих механизмов не идеален.

част-

ности, в условиях, когда нет уверенности в том, что принр1мающая сторона в мо-

мент выполнения запроса работает, приходится искать альтернативные пути

обмена. Кроме того, сршхронную по определению природу RPC и RMI, при кото-

рой на время осуществления операции необходимо блокировать клиента, време-

нами тоже хочется заменить чем-то другим.

Это «что-то другое»

—

обмен сообщениями. В этом разделе мы сосредото-

чимся на использованрп! в распределенных системах взаимодействия на основе

сообщений. Сначала мы кратко рассмотрим, что такое чисто синхронное поведе-

ние и каковы его области применения. Затем обсудим системы обмена сообще-

ниями, позволяющие сторонам в процессе взаимодействия продолжать работу.

И наконец, исследуем системы очередей сообщений, позволяющие процессам

обмениваться информацией, даже если вторая сторона в момент начала связи не

работает.

2.4.1.

Сохранность и синхронность

во взаимодействиях

Чтобы разобраться во множестве альтернатив в коммуникационных системах,

работающих на основе сообщений, предположим, что система организована по

принципу компьютерной сети, как показано на рис. 2.19. Приложения всегда вы-

полняются на хостах, а каждый хост предоставляет интерфейс с коммуникацион-

ной системой, через который сообщения могут передаваться. Хосты соединены

сетью коммуникационных серверов, которые отвечают за передачу (или маршру-

тизацию) сообщения между хостами. Без потери общности можно предположить,

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

В главе

мы предполагали, что буферы могут быть размещены исключительно на

хостах. Для более общего варианта нам следует рассмотреть варианты с размеп^е-

нием буферов и на коммуникационных серверах базовой сети.

В качестве примера рассмотрим разработанную в подобном стиле систему

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

—

это пользо-

вательские приложения, которые могут создавать, посылать, принимать и читать

сообщения. Каждый хост соединяется только с одним почтовым сервером, кото-

2.4.

Связь посредством сообщений 127

рый является по отношению к нему коммуникационным сервером. Интерфейс

пользовательского хоста разрешает пользовательскому агенту посылать сообще-

ния по конкретным адресам. Когда пользовательский агент представляет сооб-

щение для передачи на хост, хост обычно пересылает это сообщение на свой ло-

кальный почтовый сервер, в выходном буфере которого оно хранится до поры до

времени.

Интерфейс сообщений

Передающий \ Коммуникационный

сервер

Коммуникационный

сервер

Передающий

хост

^ Локальная сеть

Локальный I

буфер

Входящее сообщение

Локальный

буфер

Рис. 2.19. Обобщенная организация коммуникационной системы,

хосты которой соединяются через сеть

Почтовый сервер удаляет сообщение из своего выходного буфера и ищет, ку-

да его нужно доставить. Поиски места назначения приводят к получению адреса

(транспортного уровня) почтового сервера, для которого предназначено сообще-

ние.

Затем почтовый сервер устанавливает соединение и передает сообщение на

другой, выбранный почтовый сервер. Последний сохраняет сообщение во входя-

щем буфере намеченного получателя, также называемом почтовым ящиком по-

лучателя. Если искомый почтовый ящик временно недоступен, например, отклю-

чен, то хранить сообщение продолжает локальный почтовый сервер.

Интерфейс принимающего хоста предоставляет пользовательским агентам

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

шей почты. Пользовательский агент может работать напрямую с почтовым ящи-

ком пользователя на локальном почтовом сервере или копировать новые со-

общения в локальный буфер своего хоста. Таким образом, сообщения обычно

хранятся на коммуникационных серверах, но иногда и на принимающем хосте.

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

—

это типичный пример

сохранной

связи (persis-

tent

communication).

При сохранной связи сообщение, предназначенное для от-

сылки, хранится в коммуникационной системе до тех пор, пока его не удастся

передать получателю. Если отталкиваться от рисунка, можно сказать, сообщение

сохраняется на коммуникационном сервере до тех пор, пока его не удастся пере-

дать на следующий коммуникационный сервер. Поэтому у отправляющего сооб-

щение приложения нет необходимости после отправки сообщения продолжать

128

Глава 2. Связь

работу. Аналогично, у приложения, принимающего сообщения, также нет необ-

ходимости находиться в рабочем состоянии во время отправки сообщения.

Система сохранной связи сравнима по принципу работы с почтовой системой

Pony Express (рис. 2.20). Отправка письма начинается с доставки его в местное

почтовое отделение. Почтовое отделение отвечает за сортировку почты в зависи-

мости от того, в какое следующее почтовое отделение на пути к конечному пунк-

ту доставки ее нужно отправить. В нем также хранят соответствующие сумки

с почтой, отсортированной по месту назначения,

ждут появления лошади со

своим всадником. В пункте назначения письма вновь сортируются в зависимо-

сти от того, заберут ли их адресаты прямо здесь или нужно передать эти письма

следующему почтальону. Отметим, что письма никогда не теряются и не пропа-

дают. Несмотря на то что средства доставки, так же как и средства сортировки

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

и пересылки почты остались неизменными.

Лошадь и всадник

Почтовое

отделение

Почтовое

отделение

Почтовое

отделение

r'"•^

^:4

Почтовое г

отделениеL

Почта хранится и сортируется

в соответствии с пунктом

назначения, чтобы отправиться в путь,

когда появятся свободные лошадь и всадник

Рис. 2.20. Сохранная связь — доставка писем во времена Pony Express

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

нерезиде71тной

связи (transient

communication)

сообщение хранится в системе только в течение времени работы

приложений, которые отправляют и принимают это сообщение. Точнее говоря

(если опять отталкиваться от рис. 2.20), мы имеем дело с такой ситуацией, когда

коммуникационный сервер, не имея возможности передать сообщение следую-

щему серверу или получателю, просто уничтожает его. Обычно все коммуника-

ционные службы транспортного уровня поддерживают только нерезидентную

связь. В этом случае коммуникационный сервер соответствует традиционному

маршрутизатору «получил

—

передал». Если маршрутизатор не в состоянии пе-

реслать сообщение следующему маршрутизатору или принимающему хосту, со-

общение просто теряется.

Помимо сохранной и нерезидентной связи существует деление на синхрон-

ную и асинхронную связь. Характерной чертой

асинхронной

связи (asynchronous

communication)

является немедленное после отправки письма продолжение работы

отправителя. Это означает, что письмо сохраняется в локальном буфере пере-

дающего хоста или на ближайшем коммуникационном сервере. В случае

синхрон-

ной связи

(synchronous communication)

отправитель блокируется до того момента.

2.4.

Связь посредством сообщений 129

пока его сообщение не будет сохранено в локальном буфере принимающего хос-

та или доставлено реальному получателю. Наиболее жесткая форма синхронно-

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

время обработки его сообщения получателем.

На практике применяются различные комбинации этих типов взаимодейст-

вия. В случае сохранной асинхронной связи сообщение сохраняется в буфере ли-

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

обычно используется в системах электронной почты. В случае сохранной син-

хронной связи сообщения хранятся только на принимающем хосте. Отправитель

блокируется до момента сохранения сообщения в буфере получателя. Отметим,

что приложение, принявшее сообщение, не обязано сохранять его на своем ло-

кальном хосте. «Усеченный» вариант сохранной синхронной связи состоит в том,

что отправитель блокируется до момента сохранения сообщения на коммуника-

ционном сервере, соединенном с принимающим хостом.

Нерезидентная асинхронная связь характерна для служб дейтаграмм транс-

портного уровня, таких как UDP. Когда приложение отправляет сообщение, оно

временно сохраняется в локальном буфере передающего хоста, после чего отпра-

витель немедленно продолжает работу. Параллельно коммуникационная систе-

ма направляет сообщение в точку, из которой, как ожидается, оно сможет дос-

тигнуть места назначения, возможно, с сохранением в локальном буфере. Если

получатель в момент прихода сообщения на принимающий хост этого получате-

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

связи

—

асинхронный вызов RPC.

Нерезидентная синхронная связь существует в различных вариантах. В наи-

более слабой форме, основанной на подтверждениях приема сообщений, отпра-

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

принимающего хоста. После получения подтверждения отправитель продолжает

свою работу. В ориентированной на доставку нерезидентной синхронной связи

отправитель блокируется до тех пор, пока сообщение не будет доставлено полу-

чателю для дальнейшей обработки. Мы рассматривали эту форму синхронного

поведения при обсуждении асинхронных вызовов RPC. При асинхронных вызо-

вах RFC клиент синхронР13ируется с сервером, ожидая, пока его запрос будет

принят на дальнейшую обработку. Наиболее жесткая форма

—

ориентированная

на ответ нерезидентная синхронная связь

—

предполагает блокировку отправи-

теля до получения ответного сообщения с другой стороны, как в поведении за-

прос-ответ при взаимодействии клиент-сервер. Эта схема характерна также для

механизмов RFC и RMI.

Все сочетания сохранности и синхронности при взаимодействиях показаны

на рис. 2.21. Другая, но схожая классификация обсуждается в

[445].

До недавнего времени множество распределенных систем поддерживали

только ориентированную на ответ нерезидентную синхронную связь, реализо-

ванную через вызов удаленных процедур или через обращения к удаленным объек-

там. После того как стало ясно, что этот вид связи не всегда самый подходящий,

были созданы средства для менее жестких форм нерезидентной синхронной свя-

зи,

таких как асинхронные вызовы RFC (см. рис. 2.13) или отложенные синхрон-

ные операции.

130

Глава 2. Связь

А отправляет

сообщение

и продолжает работу

А завершает

работу

В не работает

А отправляет сообщение

и ожидает, пока оно

не будет получено

А завершает работу

Сообщение сохраняется

по месту работы В

Время для его последующей

• передачи „

В стартует

и получает

сообщение

В не работает

Время

В стартует

и получает

сообщение

А отправляет

сообщение

и продолжает работу

Отправка запроса

и ожидание его получения

Сообщение может

быть отправлено только

в случае, если В работает

Время

в получает сообщение

Запрос

получен

Работает, но делает Обработка

что-то иное запроса

Отправка запроса и ожидание

извещения о его получении

Запрос

получен

Извещение

о получении ^^^^^

Работает, но делает Обработка

что-то иное запроса

Отправка запроса

и ожидание ответа

Запрос

получен

Работает, но делает Обработка

что-то иное запроса

Извещение

о получении

Время

а е

Рис. 2.21. Шесть видов связи: сохранная асинхронная связь (а), сохранная синхронная

связь (б), нерезидентная асинхронная связь (в), нерезидентная синхронная связь

с синхронизацией по приему (г), нерезидентная синхронная связь

с синхронизацией по доставке {д) и нерезидентная синхронная

связь с синхронизацией по ответу (е)

В корне отличный подход применен в системах передачи сообщений, исполь-

зующих как отправную точку нерезидентную асинхронную связь и в качестве

дополнительной возможности содержащих средства синхронной связи. Однако

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

прозрачными. Другими словами, задействуются только те средства связи, кото-