Inf_comp_sys

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

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

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

Несмотря на все вышесказанное, необходимо передавать данные, используя обмен сообщениями. Последний более надежен, чем удаленный вызов процедуры. Можно воспользоваться каналом «точка-точка», чтобы гарантировать потребление данных только одним получателем (без дублирования), или каналом "публикация-подписка", если необходимо, чтобы копию данных получила каждая заинтересованная сторона.

Для надежной передачи структуры данных между приложениями необходимо использовать сообщение с данными (Диаграмма 23).

D - документ

Диаграмма 23

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

141

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

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

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

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

16.4.3 Сообщение о событии

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

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

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

142

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

Сообщение о событии может быть сообщением любого типа из числа тех, которые поддерживаются системой обмена сообщениями (Диаграмма 24).

Е

Наблюдатель

Диаграмма 24

Разница между сообщением о событии и сообщением с данными документа определяется своевременностью доставки и содержимым. Содержимое сообщения о событии обычно не играет особой роли. Довольно часто тело таких сообщений пустое; наблюдатель реагирует на сам факт получения сообщения. Более важна своевременность доставки. Субъект должен разослать оповещения, как только произойдет событие, а наблюдатель должен успеть обработать его, пока оно еще не потеряло своей актуальности. События случаются довольно часто и требуют немедленной доставки оповещений о себе другим приложениям, а значит, использование гарантированной доставки не оправдано. Эффективнее указать срок действия сообщения. Он гарантирует, что событие будет обработано вовремя или же не обработано вообще.

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

143

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

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

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

Модель вытягивания. Для оповещения применяется набор из трех сообщений:

обновление, т.е. сообщение о событии, которое уведомляет наблюдателя о некотором событии;

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

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

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

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

144

16.4.4 Запрос-ответ

Обмен сообщениями предусматривает одностороннее взаимодействие участвующих в нем приложений. Сообщения "перемещается" по каналу сообщений в одном направлении: от отправителя к получателю. Такая асинхронная передача сообщений повышает надежность доставки и отделяет отправителя от получателя.

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

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

Отправитель может хранить ссылку на сообщение. Затем, как только получатель помещает в сообщение свой ответ, отправитель может "вытянуть" сообщение обратно. Однако, канал передает сообщения только в одном направлении. Поэтому требуется двусторонний обмен сообщениями по двунаправленному каналу.

В схеме запрос-ответ присутствуют два участника (Диаграмма 25).

1.Инициатор запроса отправляет сообщение с запросом и ждет, когда придет сообщение с ответом.

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

Запрос Канал запросов

Диаграмма 25

Канал запросов может быть каналом "точка-точка", либо каналом "публикация-подписка". Выбор того или иного типа канала зависит от того, кем должен быть обработан запрос: всеми заинтересованными участниками или же только одним получателем. Канал ответов, в свою очередь, почти всегда

145

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

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

кполучению ответа.

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

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

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

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

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

3.Уведомление/подтверждение. Этот сценарий описывает уведомление о событии с последующим подтверждением того, что уведомление было получено. Запрос — сообщение о событии, посредством которого выполняется уведомление, а ответ — сообщение с данными документа, подтверждающее получение уведомления. Последнее, в свою очередь, тоже может быть запросом (если заинтересованный наблюдатель хочет получить больше сведений о событии).

146

Запрос аналогичен вызову метода. Из этого следует, что ответ на запрос может принимать одну из трех форм.

•Пустой ответ. Сообщение с ответом просто уведомляет вызывающее приложение о том, что выполнение метода завершено, и вызывающее приложение может работать дальше.

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

•Исключение. Объект исключения, указывающий на то, что вызываемый метод аварийно завершил свою работу до успешного окончания его выполнения, а также на причины такого поведения.

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

16.4.5 Обратный адрес

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

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

Канал ответов 1

Инициатор запроса 2

Канал ответов 2

Ответчик

Диаграмма 26

147

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

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

В сообщении с запросом должен содержаться обратный адрес, указывающий куда необходимо отправить сообщение с ответом (Диаграмма 27).

Благодаря наличию обратного адреса ответчик не должен заранее знать, куда необходимо отправить ответ; он просто получит адрес канала ответов из сообщения с запросом. Если ответы на разные сообщения необходимо отсылать в разные каналы, ответчик из каждого отдельно взятого сообщения с запросом сможет определить, куда нужно отсылать соответствующий ответ. Таким образом, знание того, какие каналы необходимо использовать для отправки запросов и ответов, будет инкапсулировано в инициаторе запросов. Фиксировать их в исходном коде ответчика не придется. Обратный адрес не является частью данных, передаваемых приложением, а следовательно, должен быть вынесен в заголовок сообщения.

148

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

16.4.6 Идентификатор корреляции

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

Запросы

???

Диаграмма 28

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

149

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

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

Всообщении с ответом должен содержаться уникальный идентификатор корреляции, который показывает, к какому запросу относится данный ответ (Диаграмма 29).

Идентификатор

сообщения

Запросы

Диаграмма 29

В схеме "запрос-ответ", изображенной на диаграмме 29 задействованы шесть участников.

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

Ответчик. Другое приложение, которое получает запрос, обрабатывает его и высылает ответ. При этом оно извлекает из запроса его идентификатор и помещает его в ответ в качестве идентификатора корреляции.

Запрос. Сообщение отправленное инициатором запроса ответчику и содержащее идентификатор запроса.

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

Идентификатор запроса. Маркер в сообщении с запросом, который уникальным образом идентифицирует запрос.

Идентификатор корреляции. Маркер в сообщении с ответом, значение которого совпадает со значением идентификатора запроса.

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

150