Сетевое издание
Современные проблемы науки и образования
ISSN 2070-7428
"Перечень" ВАК
ИФ РИНЦ = 1,006

МЕТОД СЛАБОСВЯЗАННЫХ БИЗНЕС-КОММУНИКАЦИЙ В ГОМОГЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ

Платонов Ю.Г. 1
1 Федеральное государственное бюджетное учреждение науки Институт систем информатики им. А. П. Ершова Сибирского отделения Российской академии наук, Новосибирск, Россия (630090, Новосибирск, проспект Лаврентьева, 6), должность – младший научный сотрудник лаборатории САПР и А СБИС
Предметом исследований является «Business Community» – технология создания единого информационного пространства для совместной работы нескольких независимых информационных систем, имеющих одинаковую природу данных. Объединенное пространство должно предоставлять возможность динамически включить, либо, наоборот, исключить из него одну или несколько систем без ущерба для остальных и обеспечивать обмен частью информации с гарантией безопасности остальных данных. Технологии, способные обеспечить такое настраиваемое взаимодействие, на рынке в настоящее время отсутствуют. Автор дает обоснование новому методу слабосвязанных бизнес-коммуникаций в системах с одинаковой природой данных, имеющих сервисно-ориентированную архитектуру, описывает технологию разработки Business Community и оценивает ее эффективность, надежность, простоту реализации и перспективы дальнейшего развития. В основе метода лежит технология, основанная на использовании шаблона CQRS. По мнению автора, метод может быть успешно применен для произвольных корпоративных систем, имеющих единую природу данных.
шина сообщений
интеграция информационных систем
command-query responsibility segregation (CQRS)
cервисно-ориентированная архитектура
1. Платонов Ю. Г. Анализ перспектив перехода информационных систем на сервисно-ориентированную архитектуру // Проблемы информатики. – 2011. – № 4. – С. 56-65.
2. Платонов Ю. Г. Разработка мобильных приложений для работы с корпоративными информационными системами // Проблемы информатики. – 2011. – № 3. – С. 15-33.
3. Дейт К. Введение в системы баз данных. – 6-е изд. – М.: Диалектика, 1998. – 563 c.
4. Мейер Б. Методы программирования: в 2 т. / пер. с фр. Первина Ю. А.; под ред. А. П. Ершова. – М.: Мир, 1982. – 786 c.
5. Фаулер М. Архитектура корпоративных программных приложений. – М.: Вильямс, 2006. – 403 c.
6. Юнг Г. Официальный блог [Электронный ресурс]. – Режим доступа: http://codebetter.com/gregyoung/2012/09/09/cqrs-is-not-an-architecture-2/ (дата обращения: 10.01.2013).
7. Bell M. Service-Oriented Modeling: Service Analysis, Design, and Architecture. – NY.: Wiley & Sons, 2008. – 742 p.
8. Bieberstein N., Bose S., Fiammante M., Jones K. Service-Oriented Architecture (SOA) Compass: Business Value, Planning, and Enterprise Roadmap. – NY.: IBM Press, 2006. – 1058 p.
9. Stangland D. Advanced Replication – PINNACLE // Oracle Professional. – April 2002. – № 9, pp. 56-70.
10. World Wide Web Consortium. Официальный сайт [Электронный ресурс]. – Режим доступа: http://www.w3.org/standards/xml/schema (дата обращения: 10.01.2013).

Введение

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

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

Традиционно при решении задач интеграции разработчики прибегают к созданию некой системы, объединяющей в себе две или несколько информационных систем, независимых ранее. Такой подход имеет ряд достоинств, но имеет и ряд трудно устранимых недостатков, что подробно описано в [1].

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

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

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

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

Методы и результаты исследования. В данной статье автор дает обоснование новому методу «Business Community», позволяющему обеспечивать стабильное динамическое взаимодействие нескольких независимых информационных систем, работающих в одном сегменте рынка, в едином информационном пространстве, посредством обеспечения слабосвязанных бизнес-коммуникаций. Автор описывает метод «Business Community» (см.п.1), оценивает его эффективность и перспективы дальнейшего развития (см. п.3). Таким образом, в статье предлагается решение задачи обеспечения настраиваемого информационного взаимодействия между информационными системами.

1. Метод Business Community для систем с сервисно-ориентированной архитектурой

