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

Введение

1. Понятие интеграции

1. Функции и задачи интеграции

2. Цели интеграции

2. Методы интеграции

2.1 Взаимодействие интегрированных  приложений

2.2 Обмен файлами

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

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

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

2.6 Топология

Заключение

Введение

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

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

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

1. Понятие  интеграция

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

1.1 Функции и задачи интеграции

При создании системы интеграции возникает  ряд задач, состав которых зависит  от требований к ней и используемого  подхода. К ним, в частности, относятся:

• Разработка архитектуры системы интеграции данных.

• Создание интегрирующей модели данных, являющейся основой единого  пользовательского интерфейса в  системе интеграции.

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

• Интеграция метаданных, используемых в системе источников данных.

•   Преодоление неоднородности источников данных.

• Разработка механизмов семантической  интеграции источников данных.

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

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

Система интеграции прикладных приложений обеспечивает:

• Согласование данных, используемых различными приложениями.
• Синхронизацию и маршрутизацию информационных потоков в соответствии с определенными бизнес-правилами.
• Преобразование данных по заданным алгоритмам.
• Поддержку интерфейсов к существующим промышленным системам, системам технологического уровня.
• Поддержку удобного интерфейса пользователя для описания бизнес-правил и алгоритмов взаимодействия приложений.
• Поддержку промышленных стандартов в области передачи и обработки данных.
• Интеграцию следующих промышленных приложений: SAP/R3, Oracle EBS, People Soft, Hyperion, Siebel, 1C и др. 

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

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

Следствиями отсутствие должного решения проблемы интеграции являются:

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

Это определяет цели интеграции приложений предприятия.

1.2 Цели интеграции

Общие цели интеграции приложений можно сформулировать следующим  образом:

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

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

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

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

Не надо забывать, что  основная цель интеграционных проектов — снижение издержек, равно как  и предпосылки к проектам лежат  в бизнес-области даже если проект относится сугубо к ИТ. К примеру, задача развертывания систем управления и мониторинга возникает, если бизнес озабочен снижением затрат на эксплуатацию ИТ-инфраструктуры. Мало того, интеграционные проекты в какой-то степени являются перекладыванием проблем с бизнес-подразделений на ИТ-службу. Рассмотрим, к примеру, типичную ситуацию, когда формированием отчетов «в стиле Excel» для руководства занимается группа в составе финансового департамента. От ИТ-подразделения при этом требуется лишь поддержание в работоспособном состоянии корпоративных информационных систем. В случае же внедрения системы, автоматически формирующей эту отчетность, за все — в том числе и за ошибки в данных — будет отвечать ИТ-служба. Действительно, по мере увеличения степени интегрированности и взаимосвязанности информационных систем возрастает ответственность, роль и статус ИТ-службы, увеличивается зависимость основных показателей работы всей организации от надежности и эффективности интегрированной информационной системы предприятия.

2. Методы интеграции

2.1 Взаимодействие интегрированных приложений

Для взаимодействия приложений обычно используются такие методы, как обмен файлами, общая база данных, удаленный вызов и асинхронный  обмен сообщениями. В этом списке нет прямого обмена данными между  базами данных приложений: этот метод  ближе не к интеграции приложений, а к перемещению данных. С точки зрения интеграции приложений важна возможность в процессе обмена данными выполнять какую-то содержательную обработку (например, при загрузке накладных пересчитывать товарные остатки). Прямой обмен данными, который обычно выполняется средствами класса ETL (extract, transfer, load) или самодельными утилитами, обычно такой возможности не предоставляет.

2.2 Обмен файлами

Обмен файлами пожалуй, самый распространенный подход к организации взаимодействия. Это связано с относительной простотой реализации, а также существованием стандартных (или «почти» стандартных) форматов обмена. Например, большая часть корпоративных информационных систем позволяет загружать и выгружать файлы, например, в формате CSV (Comma-Separated Values — «поля, разделенные запятыми»). Но у этого подхода есть и недостатки; если необходимо оперировать сложными структурами, то простые форматы обмена уже не пригодны. Возникающие в таких случаях специализированные форматы файлов должны «понимать» взаимодействующие системы, что ведет к жесткой зависимости систем друг от друга. Этот недостаток обычно преодолевают всевозможными утилитами конвертации данных. Кроме того, обычно обмен файлами подразумевает участие человека — кто-то должен выгрузить файл, скопировать его на другой компьютер, загрузить. Однако если интегрируемые методом обмена файлами системы имеют возможность автоматической загрузки/выгрузки (например, по расписанию), то данный подход позволяет построить полностью автоматизированное решение, которое вследствие своей простоты обладает высокой надежностью и пропускной способностью.

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.