Шаблоны интеграционных взаимодействий

1.

Шаблоны интеграционных взаимодействий
1. Асинхронный он-лайн поток сообщений
2. Асинхронный он-лайн с прямым переносом
3. Передача пакетных данных
4. Синхронный вызов удаленного сервиса
5. Интеграция без использования шины

2.

Асинхронный он-лайн поток сообщений
ШАБЛОН
Бизнес-система (источник)
DB, файлы,
веб-сервисы,
MQ
Интеграционные
интерфейсы
Данные
Процессы
Очередь
исходящих
сообщений
Система-источник – мастер данных для
интегрируемой сущности.
Непрерывные изменения сущности,
которые должны транслироваться во
внешние системы.
Нетранзакциионные данные (static data,
справочники, сигналы)
Более одного потребителя данных
Система-источник заинтересована
сформировать сообщение для
публикации только 1 раз
Интеграционная шина
Оркестрация (map, lter, routing)
Интеграционный
адаптер
Очередь задач
Хранилище сообщений
DB, файлы,
веб-сервисы,Бизнес-система (потребитель)
MQ
Интеграционный
адаптер
Интеграционные
интерфейсы
Очередь
входящих
сообщений
Каждое событие изменения сущности представлено отдельным
сообщением
Очередь исходящих (входящих) сообщений может быть реализована как:
Внутренний механизм системы с доступом через web-сервисы
Буферная база (активная и архивная таблицы)
Файловый каталог
Поддерживает 2 варианта доставки сообщений:
Гарантированная доставка сообщений каждому подписчику (либо в
очередь ошибок в случае ошибок)
Сообщения с экспирацией (time to live). Если сообщение не
доставлено вовремя, оно уничтожается
Транспортные функции шины:
Мэпинг форматов (отсутствие сложных преобразований)
Управление порядком следования сообщений (FIFO), при наличии
требований
Фильтрацию/Маршрутизацию сообщений по техническим
атрибутам
Процессы
Данные
Требуется гарантированная он-лайн
доставка данных из системыисточника

3.

Асинхронный он-лайн поток сообщений
СЦЕНАРИЙ ВЫПОЛНЕНИЯ
Бизнес-система (источник)
DB, файлы,
веб-сервисы,
MQ
Интеграционные
интерфейсы
Данные
Процессы
Очередь
исходящих
сообщений
1. В системе-источники происходит операция
изменения
данных.
Это
изменение
регистрируется
во
внутренней
очереди
исходящих сообщений системы
2. Возможные
варианты
реализации
интеграционных интерфейсов:
• Веб-сервисы. Система реализует сервисы
забора сообщений и подтверждения доставки
в очередь
• DB (ODBC/JDBC) Система реализует буферную
таблицу. Каждое сообщение – отдельная
строчка.
• Файлы (NFS, FTP, e.t.c). Очередь реализуется
папкой, а файлы – отдельные сообщения или
группы сообщений (mini-batch).
• Брокер сообщений (JMS,AMQ, e.t.c) - нативная
реализация паттерна очередь.
Интеграционная шина
DB, файлы,
веб-сервисы,Бизнес-система (потребитель)
MQ
Оркестрация (map, lter, routing)
Интеграционный
адаптер
Очередь задач
Хранилище сообщений
Интеграционный
адаптер
Интеграционные
интерфейсы
Очередь
входящих
сообщений
1. Интеграционный адаптер регулярно опрашивает очередь исходящих
сообщений (через вызов сервиса, опрос таблицы или файла или
подписку на очередь).
2. Для полученных сообщений сохраняются:
• Задача на доставку сообщений (заголовок) – в очереди задач
• Тело сообщения – в хранилище сообщений
3. После успешного сохранения задачи и тела сообщения шина
подтверждает в системе-источнике принятие сообщения к доставке:
• Веб-сервисы – вызов сервиса подтверждения
• DB – перенос (или удаление) доставленных сообщениий
• Файлы – перенос (или удаление) доставленных сообщений
• Брокер сообщений – нативный функционал подтверждения о
прочтении
4. Шина создает подзадачи для доставки сообщения каждому потребителю.
Сохраненное тело сообщения переиспользуется.
5. Шина сохраняет доставленное сообщение в очереди входящих
сообщений системы-приемника. Доставка не считается выполненной без
явного подтверждения принятия со стороны потребителя.
Процессы
Данные
1. Варианты реализации входящей
очереди
сообщений
системыпотребителя
эквивалентны
вариантам исходящей очереди для
системы-источника.

4.

