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

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

2.4.

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

рые подходят для синхронных процессов. Ограничиваться исключительно эти-

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

ние географическую масштабируемость.

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

чикам программного обеспечения промежуточного уровня потребовалось интег-

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

Подобные сети часто разбросаны по различным подразделениям и администра-

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

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

Для решения подобных проблем были разработаны частные решения на базе со-

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

ли требованиям переносимости и работоспособности в разных условиях.

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

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

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

случае означает нарушение прозрачности по отказам. В случае же сохранной свя-

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

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

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

и восстановления.

Должно быть понятно, что выбор исключительно между нерезидентным и со-

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

хронный и асинхронный типы связи

—

это еще не все. В зависимости от задач

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

нее мы говорили в основном о нерезидентной синхронной связи

—

RPC и RMI.

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

щими на основе передачи сообщений. Эти системы мы обсудим в следующих

пунктах. Мы проясним разницу между нерезидентной и сохранной связью.

2.4.2.

Нерезидентная связь на основе сообщений

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

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

уровнем. Чтобы лучше понять и оценить системы, ориентированные на сообще-

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

ниями через сокеты транспортного уровня.

Сокеты Беркли

Для стандартизации интерфейса транспортного уровня предпринимались специ-

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

зовать полный комплект протоколов обмена сообщениями как простой набор

примитивов. Кроме того, стандартные интерфейсы упрощают перенос приложе-

ний на другие машины.

В качестве примера мы кратко рассмотрим интерфейс

сокетов,

введенный

версии UNIX, разработанной в универсргтете Беркли (Berkeley UNIX). Другой

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

важный интерфейс, XTI, прртсутствуюищй в транспортном интерфейсе Х/Ореп,

который официально именуется

интерфейсом транспортного

уровня

{Transport

Layer

Interface,

ТЫ), разработан организацией AT&T. Сокеты и XTI хорошо под-

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

митивов.

Концептуально сокет (socket) — это конечная точка коммуникации. В эту

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

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

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

ботает с локальной операционной системой по некоторому транспортному про-

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

в табл. 2.1.

Таблица 2.1. Примитивы сокетов для TCP/IP

Примитив Назначение

Socket Создать новую конечную точку коммуникации

В1

nd Назначить сокету локальный адрес

Li sten Обозначить готовность к установке соединения

Accept Заблокировать вызывающую сторону до прибытия запроса о соединении

Connect Совершить попытку установить соединение

Send Послать через соединение некоторые данные

Rece1

ve Принять из соединения некоторые данные

Close Разорвать соединение

Серверы обычно выполняют первые четыре примитива, чаще всего в приве-

денном в таблице порядке. При вызове примитива socket вызывающий процесс

создает новую конечную точку для некоторого транспортного протокола. Изнут-

ри создание конечной точки коммуникации означает, что локальная операцион-

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

по некоторому протоколу сообщений.

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

ному сокету. Например, сервер должен связать IP-адрес своей машины с номе-

ром порта (возможно, общеизвестным) сокета. Привязка сообщает операцион-

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

и порт.

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

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

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

ства соединений, которое вызывающий процесс намерен поддерживать.

Вызов примитива accept блокирует вызывающий процесс до прихода запроса

на соединение. Когда этот запрос придет, локальная операционная система соз-

даст новый сокет с теми же свойствами, что и у базового, и возвратит его вызы-

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

2.4.

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

цесс,

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

Сервер в это время может вернуться в состояние ожидания следующего запроса

на соединение с базовым сокетом.

Рассмотрим теперь, как все это выглядит со стороны клиента. И здесь все на-

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

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

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

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

уровня, на который будет отправлен запрос на соединение. Клиент блокируется

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

нения стороны начинают обмениваться информацией при помощи примитивов

write и read, предназначенных для посылки и приема данных соответственно.

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

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

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

для коммуникаций, ориентированных на соединение, показана на рис. 2.22. Мно-

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

нием сокетов и других интерфейсов в среде UNIX, можно найти в

[438].

Сервер ^

Точка синхронизации —•; / \

I / Взаимодействие^

I socket I Н connectl—H write"] Н read ]—Н close |

