Основная проблематика интеграционных ландшафтов
В современном мире бизнес-приложения практически не могут существовать без интеграции с другими приложениями. Посредством интеграции мы можем как осуществлять простейший обмен данными, так и строить сложные композитные приложения.
Однако накопленный парк приложений в силу своих архитектурных, платформенных и «возрастных» отличий имеет массу проблем интеграционного уровня.
К основным проблемам подобного типа можно отнести:
• Различные интеграционные механизмы приложений
• Несовпадающие, либо частично пересекающиеся форматы данных, избыточность передачи данных
• Отсутствие единой точки управления
• Сложности с масштабированием интеграционной схемы
• Необходимость модификации приложений-подписчиков.
A. Различные интеграционные механизмы
Большинство приложений при проектировании получают тот или иной интеграционный интерфейс. Однако каждый вендор имеет свое понимание роли приложения в интеграционной схеме. И чаще всего он видит своё приложение в центре интеграционного ландшафта (особенно этим грешат поставщики финансовых систем). Исходя из этого видения и строится архитектура интеграционной части приложения. Но так как приложения разрабатываются в различные временные отрезки, то они получают обычно те интеграционные технологии, которые доминируют в данный период. А из-за «эгоцентричной» архитектуры чаще всего закладывается одна или две из наиболее популярных технологий. В результате мы имеем набор «приложений-эгоистов», ожидающих, что вся интеграция будет строиться по заложенной в них интеграционной модели.
B. Несовпадающие форматы данных
Проблема имеет те же корни, что и рассмотренная выше. Каждое приложение помещает себя в центр интеграционного ландшафта и планирует играть по своим правилам. Приложение описывает форматы и состав данных, опираясь на свою модель данных и алгоритмических базисов. Чаще всего передаваемые данные стараются привести к полной идентичности с внутренней моделью данных приложения, чтобы избежать накладных расходов на изменение форматов. В результате мы имеем ситуацию, когда данные либо частично, либо полностью не совпадают по форматам, вплоть до разных форматов носителей. Довольно часто, при простых схемах интеграции, это приводит к необходимости многократной отправки одних и тех же данных в различных форматах.
C. Отсутствие единой точки управления
Отсутствие единой точки управления – одна из краеугольных проблем при построении интеграционных ландшафтов. Когда каждое приложение пытается управлять интеграцией со своей точки зрения, ситуация довольно быстро становится слабоуправляемой. Требуется планирование комплекса мероприятий, иногда даже не связанных друг с другом, для мониторинга и обслуживания. Возникают очаговые центры компетенции, связанные с конкретным приложением. Однако, следует отметить, что частично проблема может быть решена засчет комплексного подхода к полной автоматизации предприятия – единая платформа, единые протоколы, единые форматы, сквозная документация. Но, несмотря на прозрачность и конечность методов, в реальности такое встречается очень редко.
D. Сложности с масштабированием интеграционной схемы
Проблемы, связанные с централизованным управлением, плавно перерастают в проблемы масштабирования интеграционной схемы. Для планирования масштабирования надо воедино связать информацию: кто, когда, в каком объеме и составе передает и ожидает данные, какие форматы использует и протоколы поддерживает. В таких условиях изменение формата даже одного из пакетов информации может приводить к повышенным трудозатратам и простоям.
E. Необходимость модификации приложений-подписчиков
Для обеспечения загрузки и выгрузки данных зачастую требуется модификация приложения-подписчика. Это приводит к необходимости постоянной модификации приложений при масштабировании интеграционного ландшафта, простоям приложения в период внесения изменений, повышению вычислительной нагрузки на приложение для обеспечения интеграции; требует наличия специалистов по каждой платформе, на которой реализованы приложения-подписчики. Также это затрудняет саму модификацию систем-подписчиков, так как при планировании модификаций проектной командой приложения ей требуется учитывать и планировать необходимые доработки по интеграционной модели. При этом проектной команде либо придется самой погрузиться в архитектуру интеграционных связей, либо дополнительно привлекать специалиста, обладающего этими знаниями.
Основные подходы к построению интеграционных ландшафтов
Не секрет, что современные продукты класса ESB (Enterprise Service Bus) нацелены именно на комплексное решение перечисленных проблем интеграционных ландшафтов.
Несмотря на различные подходы и компонентную базу, все они исповедуют следующие базовые принципы:
• Стандартизация форматов
• Обеспечение подключения систем-подписчиков в единую сеть посредством библиотеки коннекторов
• Гарантированность доставки сообщений
• Перенос правил обработки и маршрутизации на глобальный уровень
• Единые механизмы протоколирования и мониторинга
• Развитые средства масштабирования.
Следуя этим принципам, для построения интеграции обычно выполняют более или менее стандартный набор работ. На первом этапе выполняются аналитическая проработка и стандартизация структур передаваемых данных. Могут быть использованы следующие подходы: подход, при котором все данные от систем-источников приводятся к единым структурам, или подход, при котором данные приводятся к структурам систем-подписчиков перед доставкой. Довольно часто используется смешанный подход к структурам данных. Первый вариант позволяет сразу при получении привести передаваемые данные к стандарту и использовать эти данные в дальнейшем (например, для динамической маршрутизации данных на основании их содержимого). При необходимости формируются шаблоны информационных пакетов. Еще одним плюсом этого подхода является то, что в этом случае все участники интеграционного процесса одинаково понимают структуру данных периметра интеграции.
Второй подход позволяет сократить накладные расходы на преобразование данных и выполнять его при получении только для систем-подписчиков, которые в этом нуждаются. При смешанной схеме преобразование либо разделяется по типам данных, либо выполняется всегда на всех точках маршрута доставки данных. Делается это для упрощения последующего сопровождения интеграционного ландшафта. Так как мы знаем планируемую структуру данных и можем четко отслеживать её инструментами мониторинга и автоматической валидации.
После определения форматов и структур данных производят формирование процессов движения информации. Различают «маршрутную» и «потоковую» схемы доставки данных. Они довольно похожи между собой, но имеют и некоторые различия.
Маршрутная схема.
Эта схема предполагает, что система-отправитель не должна знать о потребителях данных. В свою очередь, системы-потребители не должны зависеть от поставщика данных. Они просто получают данные, на которые они подписаны, по факту их возникновения в сети. Это позволяет строить слабосвязанные схемы с возможностью буферизации и агрегации данных. Также эта схема отличается тем, что механизмы получения, обработки и загрузки данных выделены в отдельный процесс и не связаны напрямую с процедурой маршрутизации.
Для реализации этой схемы необходимо определить:
• Типы данных и методы их извлечения
• Список получателей и условия поставки данных этого типа до обозначенных получателей
• Список маршрутов
• Набор процедур трансформации.
Важно понимать, что для каждого объекта выполняются действия, связанные только с этим объектом. То есть, для системы-источника мы определяем, какие типы данных он будет отдавать, и каким образом мы их будем извлекать; определяется механизм трансформации полученных данных (если требуется). Для системы-подписчика, в свою очередь, также определяются типы данных, которые он будет принимать, механизмы загрузки и схемы предварительной трансформации (если требуется). В маршрутах описываются условия доставки различных типов данных до каждой системы-подписчика. Такой подход позволяет легко масштабировать интеграционную схему под любые возникающие изменения.
К недостаткам этой схемы можно отнести снижение сквозной прозрачности истории прохождения данных. Этот недостаток в системах чаще всего решается инструментальными средствами мониторинга.
Потоковая схема.
При этом подходе специалист по интеграции описывает полные потоки прохождения данных. Системы-источники и системы-приемники жестко связаны между собой в рамках потока.
Для полного описания потока требуется определить следующие объекты и механизмы:
• Список доступных систем-источников
• Методы подключения к системам-источникам
• Методы извлечения данных для каждой системы-источника
• Методы трансформации данных
• Методы расщепления и сложения данных
• Список систем-подписчиков
• Методы подключения к системам-подписчикам
• Методы передачи данных для каждой системы-подписчика.
Чаще всего используется подход, когда один поток оперирует каким-то одним типом данных. Однако важно понимать, что классическая модель потоков не обязана оперировать одним типом данных. Проектирование таких систем ведется через определение списка потоков, структурирование информации внутри каждого потока. Далее определяются точки возникновения информации, список получателей и необходимые для них трансформации.
Важно понимать, что каждое описание потока требует заново формировать вышеописанный список объектов и механизмов.
Недостатками этой модели являются:
• Потенциальная возможность частичного пересечения по данным в различных потоках;
• Потоки, оперирующие несколькими типами данных, усложняют понимание полной схемы и требуют схем управления данных внутри потоков (потоки в потоках). Сложность растет с ростом уровня вложенности потоков;
• Для каждого потока требуется описание всех процедур извлечения, трансформации, подключения и т.д., даже если схожие процедуры используются в соседних потоках. Возрастает сложность изменения масштаба интеграционной модели.
При любом подходе важной составляющей интеграционной модели являются схемы трансформации данных. Различаются только места, в которых описываются эти схемы. В первом случае схемы трансформации описываются относительно систем – выход системы-источника, вход системы-подписчика – и представляют собой единую процедуру обработки данных для этого источника. Во втором случае схема трансформации описывается внутри потока данных и может быть разбита на несколько независимых участков. Хочется обратить внимание, что в отличие от интеграционных моделей типа «точка-точка», процедура трансформации позволяет довольно сильно снизить нагрузку на прикладное приложение. Практически, использование ESB со схемами трансформации избавляет клиентское приложение от всей нетипичной нагрузки по обеспечению обмена. Решается одна из типовых проблем – необходимость доработки системы-подписчика.
Схемы трансформации обычно обладают следующей функциональностью:
• Изменение форматов передаваемых данных
• Изменение структуры передаваемых данных
• Обогащение данными
• Обеднение данных в целях уменьшения объема
• Разделение информационных пакетов на несколько
• Слияние нескольких информационных пакетов в один
• Валидация данных прикладными бизнес-правилами.
Также разработка схем трансформации позволяет существенно снизить объемы передаваемых данных. Это достигается за счет того, что выгрузка данных осуществляется однократно, атомарно и только в необходимом объеме. При этом инициатором выгрузки является либо событие по изменению данных, либо запрос данных от схемы трансформации в объеме, необходимом для выполнения обогащения данных.
Все действия по извлечению данных, трансформации и загрузке протоколируются и записываются в журналы различных форматов. Наиболее частым подходом является выделение отдельного сервера под хранение таких журналов. Это позволяет подключать специализированные системы мониторинга для возможности оперативного получения данных в человекочитаемом виде.
Хранение журналов разделяется на оперативное и архивное. Для оперативного хранения зачастую используются циклически перезаписываемые лог-файлы, которые по мере заполнения сбрасываются в архивное хранилище.
Отдельно протоколируются состояние объектов ESB и счетчики производительности оборудования. Это позволяет строить полную оперативную картину прохождения данных и текущего состояния системы в целом. Наиболее продвинутые решения имеют в своем составе средства проактивной диагностики состояния сети. Эта диагностика позволяет заблаговременно информировать сотрудников, выполняющих обслуживание интеграционной сети, о возможности возникновения проблемы, чтобы устранять потенциальные угрозы.
В результате мы имеем четкую и прозрачную модель данных, управляемую из единой точки и обеспеченную различными средствами централизованного мониторинга.
***
Построение информационного ландшафта позволяет решить многие проблемы, которые присутствуют при точечных интеграциях, но требует вдумчивого подхода к проектированию и выбору решения. Следует оценить плюсы и минусы реализуемых подходов и выбрать продукт, максимально обеспечивающий покрытие будущего ландшафта коннекторами, блоками трансформации, имеющий развитые системы мониторинга и проактивной диагностики. Затем выбрать подходы к проектированию схем передачи данных, оценить какой из подходов наиболее предпочтителен в вашем случае. На выходе мы получим стабильную, масштабируемую интеграционную модель с полным и централизованным управлением процессом.
Станислав Пиголкин, технический директор
Автор: AXELOT-IT