Рассмотрим взаимодействие нескольких клиент-серверных информационных систем, имеющих сходную предметную область [8].

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

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

2. Нескольким компаниям или филиалам одной компании требуется на короткое время объединить часть информации из справочников для совместной работы.

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

Предлагаемый автором метод Business Community призван решить проблему создания настраиваемой интеграции систем. При его использовании полученное объединенное информационное пространство будет обладать следующими свойствами:

· Информационные системы, включенные в объединенное пространство, остаются независимыми;

· Системы могут иметь разное программное обеспечение, но должны описывать сходные реальные объекты (иметь одинаковую предметную область);

· Для общего доступа предоставляется строго определенная часть информации, в то время как остальные данные защищены от просмотра, копирования и редактирования;

· Предоставляемая для общего доступа информация легко конфигурируема;

· Интеграция обеспечивает динамическое добавление и исключение систем из бизнес-сообщества;

· Система защиты исключает несанкционированное добавление новых информационных систем в ранее зарегистрированное бизнес-сообщество.

На рис. 1 представлена общая схема работы бизнес-сообщеста, включающего в себя:

· Центральный сервис обработки, используемый для проверки и обработки сообщений определенного формата (contract), приходящих от отдельных гомогенных информационных систем (членов бизнес-сообщества), формирования запросов и передачи ответов между присоединенными системами по заранее определенным протоколам, с использованием в качестве транспорта шины сообщений. Блок включает в себя динамический репозиторий сервисов-представлений, универсальную сервисную шину для связи с членами бизнес-сообщества, набор данных об инициаторах и типах, ранее созданных бизнес-сообществами, а также сервисы проверки протокола и обработки сообщений. Структура объединенного пространства, созданная с использованием метода Business Community, предполагает использование одного сервиса обработки для всех членов сообщества;

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

· Универсальные адаптеры (фасады) – стандартизированные программные средства для создания для каждой из информационных систем (членов бизнес-сообщества) системной оболочки, предназначенной для стандартизации внешних обращений и изменения функциональной ориентации (‘wrapper’). Адаптеры используются для представления данных системы в форме, доступной центральному сервису обработки. Все адаптеры имеют одинаковые библиотеки, они идентичны друг другу, но имеют различные настройки и данные. Свой универсальный адаптер создается для каждой системы – члена бизнес-сообщества.

 

Рис. 1. Общая схема работы метода Business Community

Каждая информационная система вместе с ее универсальным адаптером формируют т.н. «обобщенный клиент».

Взаимодействие исходной системы с ее адаптером осуществляется посредством специального API, входящего в состав универсального адаптера.

В исходную систему требуется внести лишь незначительные изменения. Необходимо добавить модули коммуникации с этим API, сервисы-оболочки или иные реализации взаимодействия. Все эти варианты подробно описаны в [2].

Сообщения, передаваемые в центральный сервис обработки, представляют собой потоки данных в xml-формате, в которых (помимо служебной информации, такой, как номер системы-члена сообщества), определены также типы данных, подлежащие передаче в центральный сервис обработки обобщенного пространства, и набор критериев (полей) либо для запрашиваемой, либо для предоставляемой информации. Список доступных типов данных, а также набор критериев для каждого такого типа перечисляются в дополнительном xsd файле [10].

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

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

Таким образом, в момент создания конфигурации уполномоченным пользователем одной информационной системы посылается запрос на создание или изменение конфигурации бизнес-группы, в котором определены набор данных, предоставляемый для общего пользования, уровень доступа к ним, уровень визуального контроля при попытке другой информационной системы получить предоставленные данные (рис. 2) (автоматический либо с участием уполномоченного пользователя), набор значимых полей или критериев поиска, а также круг потенциальных пользователей данных. Здесь важно отметить, что в случае предоставления данных для информационных систем, имеющих программное обеспечение, отличное от программного обеспечения предоставляющей системы, в качестве критериев поиска можно использовать наборы перечислений (такие, как пол человека, сфера деятельности, и.т.д.), определенные в xsd файле[10] и обрабатываемые всеми включенными системами.

Новый «обобщенный клиент» представляет собой модификацию архитектурного шаблона CQRS [6][4]. Публичная часть шаблона CQRS в «обобщенном клиенте» перенесена в сервис преобразования («Преобразователь сообщений» в универсальном адаптере). Данные в сервисе доступны только для чтения, адаптированы согласно наборам перечислений, заранее определенным в центральном сервисе, и отфильтрованы согласно условиям созданной бизнес-группы. Синхронизация данных сервисом «преобразователем сообщений» с информационной системой происходит через API.

