Телефон: 8-800-350-22-65
WhatsApp: 8-800-350-22-65
Telegram: sibac
Прием заявок круглосуточно
График работы офиса: с 9.00 до 18.00 Нск (5.00 - 14.00 Мск)

Статья опубликована в рамках: LXV Международной научно-практической конференции «Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ» (Россия, г. Новосибирск, 14 мая 2018 г.)

Наука: Информационные технологии

Скачать книгу(-и): Сборник статей конференции

Библиографическое описание:
Донцов П.П. ИНТЕГРАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ СООБЩЕНИЙ // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. LXV междунар. студ. науч.-практ. конф. № 5(64). URL: https://sibac.info/archive/technic/5(64).pdf (дата обращения: 05.03.2024)
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

ИНТЕГРАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ СООБЩЕНИЙ

Донцов Павел Павлович

студент, кафедра информационных технологий и автоматизированного проектирования в строительстве ВГТУ,

РФ, г. Воронеж

Курипта Оксана Валерьевна

научный руководитель,

канд. техн. наук, доцент ВГТУ,

РФ, г. Воронеж

Введение

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

Интеграция информационных систем — это процесс установки связей между информационными системами предприятий и организаций для получения единого информационного пространства и организации поддержки сквозных бизнес-процессов предприятий и организаций [2].

Основные способы интеграции приложений:

  •  Обмен файлами
  •  Обмен через общую базу данных
  •  Удаленный вызов функций
  •  Сервисная шина предприятия (MQ, ESB)

Обмен файлами

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

К плюсам интеграции через обмен файлами следует отнести:

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

Однако у этой схемы есть и несколько важных ограничений, которые надо учитывать при разработке интеграционной модели:

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

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

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

Обмен выполняется по принципу «точка-точка». Достаточно сложно централизованно проследить маршруты и историю прохождения данных. Затруднено централизованное управление интеграционной моделью.

Обмен через общую базу данных

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

К основным плюсам можно отнести:

  •  Встроенные механизмы СУБД для разграничения доступа к конкурентным данным. Данные не могут быть прочитаны или изменены до завершения процедуры записи.
  •  Единые механизмы записи и считывания данных. Все приложения оперируют стандартными механизмами СУБД по работе с данными. Это позволяет организовать единые подходы к разработке и внесению изменений.
  •  Единый формат данных для всех участников интеграционного процесса. Все приложения выполняют приведение данных к единым типам, любое приложение владеет всей полнотой знаний о текущих типах данных и их структуре
  •  Более высокая скорость доставки данных относительно файлового обмена. В этой схеме не требуется выделять регламентные периоды доступа к данным – они могут быть прочитаны сразу после их фиксации в БД
  •  Встроенные механизмы СУБД для протоколирования доступа к данным позволяют проводить расследования о причинах того или иного отклонения при доставке.

К недостаткам схемы относятся:

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

Удаленный вызов функций

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

Для реализации такого подхода могут использоваться следующие технологии, предоставляющие механизмы удаленного вызова процедур:

  •  COM
  •  CORBA
  •  SOAP
  •  Java RMI

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

К основным плюсам подхода следует отнести:

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

К недостаткам подхода следует отнести:

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

Сервисная шина предприятия

Для комплексного решения проблемы передачи данных с получением доступа к функциональности приложений используется подход передачи сообщений посредством специализированных продуктов. Общий подход к построению интеграции таков: система подключается к интеграционной шине посредством специализированных коннекторов. Главная задача коннектора – обеспечение канала приема данных в систему и передачи данных из нее. Задача системы-источника — передать данные в коннектор, а маршрутизация, трансформация и доставка сообщений в системы-потребители осуществляются уже без ее участия.

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

Основными плюсами системы являются:

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

Основными недостатками модели принято считать:

  •  Дополнительные затраты на приобретение и поддержку специализированных программных продуктов. Зачастую необходимо выделение дополнительных серверных ресурсов.
  •  Необходимость проведения обучения персонала по этим программным продуктам.

Критерии выбора способа интеграции

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

Возможность всех приложений интеграционного контура использовать выбранный способ интеграции

Разные приложения могут быть реализованы в разных архитектурных стилях и парадигмах разработки. Например, при выборе способа интеграции «Обмен файлами», все приложения интеграционного контура должны быть способны обмениваться файлами и умеют работать с предоставляемыми каждым приложением форматами.

Возможность внесения изменений в приложения

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

Требования к обеспечению надежности

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

Уровень связанности приложений

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

Временные задержки доставки данных

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

Требования к защите данных

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

Заключение

Применение критериев выбора к ранее рассмотренным шаблонам интеграции, позволяет сформулировать следующие выводы:

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

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

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

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

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

 

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

  1. Карпова И.П. Базы данных: учеб. пособие. М.: Питер, 2013. – 240 с.
  2. Морозова О.А. Интеграция корпоративных информационных систем: учеб. пособие. М.: Финансовый университет, 2014. – 140 с.
Проголосовать за статью
Конференция завершена
Эта статья набрала 0 голосов
Дипломы участников
У данной статьи нет
дипломов

Оставить комментарий

Форма обратной связи о взаимодействии с сайтом
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.