Клиент

Рис. 2.22. Общая схема ориентированного на соединение взаимодействия

с использованием сокетов

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

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

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

средство, которое облегчит им написание высокоэффективных приложений. Это

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

ракции (для облегчения разработки приложений), а их реализация должна вызы-

вать минимум дополнительных накладных расходов. Для сокетов это считается

неосуществимым по двум причинам. Во-первых, их уровень абстракции явно не-

достаточен

—

они поддерживают только простейшие примитивы send и receive.

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

стеков протоколов общего назначения, таких как TCP/IP. Они не подходят для

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

вующих сетей, например таких, которые используются в системе COW или МРР

(мы рассматривали их в разделе 1.3). Эти протоколы требуют интерфейса, обла-

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

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

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

В результате большинство взаимодействующих сетей и мультикомпьютерных

систем оснащалось собственными коммуникационными библиотеками. Эти биб-

лиотеки содержали множество эффективных высокоуровневых коммуникацион-

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

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

с переносимостью.

Требование независимости от аппаратного обеспечения постепенно привело

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

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

{Message-Passing

Interface, MPI). MPI разрабатывался для

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

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

ничего, напоминающего коммуникационные серверы (см. рис. 2.19). Кроме того,

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

или участков сети, фатальны и не могут быть восстановлены автоматически.

MPI предполагает, что связь происходит в пределах известной группы про-

цессов. Каждая группа получает идентификатор. Каждый процесс в группе также

получает идентификатор (локальный). Пара идентификаторов

{groupID,

processID),

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

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

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

мых одновременно.

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

шинство видов нерезидентного взаимодействия, показанных на рис. 2.21

(в-е),

наиболее понятные из них собраны в табл. 2.2.

Таблица 2.2. Некоторые из наиболее понятных примитивов MPI

Примитив Назначение

Поместить исходящее сообщение в локальный буфер отсылки

Послать сообщение и ожидать, пока оно не будет скопировано

в локальный или удаленный буфер

Послать сообщение и ожидать начала его передачи на обработку

Послать сообщение и ожидать ответа

Передать ссылку на исходящее сообщение и продолжить работу

Передать ссылку на исходящее сообщение и ожидать начала

его передачи на обработку

Принять сообщение, блокировать работу в случае его отсутствия

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

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

казанные на рис.

2.21, г.

Другими словами, MPI не поддерживает синхронизацию

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

Нерезидентная асинхронная связь (см. рис.

2.21,

в) поддерживается примити-

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

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

МР1_

MPI

МР1_

MPI

_bsencl

_sencl

ssend

_sendrecv

J send

1ssend

fecv

irecv

2.4.

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

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

няющая система MPI удалит сообщение из буфера и примет меры по его переда-

че получателю сразу же, как только получатель запустит примитив, отвечающий

за прием.

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

MPI_sencl. Ее семантика зависит от реализации. Примитив MPI_send может блоки-

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

му MPI на стороне отправителя, так и до момента инициирования получателем

операции приема. Первый случай соответствует асинхронной связи, показанной

на рис. 2.21, г, второй ~ на рис. 2.21, д.

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

щения на дальнейшую обработку, как показано на рис. 2.21, Э, поддерживается

при помощи примитива MPI_ssencl.

И наконец, наиболее жесткая форма синхронных коммуникаций показана на

рис.

2.21, е. Когда отправитель вызывает примитив MPI_sendrecv, он посылает по-

лучателю сообщерп1е и блокируется до получения ответа. В основе работы этого

примитива лежит обычный механизм RFC.

Примитивы MPI_senci и MPI_ssend имеют варианты, исключающею необходи-

мость копирования сообщения из буфера пользователя во внутренний буфер ло-

кальной исполняющей системы MPI. Эти варианты соответствуют асинхронной

связи. При помощи примитива MR_1send отправитель передает указатель на со-

общение, после чего исполняющая система MPI начинает взаимодействие. От-

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

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

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

MRsend, вопрос о том, нужно ли реально передавать сообщение или достаточно

копирования в локальный буфер исполняющей системы MPI, оставлен на ус-

мотрение разработчиков.

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

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

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

