1. УК 03.011.01-2011
Учебный курс. Обучение.
Паттерны обмена сообщениями.

2. Основные компоненты
•
•
•
•
•
•
Каналы
Сообщения
Фильтры
Маршрутизация
Преобразование
Конечные точки

3. Сообщение
• Как организовать обмен данными между приложениями?
• Сообщение – атомарная единица переданной
информации.
Сообщение содержит:
• Заголовок сообщения.
Служебная
информация,
используемая
сообщениями (СОС). Например, адрес
получателя.
• Тело сообщения.
Данные, передаваемые с помощью СОС.
системой
обмена
отправителя, адрес

4. Канал сообщений
• Как передать сообщения от одного приложения к
другому?
• Соединить приложения с помощью канала сообщений.
Канал доставляет помещенные в него сообщения от
отправителя к получателю.

5. Фильтры сообщений
• Как сделать приложение гибким и независимым?
• Надо разделить сложную задачу на последовательность
простых, независимых этапов (фильтров), объединенных с
помощью каналов

7. Способы обработки
• Конвейерная обработка
• Параллельная обработка

8. Маршрутизатор сообщений
• Как передавать сообщения различным фильтрам, в
зависимости от условий?
• Роутер сообщений.
Специальный фильтр, который умеет извлекать сообщение из одного
канала и помещать его в другой канал.

9. Типы маршрутизаторов
• Фиксированный – один входящий и один исходящий
канал
• Маршрутизаторы на основе содержимого
• Маршрутизаторы на основе контекста
Пример, балансировка загрузки
• Динамический маршрутизатор
• Маршрутизаторы с поддержкой состояния
• Маршрутизаторы без поддержки состояния

10. Конечная точка СОС
• Как подключить приложение к системе обмена
сообщениями?
• Конечная точка – клиент СОС, позволяющий приложению
принимать и отправлять сообщения.

11. Результаты
• Учитывает особенности конкретного приложения
• Инкапсулирует СОС

12. Транслятор сообщений
• Приложения используют разные форматы данных. Как
организовать взаимодействие?
• Для преобразования использовать специальный фильтр –
транслятор сообщений

13. Уровни преобразования
Уровень
Объект
Средство
Структуры данных
Сущности, ассоциации
Шаблоны структурного
преобразования
Типы данных
Имя поля, тип данных,
ограничение, значение
поля
Визуальные редакторы,
XSLT, БД
Представление данных
Кодировка, XML, JSON
Анализаторы, API
Транспортный
TCP/IP, HTTP, SOAP, JMS
Адаптер канала

14. КАНАЛЫ ОБМЕНА СООБЩЕНИЯМИ

15. Основные вопросы
• Фиксированный набор каналов
• Определение набора каналов
• Однонаправленные каналы
•
•
•
•
•
•
Отношения “один-к-одному” и “один-ко-многим”
Тип данных
Неверные и недоставленные сообщения
Защита от сбоев
Клиенты, не предназначенные для обмена сообщениями
Коммуникационная магистраль

16. Канал “точка-точка”
• Как гарантировать, что документ или вызов будет получен
только одним приложением?

17. Канал “публикация-подписка”
• Как оповестить о событии всех заинтересованных
получателей?

18. Канал типа данных
• Как приложение должно отправлять данные, чтобы
получатель знал как их обрабатывать?

19. Канал недопустимых сообщений
• Что делать с сообщением, которое по каким-либо
причинам не может быть обработано?

20. • Сообщения в канале не должны игнорироваться
• Недопустимость сообщения определяется контекстом –
местом обработки сообщения

21. Канал недоставленных сообщений
• Что делать с сообщениями, которые не удается доставить?

22. Гарантированная доставка
• Как гарантировать, что сообщение будет доставлено, даже
в случае возникновения сбоя системы обмена
сообщениями?

23. • Приводит к снижению производительности
• Степень надежности 99,999%

24. Адаптер канала
• Как подключить изолированное приложение к системе
обмена сообщениями?

25. Виды адаптеров
• Адаптер интерфейса пользователя
• Адаптер бизнес-логики
• Адаптер базы данных

26. Мост обмена сообщениями
• Как связать несколько различных систем обмена
сообщениями?

27. Шина сообщений
• Как организовать согласованную работу приложений, не
поставив их в зависимость друг от друга?

28. • Состоит из:
– Стандартная коммуникационная инфраструктура
– Адаптеры
– Стандартная инфраструктура команд

29. СООБЩЕНИЯ

30. Основные сообщения
•
•
•
•
Цель отправки сообщения
Возвращение ответа
Большие объемы данных
Медленный обмен сообщениями

31. Сообщение с командой
• Как использовать обмен сообщениями для вызова
процедуры другого приложения?

