Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Inf_comp_sys

.pdf
Скачиваний:
10
Добавлен:
21.03.2016
Размер:
3.33 Mб
Скачать

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

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

16.7.8 Избирательный потребитель

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

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

56).

Поставщик,

Сообщения со значениями

задающий

выбора

значение выбора

 

Диаграмма 56

Избирательный

потребитель

Получатель

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

сообщения перед его отправкой.

191

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

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

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

16.7.9 Постоянный подписчик

Если подписчик временно отключен от канала «публикация-подписка», он не получит сообщение. Подписка на канал действительна только до закрытия соединения.

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

Постоянный

подписчик

Получатель

Издатель

 

Канал

 

«публикация-

Временный

подписка»

подписчик

 

 

Получатель

Диаграмма 57

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

192

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

16.7.10 Активатор службы

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

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

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

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

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

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

193

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

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

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

194

Список литературы

1. Браун К., Крейг Г, Хестер Г., Стайнаур Р., Питт В. Д., Витцел М., Амсден Дж., Джекоб П. М., Берг Д. Вельшенбах М. Создание корпоративных Java-приложений для IBM WebSphere / Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2005.

ХХ, 860 с.

2.Грегор Хоп, Бобби Вульф «Шаблоны интеграции корпоративных приложений»: Пер. с англ. – М.: ООО «И.Д. Вильямс», 2007 г.

3.Перроун, Пол, Дж., Чаганти, Венката, С.Р. «Кришна» Р. Создание корпоративных систем на основе Java 2 Enterprise Edition. Руководство разработчика.: Пер. с англ. – М.: Издательский дом «Вильямс», 2001

4.Фаулер М. Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом "Вильямс", 2007.

5.Эндрю Троелсен. Язык программирования C# 2010 и платформа .NET 4.0. / Издательство: Вильямс, 2010 г., 1392 с.

195

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]