сообщение и в настоящее время работает с ним.

Операция MPI_recv вызывается для приема сообщения и блокирует запустив-

ший процесс до прихода сообщения. Существует также и асинхронный вариант

этой операции под именем MPI_1recv, вызовом которого получатель показывает,

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

шедшие сообщения, или заблокироваться в ожидании таковых.

Семантика коммуникационных примитивов MPI не всегда проста, и иногда

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

Официальная причина поддержки такого разнообразия вариантов взаимодейст-

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

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

всегда, не нашел в себе сил хорошенько подумать. Интерфейс MPI был разрабо-

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

нимание причин подобного разнообразия коммуникационных примитивов.

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

Множество сведений по MPI содержится в

[185].

Полное руководство, в ко-

тором детально разобрано более 100 функций MPI, можно найти в [184, 425].

2.4.3. Сохранная связь на основе сообщений

Ну вот мы и подошли к важному классу ориентированных на сообщения служб

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

системы

очередей

сообщепий

(message-

queuing systems), или ориеитированиый па сообщения

промежуточный

уровень

{Message-Onented

Middleware,

MOM). Системы очередей сообщений создают рас-

ширенную поддержку асинхронной сохранной связи. Смысл этих систем заклю-

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

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

ни от получателя. Их существенное отличие от сокетов Беркли и интерфейса

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

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

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

ний, а закончим этот пункт сравнением их с традиционными системами, под ко-

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

Модель очередей сообщений

Основная идея, лежащая в основе систем очередей сообщений, состоит в том, что

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

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

и в конце концов достигают места назначения, даже в том случае, если получа-

тель в момент отправки сообщения был неактивен. На практике большинство

коммуникационных серверов напрямую соединены друг с другом. Другими сло-

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

В принципе каждое приложение имеет собственную очередь, в которую могут по-

сылать сообщения другие приложения. Очередь может быть прочитана только

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

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

Важный момент в системах очередей сообщений СОСТОРГТ В ТОМ, ЧТО отправи-

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

—

рано или

поздно

—

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

сообщение действительно прочитано, невозможны, это полностью определяется

поведением получателя.

Подобная семантика определяет слабосвязанное взаимодействие. Именно по-

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

ние пересылается в его очередь. Точно так же нет нужды и в активности отпра-

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

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

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

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

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

казанные на рис. 2.23.

2.4.

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

Отправитель

активен

Отправитель

активен

Отправитель

пассивен

Отправитель

пассивен

Получатель

активен

Получатель

активен

Получатель

пассивен

Получатель

пассивен

Рис. 2.23. Четыре комбинации слабосвязанных взаимодействий

с использованием очередей

На рис. 2.23,

как отправитель, так

получатель

ходе всего процесса пере-

дачи сообщения находятся

активном состоянии. На рис. 2.23, б активен только

отправитель,

в то

время

как

получатель отключен,

то

есть находится

состоя-

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

все

же в

состоянии отправлять сообщения. Комбинация

из

активного получате-

ля

пассивного отправителя приведена на рис. 2.23, в. В этом случае получатель

может прочитать сообщения, которые были посланы

ему

ранее, наличия рабо-

тающих отправителей этих сообщегпп! при этом совершенно не требуется.

нако-

нец, на рис. 2.23, г мы наблюдаем такую ситуацию, когда система сохраняет и, воз-

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

Сообщения

принципе могут содержать любые данные. Единственно важ-

ный момент

—

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

На

практике адресация

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

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

очереди,

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

некоторых случаях размер сообще-

ний может быть ограничен, несмотря на то, что, возможно, базовая система

со-

стоянии разбивать большие сообщения

на

части

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

единое

целое абсолютно прозрачно

для

приложений. Эффект подобного подхода —

ВТОМ,

что

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

результате

можно сделать потрясающе простым. Это иллюстрирует табл. 2.3.

Таблица 2.3. Базовый интерфейс очереди в системе очередей сообщений

Примитив Назначение

Put Добавить сообщение

соответствующую очередь

Get Приостановить работу до тех пор, пока

соответствующей очереди

не появятся сообщения, затем извлечь первое сообщение

продолжение^

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

