Методы интеграции информационных систем

 

 

 

2.3 Общая база данных

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

 

2.4 Удаленный вызов

Стандарты на удаленный вызов  процедур возникли два десятка лет  назад, позволяя программному коду, который  выполняется на одном компьютере, вызывать код на другом. Стандарты  появлялись, развивались и угасали: RPC, CORBA, DCOM, RMI… последним в этом ряду стал протокол SOAP, основа современных Web-сервисов. Собственно в подходе  к интеграции с использованием удаленных  вызовов за эти годы ничего принципиально  не изменилось — если приложению А что-то нужно от приложения Б, то А одним из перечисленных способов вызывает функцию приложения Б.

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

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

 

2.5 Асинхронный обмен сообщениями

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

Недостаток данного подхода  — высокая цена. Система гарантированной  доставки на основе очередей сообщений  обычно сама по себе недешева; единственным известным мне исключением является Microsoft Message Queue (MSMQ), компонент серверных операционных систем семейства Windows. Правда, есть и свободно распространяемые бесплатные (например, ActiveMQ), которые, тем не менее, нужно развернуть, обучить специалистов, поддерживать, написать адаптеры между системой доставки и приложениями и т.д.

2.6 Топология

Существует два подхода  к организации маршрутов взаимодействия интегрируемых системы. Первый —  прямое взаимодействие интегрированных  систем по принципу «каждая с каждой», или «точка-точка». Второй — взаимодействие через центральный узел; подобную звездообразную архитектуру обычно называемую «хаб + спицы». Топология не зависит от физической архитектуры информационной системы, а определяет логические маршруты взаимодействия и передачи данных между интегрированными системами.

Точка-точка

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

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

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

Хаб + спицы

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Заключение

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

Готовых инструментов интеграции на рынке немало. Сложность выбора состоит в том, что среди представленных средств есть и узко ориентированные (например, IBM Message Broker), и позиционируемые как «универсальные» (скажем, Microsoft BizTalk). Однако выбор того или иного инструментария определяется не тем, что о нем говорит производитель, а конкретным составом «зоопарка» аппаратно-программных решений в организации, которые необходимо заставить работать совместно.

 

 

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

1. Калиниченко Л. А. Интеграция информации для решения задач в распределенных информационных системах       

/ http://synthesis.ipi.ac.ru/synthesis.

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

3. Гудов А. М., Завозкин С. Ю. Интеграция распределённых приложений при помощи системы электронного документооборота // Тр. Междунар. конф. «Вычислительные и информационные техноло-гии в науке, технике и образовании». Т. II. – Павлодар: ТОО НПФ «ЭКО», 2006.

2. Тейлор Д. Интеграция корпоративной информации – новое определение

Вести из Консорциума по интеграции

/ http:www.iso.ru/journal/articles/306.html.

4. Данилин А. В. Технологии  интеграции государственных информационных  систем и организации межведомственного  взаимодействия // Реализация проектов  электронного правительства. –  2008.