Архитектор
0,0
рейтинг
15 апреля 2011 в 02:42

Разработка → Интеграция информационных систем

Ни для кого не секрет, что «уже все сделано до нас». Осталась всего-то малость «собрать фрагменты» для решения поставленной задачи. И тут оказывается, что интегрировать разобщенные части не редко сложнее, чем их написать. Почему же так происходит? Что можно с этим сделать?

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

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

Давайте перечислим и проанализируем факторы, влияющие на интеграцию:
  • Ускорение процессов. Развитие организации требует все чаще и чаще менять структуры данных, бизнес-процессы, не говоря уже о дизайне и пользовательском интерфейсе, который просто постоянно находится в изменении. Вот, как раз в таких динамичных областях, где “изменчивость” является самой сутью и природой системы, задача интеграции усугубляется и превращается в серьезную проблему.
  • Распределенность. Организации становятся все более крупными, а решаемые задачи все более комплексными, появляется логическая, организационная и географическая рассредоточенность.
  • Гетерогенность. В крупном проекте, почти никогда нет возможности придерживаться платформ и инструментов от одного производителя, поэтому приходится учитывать и поддерживать особенности нескольких платформ.
  • Наследственность. Невозможность полностью отказаться от легаси систем, морально устаревших технологий, старого аппаратного обеспечения, корторые, кстати, иногда дают вполне хорошие показатели по надежности и производительности но уж ни как не способствуют интеграции.
  • Хаотичность. Не всегда есть возможность полностью формализовать, специфицировать и структурировать данные, и часть модели остается “слабо-связанной”, не поддающейся или слабо поддающейся машинной обработке, анализу, индексации, обсчету.
  • Обусловленность. К сожалению, информационные системы ограничены не только техническими рамками, но и привычками людей (которых сложно переучивать), особенностями законодательства (которое просто не готово к появлению таких систем), множеством других факторов, не зависящих от разработчиков.
  • Интерактивность. Потребитель информации постоянно повышает свои ожидания о скорости реакции системы, быстродействии и оперативности доставки информации. Большинство процессов стремятся к выполнению в реальном времени.
  • Мобильность. Пользователь систем стал передвигаться быстрее, а взаимодействие с ним ведется через каналы связи общего пользования в транспорте, дома и на улице, в общественных местах и повсеместно.
  • Безопасность. Пока данные хранились на носителе внутри охраняемого помещения, то особо ни кто не беспокоился о шифровании, но теперь сетевые пакеты летают в воздухе и это нельзя оставлять без внимания.
  • Высоконагруженность. На сложность интеграции влияют: количество пользователей в системе, интенсивность потока обработки данных, объемы данных и ресурсоемкость вычислений.
  • Непрерывность цикла работы. Интеграция и апгрейд систем почти всегда должны проводиться без остановки их функционирования, плавно, постепенно и незаметно для организации и ее клиентов.
  • Межсистемная интеграция. Задачи стыковки не ограничены рамками организации, все чаще нужно интегрироваться с партнерами, клиентами, поставщиками, подрядчиками и даже государственными структурами.

Вот такие реалии, я даже готов утверждать, что нет в ИТ более сложной задачи, чем интеграция систем. Давайте проанализируем теперь задачу с другого ракурса, выделим параметры, отвечающие за сложность интеграции и предложим варианты минимизации негативного влияния этих параметров:
  • Концептуальная разница — основывается та том, что разработчики разных систем изначально приняли разные решения, предположения и допущения, которые концептуально не стыкуются между собой. Решается введением еще одного слоя абстракции, который концептуально не противоречит обоим подходам. При этом, есть два варианта реализации: (а) когда получившаяся система становится централизованной, а две и более интегрируемых системы превращаются в подсистемы и (б) когда мы используем архитектуру брокера (посредника, не являющегося центром), при этом системы остаются независимыми, а брокер обеспечивает прослойку между ними.
  • Технологическая разница — когда мы имеем несовместимые форматы обмена данными, протоколы взаимодействия и интерфейсы. Решается написанием конвертов, прослоек, брокеров и других примочек, не вполне красивых, но достаточно надежных.
  • Несовместимость лицензий. Подробнее останавливаться на этом не буду, так как не специалист я в этом вопросе, а решение может быть в каждом случае индивидуальное, на организационном уровне.

Общая задача у нас теперь выглядит так: необходимо интегрировать N информационных систем, характеризуемых описанными выше факторами, с минимизацией количества прослоек, конвертеров, брокеров и интерфейсов между ними. Если решать задачу в лоб, то между N системами будет N(N-1)/2 связей, то есть, при двухстороннем взаимодействии N(N-1) интерфейсов. Если учесть, что под интерфейсом мы тут можем понимать все что угодно, от веб-сервиса до оффлайнового процесса, запускаемого, например раз в сутки и делающего целый ряд сложных операций по синхронизации баз (запросы, обработку, экспорт, закачку по FTP, передачу сигнала другой части системы, чтобы та приняла переданные данные и выполнила свою часть работы, а потом уведомила о результатах и передала необходимые данных обратно). В общем от таких вариантов никогда не удастся избавиться полностью, вопрос только в грамотной их реализации.

