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

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

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


Собственно говоря, синхронизация состояний – это был первый сценарий решения проблемы. Отслеживать состояние объекта и обновлять информацию о нем в различных системах. У этого подхода существует как минимум две альтернативы.
Первая альтернатива известна под названием хранилище данных. Для того чтоб получить реальную картину происходящего мы сажаем за работу аналитиков и ставим перед ними задачу приведения структур данных из различных систем к общему знаменателю. А затем выстраиваем технологический процесс выгрузки данных в общее хранилище. Поверх такого хранилища можно уже строить общие процессы аналитики и отчетности, что необходимо для управления. Впрочем, хранилище можно использовать и для поддержки операционных процессов, но с некоторыми ограничениям.
Вторая альтернатива заключается в предоставлении приложениями сервисов данных. Т.е. каждое приложение обязано реализовать набор сервисов, по крайней мере, для чтения данных. Стоит это дорого, как в части оборудования, так и в части разработки, зато избавляет нас задачи синхронизации состояний. Собственно говоря, одной из причин интереса к сервис-ориентированной архитектуре и явилось желание единого унифицированного представления данных. Однако, идеологи SOA не сумели удержать границу между данными и поведением. В результате, мы не получили ни унификации данных, ни сквозных процессов. Я думаю, что плохую службу сервисной архитектуре сослужили протокол SOAP и россыпь стандартов WS-* Более простой и прагматичный подход предлагает архитектурный стиль REST. К сравнению этих подходов мы обязательно еще вернемся

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *