CC BY
97
ВЕСТНИК ЮГОРСКОГО ГОСУДАРСТВЕННОГО УНИВЕРСИТЕТА
2011 г. Выпуск 3 (22). С. 45-50
УДК 004.94:378
ОБЕСПЕЧЕНИЕ СЛАБОЙ СВЯЗАННОСТИ ИНТЕГРИРУЕМЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ПОСРЕДСТВОМ АСИНХРОННОГО ОБМЕНА СООБЩЕНИЯМИ ЧЕРЕЗ СЕРВИСНУЮ ШИНУ
С. П. Семенов, Я. Б. Татаринцев
Введение. Постановка проблемы
В последнее время для создания эффективной системы управления во многих вузах широко применяются автоматизированные информационные системы. Всё большую популярность приобретает процессный подход, то есть осуществляется переход от функциональной организации к управлению как каждым бизнес-процессом в отдельности, так и всеми бизнес-процессами в целом. Под бизнес-процессом понимают совокупность (цепочку) работ (операций, функций), результат выполнения которых имеет ценность для потребителя, в качестве которого может выступать сотрудник, руководитель, студент, а также другой бизнес-процесс.
В связи с бурным развитием информационных технологий, одним из самых распространённых подходов к автоматизации является выбор для каждого отдельного бизнес-процесса наиболее подходящего («лучшего», в том числе и по стоимости) программного продукта. Таким образом, информационную инфраструктуру образовательного учреждения (ОУ) составляют несколько десятков разнородных приложений, которые разрабатываются разными авторами с помощью различных средств реализации, имеют уникальные модели и форматы описания данных. При этом информация об объектах зачастую дублируется и не всегда актуальна, что приводит к её противоречивости и неполноте.
В такой обстановке для обеспечения полноценного взаимодействия между N отдельными функциональными подсистемами необходимо реализовать N(N - 1)/2 интеграционных интерфейсов по принципу «точка-точка» (от англ. «point-to-point») (рис. 1), преодолев многочисленные проявления неоднородности, присущей информационным системам [1].
Рис. 1. Стихийная интеграция
Таким образом затраты на реализацию информационного обмена будут значительно превышать затраты на развитие функциональности самих подсистем. Кроме того, такой подход характеризуется «сильным связыванием». Каждая информационная система «зависит» от функционирования остальных связанных систем и средств интеграции. И малейшие изменения или сбой в одной из систем останавливает налаженный процесс информационного взаимодействия и требует вмешательства программистов.
Всё это делает актуальными задачи разработки новых моделей единой информационной среды ОУ и новых подходов к реализации информационного обмена.
Модель многокомпонентной информационной среды управления образовательным учреждением
Одно из логичных решений данной проблемы - внедрение корпоративной информационной системы класса ERP [2], рынок которых, в том числе и ориентированных на вузы, представляет сейчас большой выбор [3, 4]. Это позволяет обойти проблему интеграции разнородных приложений, так как внутри единой системы нет дублирования функциональных единиц, и основные БП уже связаны между собой. Однако даже при таком подходе не удастся полностью отказаться от унаследованных приложений. Так как ни одна монолитная система не обладает полной функциональностью и не всегда удаётся переложить автоматизацию БП со специализированных приложений в ERP-систему.
Предлагается современную инфраструктуру ОУ представить в виде многокомпонентной информационной среды [5, 6] (рис. 2).
Выделим основные компоненты:
1. Корпоративная информационная система класса ERP.
2. Группа унаследованных и узкоспециализированных локальных информационных систем.
3. Модуль интеграции данных и сервисная шина предприятия (Enterprise Service Bus, ESB).
4. Единое хранилище данных.
5. Средства формирования и публикации консолидированной отчётности.
Рис. 2. Модель многокомпонентной информационной среды управления ОУ
Анализ существующих методов интеграции
Интеграция необходима там, где происходит взаимодействие двух или более разнородных систем, и обуславливается необходимостью получения общей картины бизнес-процессов.
В 60-70-х годах первые корпоративные приложения создавались для автоматизации отдельных процессов и необходимость интеграции приложений возникла лишь с появлением распределённых баз данных [7]. В 80-ых годах большинство проектов разрабатывались на основе оперативной обработки транзакций и для решения задачи интеграции Уильям Г. Ин-мон определил понятие хранилища данных (ХД) как «предметно-ориентированной, интегрированной, содержащей исторические данные, не разрушаемую совокупность данных, предназначенную для поддержки принятия управленческих решений» [8].
В 90-х года был предложен принципиально новый подход к автоматизации БП - системы планирования ресурсов предприятия (Enterprise Resource Planning - ERP). По замыслу разработчиков, данные системы должны были снять задачу интеграции, так как все процессы протекают в рамках одного приложения и все данные хранятся в общей базе данных. Однако абсолютной универсальности в рамках одной системы добиться сложно и корпорации были вынуждены использовать унаследованные и специализированные приложения совместно с ERP-системой.
Проблемы и методы интеграции подробно рассматриваются в современной литературе. Так, например, в [9] авторы сравнивают четыре подхода, основанные на: 1) передаче файлов; 2) общей базе данных; 3) удалённом вызове процедур; 4) обмене сообщениями. В [10] рассматривает практика «Непрерывной интеграции» которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.
На сегодняшний день наиболее обсуждаемыми являются следующие принципы интеграции информационных ресурсов: интеграция информации предприятия (Enterprise Information Integration, EII), интеграция корпоративных приложений (Enterprise Application Integration, EAI), преобразование и загрузка данных (Extract, Transform and Load, ETL), интеграция бизнес-процессов (Business Process Improvement, BPI), интеграция между организациями (Busi-ness-to-Business Integration, B2Bi).
Каждый подход имеет свои особенности, преимущества и недостатки. На практике при реализации конкретного проекта используется их сочетание.
Проведём классификацию существующих методов интеграции.
По времени запуска:
1. Реального времени - если данные должны быть обновлены немедленно после изменений.
2. Отложенная - если процесс синхронизации данных запускается по какому либо событию во времени или по расписанию.
По способу анализа информации:
1. По текущему состоянию - сравнение записей одной таблицы с записями другой, и на основании этого принимается решение о синхронизации,
2. Дельта-репликация - если в базе предусмотрен журнал вносимых изменений в БД, и алгоритм репликации переносит изменения по дельтам изменений, накопленным в журнале [11].
По направлению интеграции:
1. Односторонняя - если данные изменяются только в одном приложении, а в другой данные только хранятся и не подвергаются изменениям.
2. Многосторонняя - если данные могут изменяться и вводиться во всех приложения.
По уровню интеллектуального анализа:
1. Синтаксический анализ. Основывается на внешнем сходстве объединяемых данных.
Например, при объединении двух таблиц мы предполагаем, что в поле «Номер договора» все записи имеют схожий формат «Договор № 345». Однако если в одной таблице в этом же поле дополнительно указывается дата договора «Договор № 345 от 15.05.2010», а в дру-
гой таблице выделено отдельное поле «Дата договора», необходимо обеспечить интерпретацию данных из одного вида в другой.
2. Семантический анализ. Основывается на сравнении данных на содержательном уровне.
Данный подход предполагает передачу вместе с данными также и их описание - мата-данные. Семантическая интеграция основывается на знании и учёте природы данных. Основой семантической интеграции стала реализация онтологического подхода. При этом связь между элементарными единицами данных осуществляется в соответствии с их определением в онтологии.
В настоящее время наряду с решением вопросов интеграции информационная архитектура должна обеспечивать беспрепятственное добавление в интегрированную среду новых систем. Этому требованию удовлетворяет сервис-ориентированная архитектура (Service-Oriented Architecture, SOA). Которая представляет собой парадигму, основанную на превращении функций и компонентов информационных систем в «сервисы», к которым можно обратиться через стандартный интерфейс независимо от местоположения или технической составляющей функции или части данных. Основой SOA являются протоколы SOAP, UDDI, WSDL и другие, которые изначально использовались лишь в Web-технологиях, однако они были приспособлены под корпоративные системы и стали основой SOA.
Лёгкое подключение к единой среде обеспечивает сервисная шина предприятия (ESB), которая выполняет роль посредника между сервисами и позволяет им обращаться друг с другом независимо от протокола и первоначального формата данных [12].
Таким образом, модуль интеграции данных представляется в виде сервис-ориентированной архитектуры, изображённой на рис. 3.
Рис. 3. Интеграция по принципам 80Л с использованием Б8Б Синхронный и асинхронный обмен сообщениями
Поддержка обмена сообщениями входит в ядро архитектуры ESB. Функциональная часть обмена сообщениями обеспечивается отдельной программной системой, называемой системой обмена сообщениями или связующим ПО, ориентированным на обмен сообщениями (message-orient middleware - MOM). Это концепция обмена данными между приложениями, реализуемого по коммуникационным каналам, несущим отдельные единицы информации (сообщения). Обмен сообщениями - это технология асинхронного взаимодействия при-
ложений с гарантией доставки данных. Большинство приложений использует синхронные вызовы функций; например, процедура вызывает подпроцедуру, один метод вызывает другой или же процедура вызывает другую процедуру через технологию удалённого вызова (CORBA, DCOM, ActiveX) Синхронный вызов требует от вызывающего процесса ожидания завершения выполнения функции подпроцессом (рис. 4.)
Время
Процесс А
Процесс Б
^локирование і Г
Вызова і Возврат
Рис. 4. Синхронный вызов процесса
Асинхронный обмен сообщениями (рис. 5) позволяет наладить взаимодействие между приложениями по принципу «отправил и забыл» (Бепё-апё-Ю^е^. В соответствии с этим принципом отправитель не обязан ожидать подтверждения о получении и обработке сообщения от принимающей стороны. Единственное, что нужно обеспечить, - подтверждение об отправке сообщения, то есть о помещении в канал. Как только сообщение будет передано системе обмена сообщениями, отправитель может приступать к выполнению имеющихся у него задач.
Время
Процесс А
Процесс Б
Сообщение > Г
Рис. 5. Асинхронный обмен сообщениями
Асинхронный обмен сообщениями позволяет создать слабосвязанную среду, в которой приложениям не нужно знать подробности того, где найти другие приложения и как с ними связаться. В сильносвязанной среде каждое приложение должно знать, как следует связываться с каждым другим приложением, количество методов, которое оно экспонирует, и подробности параметров, которые принимает каждый метод. Поскольку количество приложений и сервисов увеличивается, число интерфейсов, которые необходимо создать и которыми нужно управлять, становится громоздким. Число связей между N приложениями можно оценить по формуле N(N - 1)/2.
Основной принцип слабого связывания состоит в уменьшении числа допущений, которые делают друг о друге взаимодействующие стороны (компоненты, приложения, службы, программы, пользователи). В противовес сильносвязанной среде, использование слабосвязанного обмена сообщениями уменьшает количество интерфейсов до почти линейного роста, где число интерфейсов соответствует количеству точек присоединения, так как каждый участник многоэтапного бизнес-процесса должен позаботиться только о том, чтобы передать сообщение в систему обмена сообщениями посредством ЕБВ.
Несмотря на все преимущества асинхронного обмена сообщениями, данный подход имеет ряд недостатков, среди которых можно выделить, во-первых, сложную модель программирования. Асинхронный обмен сообщениями требует от разработчиков использования модели событийно управляемого программирования. В этом случае логика приложения разбивается на множество обработчиков событий, реагирующих на входящие сообщения. Подобную систему гораздо труднее программировать и отлаживать, чем систему, основанную на вызове процедур. Во-вторых, Система обмена сообщениями гарантирует доставку сообще-
ния от отправителя к получателю, не оговаривая время доставки. В результате может быть нарушен порядок сообщений, что требует написания дополнительных функций восстановления очереди. В третьих, не все приложения могут взаимодействовать по принципу «отправил и забыл». Следовательно, в некоторых средах наряду с асинхронным обменом сообщений будет применяться синхронный обмен [9, 12].
Заключение
На основании проведённого анализа можно сделать вывод о разнообразии решений для задачи построения единой информационный среды. Это связано с многочисленными проявлениями неоднородности в информационных системах. Одним из возможных подходов является предлагаемая многокомпонентная модель, основанная на слабосвязанной интеграции корпоративной информационной системы класса ERP и множества разнородных приложений с применением принципов сервис-ориентированной архитектуры и асинхронного обмена сообщениями через сервисную шину предприятия.
Один из этапов реализации данной модели проходит в Югорском государственном университете. Наряду с внедрением контуров и модулей корпоративной информационной системой «Галактика-ERP», сотрудниками Управления информатизации проводится разработка сервисов и интерфейсов интеграции данных из унаследованных и специализированных информационных систем.
ЛИТЕРАТУРА
1. Черняк, Л. Интеграция данных: синтаксис и семантика [Текст] / Л. Черняк // Открытые системы. - 2009. - № 10. - С. 24-30.
2. Бочаров, Е. П. Интегрированные корпоративные информационные системы: Принципы построения. Лабораторный практикум на базе системы «Галактика» : учеб. пособие [Текст] / Е. П. Бочаров, А. И. Колдина. - М. : Финансы и статистика, 2005. - 288 с. : ил.
3. Лесневская, С. В. Автоматизация управления вузом на базе технологий класса ERP [Текст] / С. В. Лесневская // Информатизация образования и науки. - 2010. - № 5. -С. 114-126.
4. Смелянский, Р. Л. Возможности системы «Университет» компании «РЕДЛАБ» для формирования и реализации стратегии развития вуза [Текст] / Р. Л. Смелянский, М. В. Ие-венко // Университетское управление: практика и анализ. - 2004. - № 3(31). - С. 18-25.
5. Семенов, С. П. Автоматизированная система контроля данных по кадровому составу вуза и контингенту студентов [Текст] / С. П. Семенов, Я. Б. Татаринцев // Системы управления и информационные технологии. - 2009. - № 3.2 (37). - С. 279-282.
6. Семенов, С. П. Сравнительный анализ подходов к автоматизации составления расписаний учебных занятий в образовательных учреждениях [Текст] / С. П. Семенов, Я. Б. Та-таринцев // Известия Алтайского государственного университета. - 2010. - № 1-1. -C. 103-105;
7. Date, C. J. What is distributed database? C. J. Date. - InfoDB, 1987.
8. Inmon, W. H. Building the Data Warehouse (Second Edition) [Text] / W. H. Inmon. - NY, New York: John Wiley & Sons. - 1993.
9. Гергор, Х. Шаблоны интеграции корпоративных приложений [Текст] / Хоп Грегор, Вульф Бобби ; пер. с англ. - М. : ООО «И. Д. Вильямс», 2007. - 672 с. : ил.
10. Дюваль, Поль М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска [Текст] / Поль М. Дюваль, Стивен Матиас, Эндрю Гловер ; пер с англ. - М. : ООО «И. Д. Вильямс», 2008. - 240 с. : ил.
11. Евдокимов, А. Репликация базы данных [Электронный документ] / А. Евдокимов. -2001. - Режим доступа : http://replication.chat.ru
12. Шаппелл, Д. А. ESB - Сервисная Шина Предприятия : [Текст] / Д. А. Шаппелл ; пер. с англ. - СПб. : БХВ-Петербург, 2008. - 368 с. : ил.