Интеграция системы с блоком преобразования, изображенная на рис. 1, зависит от типа системы и более подробно описана в [2].

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

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

 

Рис. 2. Схема последовательностей регистрации системы в существующее сообщество

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

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

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

2. Обоснование метода

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

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

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

· Частичной репликации данных [9], [7];

· Создание центра управления данными;

· Метод импорта – экспорта требуемых данных с визуальным контролем.

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

В случае создания центра управления данными мы получаем некоторую обобщенную систему, где серверная часть реализована в качестве интеллектуального центра, а системы-члены будут являться укрупненными клиентскими приложениями со своими наборами справочников. Метод несколько напоминает предлагаемый автором, но в отличие от Business Community он обеспечивает только статическую, не настраиваемую интеграцию, в результате которой (в общем случае) системы-члены сообщества теряют независимость. В этом случае все запросы на получение информации и ее обновление следует рассматривать в клиент-серверной терминологии [5]. Из положительных сторон этого метода можно отметить скорость получения информации и отсутствие ее дублирования. Из минусов – негибкость ввиду отсутствия возможности исключить систему-члена из одного сообщества и добавить в другое. И главное, что начав участвовать в подобных сообществах, приходится полагаться на корректную работу системы безопасности сервера и соблюдение конфиденциальности.

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

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

Внедрение метода Business Community, разработанного для обеспечения гибкого взаимодействия предприятий – членов сообщества, позволяет повысить конкурентоспособность каждой из систем, поскольку позволит им оптимизировать производственные процессы, объединяясь во временные группы.

По наблюдениям автора, подобных решений на рынке нет, но потребность в них назрела.

3. Оценка эффективности метода

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

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

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

· Необходимость проектирования и разработки только одного серверного приложения для обмена сообщениями;

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

· Неизменность внутренней архитектуры системы при вводе/выводе системы из объединенной системы;

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

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

В то же время при проектировании системы с использованием метода Business Community следует принимать во внимание специфику обработки данных с точки зрения времени отклика системы. В основе метода лежит некоторая сеть независимых сервисов. Систему – член сообщества – в данном контексте можно также рассматривать как некий укрупненный сервис.

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

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

Применение метода наиболее эффективно в случаях, когда необходимо создать единое информационное поле для нескольких компаний, работающих в одной области. Например, компания Recruitment Systems Pty Ltd (Австралия) была заинтересована в разработке объединенного бизнес-пространства для своих клиентов. Соответственно, в качестве экспериментальной площадки в настоящее время используются несколько кадровых агентств Австралии, каждое из которых применяет для производственных нужд информационную систему TRIS и хотело бы обмениваться со своими коллегами открытой частью своей коммерческой информации (в ряде случаев это позволяет заметно ускорить подбор кадров для нужд клиентов, т.е. извлечь значительную финансовую выгоду), сохраняя при этом полную автономность и не рискуя неприкосновенностью остальных данных.

Заключение

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

В статье также исследованы и как результат положительно охарактеризованы производственные характеристики метода – надежность, простота реализации и экономическая эффективность.

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

В настоящее время метод проходит апробацию при разработке приложения ‘TRIS Business Community’ (рабочее название) в компании Recruitment Systems Pty Ltd (Австралия).

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

Рецензенты:

Марчук Александр Гурьевич, доктор физико-математических наук, профессор, директор Федерального государственного бюджетного учреждения науки Институт систем информатики им. А. П. Ершова Сибирского отделения Российской академии наук, Федеральное государственное бюджетное учреждение науки Институт систем информатики им. А. П. Ершова Сибирского отделения Российской академии наук, г. Новосибирск.

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


Библиографическая ссылка

Платонов Ю.Г. МЕТОД СЛАБОСВЯЗАННЫХ БИЗНЕС-КОММУНИКАЦИЙ В ГОМОГЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ // Современные проблемы науки и образования. – 2013. – № 1. ;
URL: https://science-education.ru/ru/article/view?id=8263 (дата обращения: 29.03.2024).

Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»
(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)

«Фундаментальные исследования» список ВАК ИФ РИНЦ = 1,674