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

удаленного сервиса
Интеграция без использования шины

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

транслироваться во внешние системы.
Нетранзакциионные данные (static data, справочники, сигналы)
Более одного потребителя данных
Система-источник заинтересована сформировать сообщение для публикации только 1 раз

Каждое событие изменения сущности представлено отдельным сообщением
Очередь исходящих (входящих) сообщений может быть реализована как:
Внутренний механизм системы с доступом через web-сервисы
Буферная база (активная и архивная таблицы)
Файловый каталог
Поддерживает 2 варианта доставки сообщений:
Гарантированная доставка сообщений каждому подписчику (либо в очередь ошибок в случае ошибок)
Сообщения с экспирацией (time to live). Если сообщение не доставлено вовремя, оно уничтожается
Транспортные функции шины:
Мэпинг форматов (отсутствие сложных преобразований)
Управление порядком следования сообщений (FIFO), при наличии требований
Фильтрацию/Маршрутизацию сообщений по техническим атрибутам

Асинхронный он-лайн поток сообщений
ШАБЛОН

Требуется гарантированная он-лайн доставка данных из системы-источника

DB, файлы, веб-сервисы, MQ

DB, файлы, веб-сервисы, MQ

системе-источники происходит операция изменения данных. Это изменение регистрируется во внутренней очереди исходящих сообщений системы
Возможные варианты реализации интеграционных интерфейсов:
Веб-сервисы. Система реализует сервисы забора сообщений и подтверждения доставки в очередь
DB (ODBC/JDBC) Система реализует буферную таблицу. Каждое сообщение – отдельная строчка.
Файлы (NFS, FTP, e.t.c). Очередь реализуется папкой, а файлы – отдельные сообщения или группы сообщений (mini-batch).
Брокер сообщений (JMS,AMQ, e.t.c) - нативная реализация паттерна очередь.

Интеграционный адаптер регулярно опрашивает очередь исходящих сообщений (через вызов сервиса, опрос таблицы или файла или подписку на очередь).
Для полученных сообщений сохраняются:
Задача на доставку сообщений (заголовок) – в очереди задач
Тело сообщения – в хранилище сообщений
После успешного сохранения задачи и тела сообщения шина подтверждает в системе-источнике принятие сообщения к доставке:
Веб-сервисы – вызов сервиса подтверждения
DB – перенос (или удаление) доставленных сообщениий
Файлы – перенос (или удаление) доставленных сообщений
Брокер сообщений – нативный функционал подтверждения о прочтении
Шина создает подзадачи для доставки сообщения каждому потребителю. Сохраненное тело сообщения переиспользуется.
Шина сохраняет доставленное сообщение в очереди входящих сообщений системы-приемника. Доставка не считается выполненной без явного подтверждения принятия со стороны потребителя.

Варианты реализации входящей очереди сообщений системы-потребителя эквивалентны вариантам исходящей очереди для системы-источника.

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

Гибридный вариант push и pull модели для избежания возможных задержек при появления сообщений в очереди внутри интервала пулинга
Необходимость реализации сложной логики работы с сигналами на стороне бизнес-системы

в том числе удаления. Это изменение регистрируется в буферной таблице исходящих сообщений.

Шина реализует счетчик очереди для хранения состояния (последний sequence id доставленного сообщения) и актуализирует его в процессе доставки сообщений. Для каждого потребителя ведется отдельный счетчик.
Шина мониторит буферную таблицу источника, ожидая сообщений с sequence id больше чем хранящийся в счетчике.
При появлении сообщений, шина читает и пишет сообщения группами (mini-batch). Если сообщения успешно доставлены потребителю, шина обновляет значение счетчика максимальным seqence id доставленных сообщений
Отдельным процессом шина осуществляет регламентную чистку буферной таблицы. Для сообщений с sequence id меньше или равным минимальному из seqence id в счетчике очереди шина осуществляет либо перенос в архивную таблицу, либо удаление сообщений.
При необходимости повторной доставки сообщений шина может перенести сообщения из архива в активный буфер с новым sequence id
Если система предоставляет сервис генерации корректирующих загрузок по запросу, шина реализует GUI запроса в управляющем механизме и взаимодействие с этим сервисом?

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

данных, а не отдельных составляющих его сущностей по принципу all-or-nothing
Существенное время переноса в силу большого объема данных или слабых каналов передачи данных
Источник заинтересован в однократном формировании пакета

Требуется гарантированная доставка пакета данных из системы-источника
Требуется явное уведомление о готовности доставленного пакета к чтению (all-or-nothing)

Шина не хранит сообщения на своей стороне
Шина не реализует трансформацию переносимых пакетов, только Extract & Load
Шина мониторит сигнальную таблицу источника для определения наличия и готовности пакета к отправке
Шина обновляет сигнальную таблицу приемника для уведомления о наличии и готовности пакета в приемнике

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

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

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

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

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

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

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