Таблица 2.3

(продолжение)

Примитив Назначение

Pol

Проверить наличие сообщений в соответствующей очереди, затем извлечь

первое из них. Ничего не блокировать

Noti fy Вставить дескриптор функции, которая будет вызвана при помещении

сообщения в соответствующую очередь

Примитив put вызывается отправителем для передачи сообщения базовой

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

это неблокирующий вызов. Примитив get

—

это блокирующий вызов, посредст-

вом которого авторизованный процесс может извлечь самое старое сообщение из

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

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

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

ния. Неблокирующий вариант представлен примитивом poll. Если очередь пус-

та или искомое сообщение не найдено, вызвавший этот примитив процесс про-

должает свою работу.

И, наконец, большинство систем очередей сообщений поддерживают также

процесс вставки дескриптора функции

обрат?1ого

вызова (callback function), кото-

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

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

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

щее время не запущен. Подобное поведение обычно реализуется при помощи де-

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

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

Общая архитектура системы очередей сообщений

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

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

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

отправР1теля, то есть в очереди, находящиеся на той же самой машине или, во

всяком случае, не дальше, чем на соседней, то есть машине, входящей в ту же ло-

кальную сеть. Подобная очередь называется исходящей очередью (source queue).

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

Сообщение, помещенное в очередь, содержит описание очереди пазпачепия (des-

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

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

лям и обеспечение перемещения сообщений из исходящих очередей в очереди

назначения.

Важно понимать, что набор очередей разнесен по множеству машин. Соответст-

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

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

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

ленную) имен очередей (queue names) в соответствии с их сетевым местоположе-

нием, как показано на рис. 2.24. Отметим, что это отображение полностью анало-

2.4.

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

гично использованию системы доменных имен (DNS) для электронной почты

Интернета. Так, например, для отсылки почты на логический почтовый адрес

steen@cs.vu.nl почтовая система запрашивает у DNS

сетевой

адрес (то есть IP-

адрес) почтового сервера получателя, чтобы затем использовать его для переда-

чи сообщений.

Поиск адреса

очереди

на транспортном

уровне

Адрес на уровне

очереди

База данных

поиска адресов

Сеть

Адрес на транспортном

уровне

Рис. 2.24. Отношение между адресацией на уровне очередей и на сетевом уровне

Очереди управляются

менеджерами

очередей (queue

managers).

Обычно ме-

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

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

менеджеры очередей, которые работают как маршрутизаторы, или ретранслято-

ры:

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

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

конченной

оверлейной сети {overlay netxQ)ork)

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

вующей компьютерной сети. Этот подход схож с ранней конструкцией системы

МВопе поверх Интернета, в которой обычные пользовательские процессы кон-

фигурировались для маршрутизации групповых рассылок. В наши дни многие

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

оверлейных групповых рассылках сильно сократилась.

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

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

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

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

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

масштабных системах очередей сообщений подобный подход легко может при-

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

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

шрутизаторов, имеющих информацию о топологии сети. Когда отправитель Л по-

мещает в локальную очередь сообщение для получателя В, это сообщение первым

делом передается на ближайший маршрутизатор R1, как показано на рис. 2.25.

При этом маршрутизатор знает, что делать с этим сообщением, и передает его

в направлении В. Так, R1 может понять по имени 5, что сообщение следует пере-

дать на маршрутизатор R2. Таким образом, при добавлении или удалении очере-

140

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

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

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

жение ближайшего маршрутизатора.

Отправитель А

Маршрутизатор

Рис. 2.25. Обобщенная организация систем очередей сообщений с маршрутизаторами

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

систем очередей сообщений. Однако по мере роста сети очередей сообщений

становится ясно, что ручное конфигурирование этой сети скоро станет невоз-

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

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

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

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

Другой причиной использования ретрансляторов является их способность

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

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

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

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

получателя вид.

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

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

очередей.

Брокеры сообщений

Важнейшей областью применения систем очередей сообщений является интег-

рация существующих и новых приложений в единые согласованные распре-

деленные информационные системы. Интеграция требует, чтобы приложения

понимали сообщения, которые они получают. На практике это означает, что от-