Асинхронный он-лайн поток сообщений
ОПЦИИ ВЗАИМОДЕЙСТВИЯ СИСТЕМЫ И ШИНЫ
Бизнес-система (источник)
Интеграционная шина
Сервис публикации
сообщений
Оркестрация
(map, lter, routing)
Интеграционные
интерфейсы
pull
Очередь
исходящих
сообщений
Бизнес-система (источник)
push
Очередь
недоставленных
сообщений
2.
3.
Хранилище сообщений
4.
Интеграционная шина
1.
Оркестрация
(map, lter, routing)
Интеграционные
интерфейсы
Сервис публикации
сообщений
Сервис приема
сообщений
1.
Сервис приема
сообщений
2.
3.
4.
Хранилище сообщений
Бизнес-система (источник)
Интеграционная шина
Сервис публикации
сообщений
Оркестрация
(map, lter, routing)
Интеграционные
интерфейсы
1.
2.
signal
Сервис приема
сообщений
Очередь
исходящих
сообщений
pull
Хранилище сообщений
3.
Интеграционные сервисы бизнес-системы наполняют сообщениями, требующими
публикации в шину, очередь исходящих сообщений
Интеграционный адаптер регулярно опрашивает очередь, вычитывает накопившиеся
сообщения и публикует
При использовании веб-сервиса интеграционный адаптер подтверждает успешную
обработку сообщения дополнительным вызовом
Интервалы чтения, размер пакетов разового забора сообщений и возможность
параллельной обработки сообщений настраивается на стороне интеграционного адаптера
Интеграционный сервис публикации сообщений бизнес-системы осуществляет прямой
вызов сервиса интеграционного адаптера для публикации сообщения в шину
В случае подтверждения от шины об успешности операции сообщение удаляется
В случае неподтверждения от шины или недоступности сервиса сообщение помещается
во внутреннюю очередь недоставленных сообщений бизнес-системы
Интеграционные сервисы бизнес-системы берут на себя обеспечение поддержание
соединения с шиной, повторного подключения в случае обрыва соединения, логику
доставки сообщений из очереди недоставленных сообщений
Интеграционные сервисы бизнес-системы наполняют сообщениями, требующими
публикации в шину, очередь исходящих сообщений
Интеграционный адаптер регулярно опрашивает очередь, вычитывает накопившиеся
сообщения и публикует
Интеграционный адаптер реализует сигнальный сервис принудительного запуска пулинга
сообщений из очереди. Система вызывает сигнальный сервис каждый раз, когда в очередь
исходящих сообщений попадает новое сообщение после некоторого перерыва. Данная
схема позволяет шине незамедлительно начать пулинг и избежать задержек при доставке
новых событий.
Развязка событий в бизнес-системе и
событий публикации в шину
Простой механизм взаимодействия с шиной
Шина управляет собственной нагрузкой
Средняя задержка доставки сообщений –
половина времени интервала пулинга
Минимальная задержка между событиями в
системе и публикацией сообщения в шину
Бизнес-система должна самостоятельно
реализовать механизм гарантированности
доставки и персистентности недоставленных
сообщений
Шина не управляет входящей нагрузкой
Гибридный вариант push и pull модели для
избежания возможных задержек при
появления сообщений в очереди внутри
интервала пулинга
Необходимость реализации сложной логики
работы с сигналами на стороне бизнессистемы

5.

Асинхронный он-лайн с прямым переносом
ШАБЛОН
Система-источник – мастер данных
для интегрируемой сущности.
Непрерывные изменения сущности,
которые должны транслироваться
во внешние системы.
Большой объем изменений
(транзакционные данные)
Небольшое количество
потребителей данных (1-3)
Система-источник заинтересована
сформировать сообщение для
публикации только 1 раз
Каждое событие изменения сущности представлено
отдельным сообщением
Шина не хранит сообщения на своей стороне
Шина переносит сущности группами (мини-батч) для
оптимизации производительности чтения и записи
данных
Максимально простая логика переноса
Возможны 2 варианта утилизации сообщений из
буферной таблицы:
• Архивная таблица – после успешной доставки
шина переносит сообщения в архив. Сообщения
из архива могут быть извлечены для повторной
доставки в случае необходимости
• В противном случае, шина просто удаляет
успешно доставленные сообщения
Требуется гарантированная он-лайн
доставка данных из системы-источника
Система переносит сообщения из
активной буферной таблицы в архивную
по факту обработки этих сообщений.
Либо удаляет, если архивация не
требуется.

6.

Асинхронный он-лайн с прямым переносом
СЦЕНАРИЙ ВЫПОЛНЕНИЯ
1. В
системе-источники
происходит
операция изменения данных, в том
числе удаления. Это изменение
регистрируется в буферной таблице
исходящих сообщений.
1. Шина реализует счетчик очереди для хранения состояния (последний sequence
id доставленного сообщения) и актуализирует его в процессе доставки
сообщений. Для каждого потребителя ведется отдельный счетчик.
2. Шина мониторит буферную таблицу источника, ожидая сообщений с sequence
id больше чем хранящийся в счетчике.
3. При появлении сообщений, шина читает и пишет сообщения группами (minibatch). Если сообщения успешно доставлены потребителю, шина обновляет
значение счетчика максимальным seqence id доставленных сообщений
4. Отдельным процессом шина осуществляет регламентную чистку буферной
таблицы. Для сообщений с sequence id меньше или равным минимальному из
seqence id в счетчике очереди шина осуществляет либо перенос в архивную
таблицу, либо удаление сообщений.
5. При необходимости повторной доставки сообщений шина может перенести
сообщения из архива в активный буфер с новым sequence id
6. Если система предоставляет сервис генерации корректирующих загрузок по
запросу, шина реализует GUI запроса в управляющем механизме и
взаимодействие с этим сервисом?
1. Система-потребитель
мониторит
буферную таблицу в ожидании новых
сообщений.
2. Обработанные
сообщения система
перемещает в архив, либо удаляет, в
соответствии с собственной логикой.

