Интеграция ИС

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

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

аудит информационных систем компании;

построение моделей процессов и бизнес-логики будущей системы;

подбор промышленного интеграционного продукта (разработка собственного интеграционного решения);

тестирование, введение в эксплуатацию;

сопровождение внедренного интегрированного решения.

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

минимизация затрат и сбоев при взаимодействии информационных систем;

сокращение сроков и трудоемкости внедрения новых систем;

устранение дублирования функций и данных в системе;

создание единой системы контроля доступа к информации, единой политики информационной безопасности;

сокращение применения «ручного труда» при обмене данными.

Эволюция интеграции системы

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

Этап 1

Допустим, когда-то была создана система S (см рис.). Эта система состоит из 3-х независимых между собой подсистем (Ss - Subsystem).

Этап 2

На очередном этапе развития системы возникла потребность взаимодействия между Ss1 и Ss2, Ss1 и Ss3.

Разработчик пишет интерфейсы для каждой связи Ss-i <-> Ss-j. Обозначим стрелками направления взаимодействия между подсистемами. Интерфейсы представляют из себя описания вызовов процедур, исполняемых на данной подсистеме. Стрелки - это передача параметров вызова и возвращаемый результат.

Этап 3

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

Этап 4

Предположим, что система усложнилась до такой степени, что стало слишком накладно каждый раз писать индивидуальные интерфейсы для новой подсистемы (вернее, ее части, которая обращается к остальным Ss).

Возникает идея создания промежуточного программного слоя-шины, который инкапсулировал бы в себе эту задачу. Назовем его "Middleware" (связующее ПО).

Этап 5

На сегодняшний день уже разработано несколько стандартов такого промежуточного ПО, среди них описываемые ниже OMG CORBA и Microsoft DCOM/COM+. Поэтому в какой-то момент рациональнее будет не изобретать велосипед, а использовать эти стандарты для построения их собственной реализации либо продукты стороних призводителей ПО. Это прямой путь к технической интероперабильности подсистем.

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

Этап 6

Заглянем на секунду в будущее. Мы там видим, как подсистемы представляют из себя автономные объекты, которые живут своей жизнью и общаются друг с другом на уровне смысловых понятий их предметной области.

Это уже уровень семантической интероперабильности компонентов. По сложности стоящих перед исследователями задач он приближается к проблемам искусственного интеллекта.

Весьма интресным был бы количественный анализ необходимости перехода от одной версии взаимодействия к другой. Описанные выше критерии затрат на миграцию унаследованной системы частично дают ответ на вопрос, что же нужно учитывать при оценке. При попытке использования какого-либо стандарта на любом этапе появляется потребность сравнительного анализа выбора между разработкой собственного, использования уже разработанного какой-либо авторитетной организацией(-ми), либо программных продуктов сторонних производителей (которые, в свою очередь, тоже могут как использовать, так и не применять общепризнанные стандарты). В реалиях невообразимого разнообразия аппаратного и программного обеспечения становится весьма разумным использовать 2-й подход - использования общепризнанных стандартов. Одним из наиболее известных в этой области является стандарт взаимодействия открытых систем. Но что такое "открытая система"?

Создание промежуточного программного слоя как основной метод интеграции ИС

Промежуточный слой (Middleware) определяется как слой программного обеспечения, который расположен между операционной системой и средствами управления компьютерными сетями снизу и прикладными системами сверху. В 7-уровневой модели ISO/OSI это находится на 6-7 уровнях (представления и прикладного).

Выше этот термин использовался в более узком смысле как ПО взаимодействия между подсистемами.

Идеология открытых систем, позволяющая интегрировать ПО разных производителей

Попробуем определить открытую систему через ее признаки.

Каким требованиям должна удовлетворять открытая информационная система?

Как минимум, необходимо обеспечить:

отсутствие ограничений по стандартам входящих и выходящих потоков

инвариантность относительно технологий описания системы

отсутствие ограничений с точки зрения эволюции системы

гибкость и самоадаптацию при взаимодействии с другими большими системами и информацией различной природы.

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