32. Сообщение с данными документа
• Как использовать сообщения для обмена данных между
приложениями?

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

34. • Модель проталкивания
• Модель вытягивания
– Обновление
– Запрос о состоянии
– Ответ о состоянии

35. Запрос-ответ
• Как организовать обмен сообщениями, чтобы отправитель
сообщения получал на него ответ?

36. • Подходы к получению ответа:
– Синхронная блокировка
– Асинхронный обратный вызов

37. Варианты запросов и ответов
• Удаленный вызов процедуры с помощью обмена
сообщениями.
– Запрос – сообщение с командой, описывающее функцию, которую
надо вызвать
– Ответ – сообщение с данными документа
• Запрос с помощью обмена сообщениями
– Сообщение, с текстом запроса
– Ответ – результирующий набор данных, отправленный в виде
цепочки сообщений
• Уведомление/подтверждение
– Запрос – сообщение о событии
– Ответ – сообщение с данными, подтверждающими получение
сообщения

38. Виды ответов
• Пустой ответ
• Результат
• Исключение

39. Обратный адрес
• Куда отправлять сообщение с ответом

40. Идентификатор корреляции
• Как инициатору запроса, получившему сообщение узнать,
к какому запросу оно относится?

41. Цепочка сообщений
• Как передавать большие объемы данных?

42. Срок действия сообщения
• Как получатель узнает, что сообщение уже устарело?

43. Индикатор формата
• Как спроектировать формат сообщения, чтобы
предусмотреть возможность изменений в будущем?
Подходы:
1. Номер версии
2. Внешний ключ
3. Документ с описанием формата

44. МАРШРУТИЗАЦИЯ СООБЩЕНИЙ

45. Классификация

46. Маршрутизатор на основе
содержимого

47. Фильтр сообщений

48. • Фильтры с сохранением и без сохранения состояния
• Фильтры vs маршрутизатор на основе содержимого

49. Динамический роутер

50. Стратегии разрешения кофликтов
• Игнорировать управляющие сообщения, которые
конфликтуют с существующими правилами
• Отправить сообщение первому получателю с
подходящими критериями
• Отправить сообщение всем получателям с подходящими
критериями

51. Список получателей

52. Надежность
• Одна транзакция
• Постоянный список получателей
• Идемпотентные получатели

53. • Динамический список получатеоей
• Эффективность с точки зрения сети
• Список получателей vs канал “публикация-подписка” с
фильтрами сообщений

54. Разветвитель

55. • Итеративный раветвитель
• Статический разветвитель
• Упорядоченные или неупорядоченные дочерние
сообщения

56. Агрегатор

57. Вопросы при реализации:
1. Корреляция. Какие входящие сообщения связаны друг с
другом?
2. Условия полноты. Когда агрегатор готов опубликовать
итоговое сообщение?
3. Алгоритм агрегации. Как скомпоновать полученные
сообщения в одно итоговое сообщение?

58. Стратегии агрегации
1.
2.
3.
4.
5.
Ожидать всех.
Время ожидания.
Первый – лучший.
Время ожидания с досрочным завершением.
Внешнее событие.

59. Условие полноты агрегата
1. Выбор “лучшего” ответа.
2. Сжатие данных.
3. Сбор данных для дальнейшей оценки.

60. Преобразователь порядка

61. Вопросы реализации:
1. Порядковый номер
2. Буфер для хранения сообщений
3. Борьба с переполнением буфера.

62. Обработчик составного сообщения

63. Рассылка сборка

64. Варианты реализации
1. Распределение с помощью списка получателей
2. Аукцион. Рассылка-сборка через “публикация-подписка”.

65. Карта маршрутизации
Необходимо провести сообщение через несколько этапов
обработки, при этом на момент разработки системы
последовательность этапов неизвестна и может
отличаться для каждого сообщения
Необходимо обеспечить:
• Эффективное продвижение сообщений (сообщения
должны проходить только через необходимые этапы
обработки)
• Эффективное использование ресурсов
• Гибкость (маршрут должен легко поддаваться
изменениям)
• Простота поддержки

67. Область применения
1. Цепочка бинарных этапов проверки
2. Каждый этап обработки представляет собой
преобразование без сохранения состояния
3. На каждом этапе происходит сбор данных, но не
принимаются решения

68. Диспетчер процессов
• Как провести сообщение через несколько этапов
обработки, если на момент проектирования системы
требуемые этапы обработки неизвестны и необязательно
будут выполняться последовательно друг за другом?

70. Аспекты реализации
•
•
•
•
Управление состоянием
Экземпляры процесса
Корреляция
Сохранение состояния в сообщениях

71. • Создание определения процесса