7.

Передача пакетных данных
ШАБЛОН
Требующие передачи данные
характеризуются следующими
свойствами:
• Необходим перенос всего набора
данных, а не отдельных
составляющих его сущностей по
принципу all-or-nothing
• Существенное время переноса в
силу большого объема данных или
слабых каналов передачи данных
• Источник заинтересован в
однократном формировании пакета
Шина не хранит сообщения на своей стороне
Шина не реализует трансформацию переносимых
пакетов, только Extract & Load
Шина мониторит сигнальную таблицу источника для
определения наличия и готовности пакета к отправке
Шина обновляет сигнальную таблицу приемника для
уведомления о наличии и готовности пакета в
приемнике
Требуется гарантированная доставка
пакета данных из системы-источника
Требуется явное уведомление о
готовности доставленного пакета к
чтению (all-or-nothing)

8.

Передача пакетных данных
СЦЕНАРИЙ ВЫПОЛНЕНИЯ
1. В
системе-источнике
возникает
событие формирования пакета для
публикации во внешние системы
2. Система источник наполняет буферную
таблицу содержимым пакета
3. Когда
пакет
заполнен,
система
источник размещает в сигнальной
таблице
строку,
означающую
готовность пакета к передаче.
4. Каждый пакет имеет собственный
уникальный номер. Каждая строка в
пакете имеет собственный уникальный
номер (sequence id)
1. Интеграционная шина мониторит сигнальную таблицу. При появлении сигнала
о готовности пакета шина запускает процесс переноса пакета в системыпотребители
2. В рамках самостоятельных задач (по 1 для каждого потребителя) происходит
прямой перенос записей из буфера источника в буфер приемника группами
(mini-batch). Статус переноса хранится во внутреннем счетчике шины.
3. По завершении переноса шина размещает в сигнальной таблице системыприемника уведомление о доставке пакета
4. Если пакет доставлен всем потребителям, при необходимости шина может
осуществить перенос доставленного пакета из буферной таблицы в архивную. В
противном случае происходит удаление доставленного пакета.
5. При необходимости повторной доставки пакета шина может перенести пакет из
архива в активный буфер и создать новое уведомление в сигнальной таблице
6. Если система предоставляет сервис генерации корректирующих загрузок по
запросу, шина реализует GUI запроса в управляющем механизме и
взаимодействие с этим сервисом.
1. Система-потребитель
мониторит
сигнальную таблицу в ожидании
уведомления о доставке пакета.
2. В случае появления уведомления
система забирает из буфера данные
доставленного пакета.
3. При необходимости система переносит
принятый пакет из активной таблицы в
архив. В противном случае система
удаляет принятый пакет.

9.

Синхронный вызов удаленного сервиса
ШАБЛОН
Бизнес-система (потребитель)
?
Данные
Процессы
Интеграционные
интерфейсы
• Системы-потребители в рамках
выполняемых процессов обращаются к
публичному сервису для выполнения
уникальной функции, реализуемой в
другой системе.
• Системы не являются плотно-связанными
частями одной бизнес-системы.
• Вызов сервиса не является схемой
передачи данных (сущностей)
Интеграционная шина
Интеграционный адаптер
proxy-сервиса
Интеграционный адаптер
proxy-сервиса
• Интеграционная шина изолирует поставщиков и
потребителей сервиса.
• Интеграционная шина может выполнять
оркестрацию вызова нескольких сервисов только в
части технических требований (невозможность
реализации через вызов одного сервиса).
Недопустима реализация бизнес-функций на уровне
шины.
• В силу высоких требований к скорости и
актуальности ответа, шина не обеспечивает
персистентность запросов.
• Все ошибки обработки запросов регистрируются в
логе шины с указанием контекста запроса,
предоставляемого системой-потребителем.
Бизнес-система (поставщик)
!
Интеграционные
интерфейсы
Процессы
Данные
• Систем-поставщик реализует
уникальный публичный сервис.
• Функционал сервиса не должен
дублироваться в других системах.
• Система источник готова предоставить
гарантии доступности и
производительности сервиса

10.

Интеграция без использования шины
Предпосылки:
Внутренняя интеграция взаимодействия между компонентами инф. системы (например., ИФД)
Инфраструктурная интеграция/типовые сервисы (LDAP, IMAP, Мониторинг…)
Передача в режиме реального времени потоковых медиа-данных, например видеопоток RTSP/RTMP
Комплексы систем одного вендора – SAS, SAP, 1С, e.t.c
Исключительные ситуации для Legacy-систем, развитие которых не целесообразно
Взаимодействия с использованием публичных сетей:
Шина может обратиться к внешней публичной системе (например ФИАС) напрямую, но такие случаи должны
утверждаться архитектурным комитетом
Шина не предоставляет публичных сервисов.
Интеграция должна происходить через фронт-системы компании (веб-сайты, FTP/SMTP серверы, API-шлюзы)