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

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

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

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

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

Подобная семантика определяет слабосвязанное взаимодействие. Именно по­этому у получателя нет необходимости быть активным в то время, когда сообще­ние пересылается в его очередь. Точно так же нет нужды и в активности отпра­вителя во время обработки сообщения получателем. Отправитель и получатель могут выполняться абсолютно независимо друг от друга. На самом деле, как толь­ко сообщение поставлено в очередь, оно будет оставаться в ней до удаления, независимо от того, активен его отправитель или его получатель. Это, в зависи­мости от состояния отправителя и получателя, дает нам четыре комбинации, по­казанные на рис. 2.23.

 

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

 

 

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

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

 

 

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

Примитив put вызывается отправителем для передачи сообщения базовой системе, где оно будет помещено в соответствующую очередь. Как мы объясняли, это неблокирующий вызов. Примитив get — это блокирующий вызов, посредст­вом которого авторизованный процесс может извлечь самое старое сообщение из определенной очереди. Процесс блокируется только в том случае, если очередь пуста. Варианты этого вызова включают в себя поиск в очереди определенного сообщения, например, с использованием приоритетов или образца для сравне­ния. Неблокирующий вариант представлен примитивом poll. Если очередь пус­та или искомое сообщение не найдено, вызвавший этот примитив процесс про­должает свою работу.

И, наконец, большинство систем очередей сообщений поддерживают также процесс вставки дескриптора функции обратного вызова {callback function), кото­рая автоматически вызывается при попадании сообщения в очередь. Обратные вызовы могут быть также использованы для автоматического запуска процесса, который будет забирать сообщения из очереди, если ни один процесс в настоя­щее время не запущен. Подобное поведение обычно реализуется при помощи де­мона на стороне получателя, который постоянно проверяет очередь на наличие входящих сообщений и поступает в соответствии с результатами проверки.

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

Давайте теперь рассмотрим поближе, как выглядит обобщенная система очере­дей сообщений. Одно из первых ограничений, которые мы сделаем, будет состо­ять в том, что сообщения могут быть помещены только в локальные очереди отправителя, то есть в очереди, находящиеся на той же самой машине или, во всяком случае, не дальше, чем на соседней, то есть машине, входящей в ту же ло­кальную сеть. Подобная очередь называется исходящей очередью {source queue). Аналогично, прочитаные сообщения могут быть только из локальных очередей. Сообщение, помещенное в очередь, содержит описание очереди назначения {des­tination queue), в которую оно должно быть перемещено. В обязанности системы очередей сообщений входит предоставление очередей отправителям и получате­лям и обеспечение перемещения сообщений из исходящих очередей в очереди назначения.

Важно понимать, что набор очередей разнесен по множеству машин. Соответст­венно, для того чтобы система очередей сообщений могла перемещать сообщения, она должна поддерживать отображение очередей на сетевые адреса. На практике это означает, что она должна поддерживать базу данных (возможно, распреде­ленную) имен очередей {queue names) в соответствии с их сетевым местоположе­нием, как показано на рис. 2.24. Отметим, что это отображение полностью анало-

 

 

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

гично использованию системы доменных имен (DNS) для электронной почты Интернета. Так, например, для отсылки почты на логический почтовый адрес [e-mail] почтовая система запрашивает у DNS сетевой адрес (то есть IP-адрес) почтового сервера получателя, чтобы затем использовать его для переда­чи сообщений.

Очереди управляются менеджерами очередей (queue managers). Обычно ме­неджер очередей взаимодействует непосредственно с отправляющими и прини­мающими сообщения приложениями. Существуют, однако, и специализированные менеджеры очередей, которые работают как маршрутизаторы, или ретранслято­ры: они перенаправляют приходящие сообщения другим менеджерам очередей. Таким образом, система очередей сообщений может постепенно вырасти до за­конченной оверлейной сети (overlay network) прикладного уровня поверх сущест­вующей компьютерной сети. Этот подход схож с ранней конструкцией системы МВоnе поверх Интернета, в которой обычные пользовательские процессы кон­фигурировались для маршрутизации групповых рассылок. В наши дни многие маршрутизаторы сами поддерживают групповые рассылки и необходимость в оверлейных групповых рассылках сильно сократилась.

Ретрансляторы могут быть удобны по нескольким причинам. Так, во многих системах очередей сообщений не существует общих служб именования, которые могли бы динамически поддерживать отображение имен на адреса. Вместо этого топология сети с очередями сделана статической, а каждый менеджер очередей имеет копию отображения очередей на адреса. Нельзя не сказать, что в крупно­масштабных системах очередей сообщений подобный подход легко может при­вести к трудностям в управлении сетью.

Одним из решений этой проблемы является использование нескольких мар­шрутизаторов, имеющих информацию о топологии сети. Когда отправитель А по­мещает в локальную очередь сообщение для получателя В, это сообщение первым делом передается на ближайший маршрутизатор R1, как показано на рис. 2.25. При этом маршрутизатор знает, что делать с этим сообщением, и передает его в направлении В. Так, R1 может понять по имени В, что сообщение следует пере­дать на маршрутизатор R2. Таким образом, при добавлении или удалении очере-

 

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

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

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

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

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

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

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