72. Брокер сообщений
• Как отделить пункт назначения сообщения от его
отправителя, сохраняя централизованный контроль над
сообщениями?

74. ПРЕОБРАЗОВАНИЕ СООБЩЕНИЙ

75. Оболочка конверта
• Система обмена сообщениями существующего
приложения предъявляет особые требования к формату
сообщения

76. Процесс упаковки сообщения в
конверт
1. Исходное приложение публикует сообщение в
необработанном виде.
2. Упаковщик принимает необработанное сообщение и
преобразует его в формат, удовлетворяющий
требованиям системы обмена сообщениями.
3. Система обмена сообщениями передает упакованное
сообщение в пункт назначения
4. Доставленное сообщение попадает к распаковщику.
5. Распакованное сообщение доставляется получателю.

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

78. Источники расширения
1. Вычисления
2. Среда
3. Другая система

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

80. • Удалить лишнее
• Упрощение структуры

81. Квитанция
Как сократить объем передаваемых данных, но не потерять
их?

82. Этапы обработки
1. Прибывает сообщение с данными
2. Регистрация багажа генерирует уникальный ключ для
информации, содержащейся в сообщении.
3. Регистрация багажа извлекает данные из сообщения и
помещает данные в постоянное хранилище
4. Данные помещенные в хранилище удаляются из
сообщения. Вместо них отправляется квитанция.
5. Расширитель содержимого на основании квитанции
извлекает данные из хранилища.

83. Выбор ключа
1. В теле сообщения уже может содержаться ключ.
2. Можно использовать идентификатор самого сообщения.
3. Генерировать уникальный ключ.

84. Специальные вопросы
• Использование ключа для сокрытия информации
• Использование квитанции с диспетчером процессов

85. Нормализатор
• Обработка входящих сообщений эквивалентных по
смыслу, но различных по формату

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

87. Способы преобразования
1. Изменить формат данных, используемый внутри
приложения
2. Внедрить в приложение преобразователь обмена
сообщениями
3. Использовать внешний транслятор сообщений

88. Результаты
1. Двойное преобразование данных
2. Сложность разработка канонической модели
3. Зависимости между форматами данных
–
Индикатор формата

89. КОНЕЧНЫЕ ТОЧКИ ОБМЕНА
СООБЩЕНИЯМИ

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

91. Виды шлюзов
1. Блокирующий (синхронный) шлюз обмена сообщениями
2. Событийно управляемый (асинхронный) шлюз обмена
сообщениями

92. Вопросы реализации
1. Соединение шлюзов в цепочки для обеспечения уровней
абстракции
2. Обработка исключений системы обмена сообщениями
Преобразование исключений системы обмена сообщениями в
исключения, специфичные для предметной области
3. Генерация кода шлюзов
–
–
Web-сервисы
WCF
4. Использование шлюзов в процессе тестирования

93. Преобразователь сообщения
Перемещение данных между объектами предметной
области и элементами системы обмена сообщениям, не
нарушая их независимость?

94. Вопросы реализации
1. Упрощение кодирования
–
Дублирование кода
2. Преобразователь + транслятор для канонической модели
данных

95. Транзакционный клиент
• Как клиенту управлять транзакциями при взаимодействии
с системой обмена сообщениями?

96. • Гарантируют, что сообщение либо будет добавлено в
канал, либо не будет
• Гарантируют, что либо будет считано из канала, либо не
будет
• Транзакционный отправитель – сообщение не будет
добавлено в канал до тех пор, пока отправитель не
подтвердит выполнение транзакции
• Транзакционный получатель – сообщение не будет
удалено из канала до тех пор, пока получатель не
подтвердит выполнение транзакции.

97. Сценарии транзакций
1.
2.
3.
4.
Отправка-получение пары сообщений.
Группа сообщений.
Сообщение – база данных
Сообщение – рабочий поток

98. Отправка-получение пары
сообщений
1. Реализация
Начать транзакцию, получить и обработать первое сообщение,
отправить второе, подтвердить выполнение транзакции
2. Результат
Первое сообщение не будет удалено из своего канала, пока второе не
будет успешно добавлено в свой канал
3. Тип транзакции
Если оба сообщения отправляются по каналам одной системы, то
транзакция простая, в противном случае - распределенная
4. !Может применяться только получателем запроса

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

100. Сообщение – база данных
1. Реализация
Начать транзакцию, получить сообщение, обновить базу
данных, после этого подтвердить выполнение транзакции. Или
обновить базу, отправить сообщение, подтвердить выполнение
транзакции.
2. Результат
Сообщение не будет удалено из канала до тех пор, пока не
произойдет обновление базы данных или база данных не будет
обновлена, пока не будут разосланы соответствующие
уведомления.
3. Тип транзакции
Распределенная транзакция.

101. Сообщение – рабочий поток
1. Реализация
Начать транзакцию, открыть единицу работы, отправить сообщение с
запросом, подтвердить выполнение транзакции. Или начать
другую транзакцию, получить сообщение с ответом, закрыть или
аварийно завершить единицу работы, подтвердить выполнение
транзакции.
2. Результат
Единица работы не будет успешно закрыта, пока запрос не будет
отправлен, или ответ не будет удален из канала, пока единица
работы не будет обновлена.
3. Тип транзакции
Распределенная транзакция

102. Опрашивающий потребитель
Приложение должно потреблять сообщения только
тогда, когда оно готово это сделать.
Явный запрос сообщений из канала.

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

104. Составные части
1. Инициализация.
2. Потребление.

105. Конкурирующие потребители
Параллельная обработка сообщений одним клиентом

106. Особенности
• Канал “точка-точка”
• Каждый из потребителей выполняется в собственном
потоке
• Скорость обработки сообщений определяется тем, как
быстро канал может распределять сообщения по
потребителям
• Конкурирующие потребители могут быть
опрашивающими, событийными или их комбинацией.
• Транзакционность может приводить к снижению
конкурирующих потребителей

107. Диспетчер сообщений
Согласованное распределение и обработка сообщений
потребителями одного канала

108. Составные части паттерна
• Диспетчер. Потребляет сообщения из канала, а затем
раздает их.
• Исполнитель. Получает сообщение от диспетчера, а затем
обрабатывает его.

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

110. Компоненты
• Поставщик. Задает параметры выбора сообщения перед
отправкой.
• Параметры выбора. Одно или несколько
значений, заданных в сообщении, на основании которых
потребитель принимает решение об обработке
сообщения.
• Избирательный потребитель. Получает только те
сообщения, которые соответствуют критериям отбора.

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

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

113. Особенности
• Каналы “публикация-подписка”
• Состояния подписчика:
– Подключен
– Отключен
– неактивен

114. Идемпотентный получатель
• Что делать, если сообщение было доставлено несколько
раз?
Стратегии:
• Явное удаление дубликатов сообщений
• Определение семантики сообщения с учетом
идемпотентности
Пример:
• Положить на счет 12345 еще 10 рублей.
• Установить баланс счета 12345 равный 110 рублям.

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

116. УПРАВЛЕНИЕ СИСТЕМОЙ

117. Шина управления
Компоненты системы распределены, как ими управлять?

118. Подсистемы
• Поток сообщений приложения
• Шина управления

119. Сообщения для шины
1. Конфигурационные сообщения.
Каждый компонент должен иметь набор настраиваемых параметров:
– Адреса каналов
– Форматы данных сообщений
– Тайм-ауты
– И т.д.
Также таблицы маршрутизации роутеров.
2. Пульсы.
Может включать дополнительные сведения о компоненте: число
обработанных сообщений, объем оперативной памяти и т.д.
3. Тестовые сообщения
Получить более подробную информацию о работе компонента, чем
предоставляет сообщение-пульс.

120. 4. Исключения.
Информацию об исключениях можно дублировать в шину
управления, чтобы система могла оценить степень их
серьезности.
5. Статистические сообщения
Как правило применяется канал с негарантированной доставкой или
с низким приоритетом.
6. Активная консоль
Все действия объединяются в единой центральной консоли.

121. Обходной путь
Сообщение проходит дополнительные этапы обработки с
целью проверки правильности, отладки и тестирования.

122. Отвод
Посмотреть содержимое сообщения, передаваемое по
каналу “точка-точка”

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

124. Журнал доставки сообщений
Отладка маршрутов следования сообщений
Вопросы:
• При прохождении сообщения через некоторые
компоненты идентификатор сообщения может меняться
• На одно входящее сообщение может быть несколько
исходящих
• Одно сообщение может являться результатом обработки
нескольких сообщений

125. Стратегии организации журнала
• Дерево
• Простой список
• Журнал доставки “победившего” сообщения
Особенно полезен, если сообщение проходит ряд фильтров

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

127. Вопросы реализации
•
•
•
•
Асинхронная обработка
Объем хранимых данных и нагрузка на есть
Очистка хранилища
Версионность данных

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

129. Применение
• Отладка
• Сбор метрик
• Выполнение дополнительных действий

130. Тестовое сообщение
Отладка, в случае если обработка сообщения выполняется
неправильно

131. Компоненты
•
•
•
•
Генератор тестовых данных
Вбрасыватель тестовых сообщений
Отделитель тестовых сообщений
Верификатор тестовых данных

132. Вентиль канала
Удалить лишние сообщения из канала, которые по какимлибо причинам остались в канале