Но приведу весь арсенал средств по решению поставленной задачи, из тех, которым научился от других, использовал сам и наблюдал на практике:
  • Стандартизация — нужно и важно использовать как можно больше международных, государственных и отраслевых стандартов, а если каких-то не хватает, а они явно просятся, то нужно вводить корпоративные стандарты, а часто имеет смысл и продвигать их в соответствующих организациях для скорейшего распространения и популяризации.
  • Интеграция на уровне брокеров. Преимущества: универсальность — практически всегда можно создать дополнительный программный модуль, который будут обращаться в обе системы, еще и разными способами (например, в одну через базу данных, а в другую через RPC). Недостатки: сложность, трудоемкость, а следовательно высокая стоимость разработки, внедрения и владения.
  • Интеграция на уровне данных — то есть несколько приложений могут обращаться в одну базу данных или в несколько баз данных, связанных репликациями. Преимущества: низкая стоимость интеграции, а при использовании одной СУБД это становится очень заманчивым решением. Недостатки: если база данных не экранирована хранимыми процедурами и не имеет необходимых ограничений целостности (в виде указания каскадных операций и триггеров), то разные приложения могут приводить данные в противоречивые состояния. Если же база экранирована и целостность обеспечивается, то и в этом случае, в параллельно работающих с одной БД приложениях, будут дублирующиеся части кода, выполняющие одинаковые или похожие операции. Кроме того, при изменениях структуры базы мы будем отдельно переписывать код всех приложений, с ней работающих.
  • Интеграция на уровне сервисов — это красивая интеграция, основанная на фиксации интерфейсов и форматов данных с двух сторон и позволяющая наладить быструю отработку межкорпоративной бизнес-логики. Есть и недостатки: все же, присутствует фиксация, а если структуры или процессы изменяются, то образуются проблемы и узко специализированные, частные решения.
  • Интеграция на уровне пользователя — это крайний случай, не автоматизированная интеграция, когда пользователи перемещают данные между системами через копипаст, файлы, почту и другие безобразия. Мы такие методы не рассматриваем, но они, к сожалению, часто применяются в тот период, пока программные системы не готовы, а развитие компании не позволяет ждать.
  • Динамическая интерпретация метаинформации — об этом мы поговорим в отдельной статье.

Это почти исчерпывающий обзор классических методов, прошу дополнять, если я что-то упустил. А вот по не классическим методам интеграции я готовлю еще одну публикацию. Спасибо за внимание.
Timur Shemsedinov @MarcusAurelius
карма
156,5
рейтинг 0,0
Архитектор
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (6)

  • +1
    Цикл статей будет теоретический?
    Будете рассматривать какие-то конкретные технические схемы?
    Очень интересна тематика отказоустойчивости интеграционных решений.
  • +1
    Если хватит времени и сил, то и теорию и примеры практического применения опишу, в том числе, хитрые, как межсерверные вызовы веб-сервисов с применением лонг-пулинга и случаи интеграции с метапрограммированием.
  • +1
    Если уж речь пошла про N(N-1) связей в случае двухсторонних коннекторов — то наверное стоит рассказать и про централизированную интеграцию через ESB/подобное, и вообще поподробней рассказать о различных топологиях интеграции.
  • +1
    Согласен, но просто все сразу не успеваю. Я сделал классификацию толькл факторов и методов, а еще нужна классификация архитектур: (1) базе сервисов — SOA, (2) архитектура с общей шиной — ESB, (3) интеграция с использованием репликаций БД, (4) событийно-ориентированная, (5) потоковая, (6) сигнальная или message-oriented, (7) интеграция на базе броекров запросов, (8) не знаю деже, стоит ли сюда включать облачную (это не столько архитектура, как технология), ну и старые: (9) файл-серверная, (10) клиент-серверная. Потом топологии взаимодействия рассмотреть: звезда, иерархия, кольцо, сеть, шина. Принципы зваимодействия: pool, push, message, event, hub, broker, multicast, bus. Кстати, нет же ж ни кгде толковой методички, где все вопросы по интегрции собраны и при этом было все сжато и кратко, только по существу. Все это разбросано по разным источникам, каждый только за свою архитектуру проповедует, поэтому тут еще на страницы 3 нужно дописать. Если еще есть коррективы, прошу добавлять, хочется собрать по архитектуре и программной инжинерии такой полный обзор.
    • 0
      В любом случае, ждем продолжения :)
  • 0
    Поступили вопросы по теме от Оскара Бостонова, ответы публикую:

    1) Какое определение вы используете для терминов ИНТЕГРАЦИЯ и ИНТЕГРАЦИЯ ИНФОРМАЦИОННЫХ СИСТЕМ?

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

    Интеграция — это любое взаимодействие между системами с помощью общих для них форматов данных или форматов вызовов, когда происходят прямые межсистемные запросы или обмен данными, в т.ч. через пользователя (выгрузил в файл, потом загрузил в другую систему) или репликации СУБД. Более точные определения есть для понятий «интеграция на уровне данных», «интеграция на уровне вызовов».

    2) Что вы понимаете под ИНФОРМАЦИОННОЙ СИСТЕМОЙ только программно-аппаратную часть или бизнес-процессы тоже?

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

    3) Чем отличается событийно-ориентированная и сигнальная архитектура?

    Я различаю эти две архитектуры по способу взаимодействия (но это единственный взгляд на вопрос):
    1. Событийное взаимодействие (принцип push): одна сторона устанавливает продолжительное соединение с другой стороной, т.е. первый признак это взаимодействие с установлением соединения, а второй — это подписка на события, т.е. односторонняя подписка или обоюдная и потом по соединению приходят события сразу как они происходят на удаленной стороне.
    См. так же http://en.wikipedia.org/wiki/Push_technology
    2. Сигнальное взаимодействие (принцип pull): одна сторона хочет узнать о состоянии другой, и периодически делает запросы, т.е. нет постоянного соединения, а сигналы поступают через периодические вызовы.
    См. так же http://en.wikipedia.org/wiki/Pull_technology

    4) Не рассматриваете ли вы вопрос семантической интеграции и глобальной целостности данных?

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

    С другой стороны, я не исключаю возможности создания универсальной модели в которой каждый объект имеет несколько связанных «аспектов» (подмоделей, представлений или проекций). Или проекция полной модели на каждую задачу происходит динамически в момент выполнения.

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