Сценарии интеграции приложений

Одна из немногих книг по интеграции корпоративных информационных систем Enterprise Integration Patterns появилась в конце 2003 года. По большому счету других, сколь либо серьезных исследований данного вопроса с того времени и не появилось. Автор книги Gregor Hohpe поддерживает одноименный сайт Enterprise Integration Patterns на котором можно посмотреть основные паттерны. Впрочем, описаны они довольно кратко и лучше читать книгу. Тем более что она переведена на русский язык как Шаблоны интеграции корпоративных приложений.

При всем искреннем уважении к Грегору Хопу, должен отметить, что о паттернах корпоративной интеграции речь идет только в первых нескольких главах книги, написанных такими уважаемыми людьми как Мартин Фаулер и др. Авторы выделяют четыре основных паттерна интеграции: файловый обмен, общая база данных, вызов удаленной процедуры и обмен сообщениями. Основную часть книги как раз и занимают паттерны обмена сообщениями. Messaging, безусловно, мощный и эффективный подход как при интеграции так и при разработке корпоративных систем. Однако сценарии интеграции корпоративных приложений это не только и не столько messaging. Это и файловый обмен и синхронный вызов сервисов и доступ разных приложений к общей базе данных. И в описании подходов к интеграции чувствуется определенный пробел. Чтобы не перегружать слово паттерны, я буду использовать термин сценарии интеграции приложений и постараюсь постепенно заполнить возникший пробел.

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

Итак, общая база данных, используемая несколькими приложениями. Хорошо это или плохо?

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

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

До недавнего времени я готов был безоговорочно согласиться со всеми эти аргументами. Но сейчас, я не то чтоб хотел с ними поспорить. Скорее уточнить в каких случаях и каким образом можно использовать общую базу данных. Конечно, если у вас хватает денег на создание реплик или ежедневных копий, то можно идти этим путем. Но когда счета за оборудование и лицензии СУБД превышают все разумные границы пора начинать думать иначе. Системы управления реляционными базами данных наиболее распространенный и наиболее эффективный инструмент последних десятилетий. Мы все к нему привыкли и потому не видим, где именно скрыты ограничения. А это, например, и протокол доступа. Напомню, что доступ к БД – это протокол, требующий установления соединения и обрабатывающий запросы в рамках этого соединения(stateful). А такие сервисы довольно сложно масштабировать. И разные подходы к оптимизации для чтения и добавления данных и многое другое. Общие базы данных использовать можно. Для ряда задач, например общекорпоративных справочников – это вообще практически единственный подход к интеграции.

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

  1. Внешняя система добавляет в интерфейсную таблицу запись с параметрами запроса, например идентификатором документа.
  2. Промежуточный job периодически выбирает записи из интерфейсной таблицы. Если обработка таблицы ведется несколькими job-ами, что бывает довольно часто в системах с высокой нагрузкой, он изменяет статус записи (дополнительное служебное поле) чтоб другие экземпляры процесса видели, что запись уже обрабатывается.
  3. Этот волшебный job, который, кстати, легко может оказаться внешним по отношению к СУБД приложением, выбирает нужную запись из основных таблиц и изменяет запись в интерфейсной таблице, заполняя ряд полей и меня значение статуса.
  4. Внешняя система периодически выбирает из интерфейсной таблицы записи, статус которых установлен в значение «готово»

Недостатки предложенного подхода:

  • При изменении формата запроса надо переписывать всё. И интерфейсную таблицу и job и приложения. А изменения формата запроса происходят довольно часто, т.к.:
  • Таблица реляционной БД накладывает ограничения на количество и формат полей.
  • Дополнительная, ничем не обоснованная нагрузка на СУБД.
  • Непредсказуемое время отклика

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

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

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

Другие статьи по теме:

Реклама

4 responses to “Сценарии интеграции приложений

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s