Главная страница 
 
О Фонде ФОСТАС 
События 
Семинары 
Конференции 
Программы и Проекты 
Библиотека 
Тезисы 
Доклады 
Материалы проектов 
Презентации 
Об участии 
Работа участников 
Вопросы-ответы 
Контакты 
Форум 
 

Критерии поиска:

в разделе библиотеки:

 


 Перспективы интеграции информационных систем на основе сообщений о событиях

Синяев Игорь Николаевич, отдел информатики и компьютеризации администрации муниципального образования «город Лесной», г. Лесной, Свердловской обл.,  sin@adm.lesnoy.ru, Артамкин Сергей Николаевич, ООО «АСС-Бизнессофт», г. Лесной, Свердловской обл., art@adm.lesnoy.ru

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

Суть проблемы.

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

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

Примеры событий в том ключе как они понимались выше:

  • рождение/смерть человека
  • подготовка и регистрация сделки с объектом недвижимости
  • ввод нового жилого дома в эксплуатацию
  • авария на инженерных коммуникациях
  • и т.д.

Рассмотрим один из вариантов реализации предлагаемой системы обмена сообщениями (далее СОС).

Система состоит из двух частей:

  • центр обработки сообщений СОС
  • клиент участника информационного обмена СОС
  • Модульная структура центра обработки сообщений «СОС» выглядит следующим образом:
  • транспортная подсистема обеспечивает доставку/отправку сообщений через различные протоколы и технологии: email, FTP, HTTP, CORBA, MQ Series, Web-интерфейс (для ввода сообщений о событиях вручную) и т.д
  • подсистема ведения репозитария «СОС» хранит структуру нового входящего сообщения, обеспечивает корректировку и удаление существующей структуры сообщения; хранит правила проверки входящих сообщений на соответствие структуре; предоставляет информацию о структуре репозитария участникам обмена
  • подсистема обработки входящих сообщений получает сообщения от транспортной подсистемы, регистрирует в журнале входящие сообщения; проверяет сообщения на соответствие структуре; осуществляет запись сообщений в хранилище сообщений
  • подсистема формирования исходящих сообщений осуществляет выборку нужных (по регламенту указанному получателем) сообщений из хранилища; формирует на базе отобранной информации исходящее сообщение; регистрирует в журнале исходящих; передает транспортной подсистеме
  • подсистема администрирования входящих сообщений позволяет участнику обмена раздать права другим участникам обмена на получение информации о событиях из сообщений, владельцем которых он является; выбрать формат и способ доставки сообщений; управлять хранилищем своих сообщений в части срока хранения/архивирования/уничтожения сообщений; управлять статистикой о своих сообщениях (кто, когда получил, объем его сообщений в хранилище и т.д.)
  • подсистема администрирования исходящих сообщений установить контакт с владельцами информации хранилища сообщений; после уведомления на разрешение получения информации настроить под себя формат и способ доставки исходящего сообщения; управлять статистикой о полученных сообщениях
  • подсистема ведения статистики осуществляет ведение статистики о проходящих через центр сообщениях в различных разрезах, модуль при необходимости может быть дополнен функциями для осуществления финансовых расчетов между участниками обмена за полученную информацию
  • подсистема публикации сообщений через данный модуль могут быть реализованы новостные web-сайты, электронные и бумажные справочники типа «Что? Где? Почем?» и т.д.

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

  • непосредственно функциональная часть ИС (СУБД и исполняемые модули) как правило совершенно готовая прикладная ИС

И часть модулей «СОС»:

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

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

В течение года был обкатан весьма упрощенный вариант описанной системы. Были достигнуты слебующие результаты:

  • повысилась оперативность информирования о событиях
  • сократился ручной ввод информации на 15-20%
  • системные администраторы ИС, несмотря на повысившийся первоначальный объем работы по настройке системы «СОС», с оптимизмом восприняли данную технологию.

На наш взгляд, для более серьезного подхода к данной проблеме требуется разработка какой-то общепринятой технологии/стандарта. «Кандидатами» в таковые нам видятся:

  • CORBA, в которую надо добавить механизм «отложенных на неопределенный срок транзакций»
  • Объектно-ориентированное программирование, только «наоборот», т.е. во главу технологии ставится событие, а объекты являются свойствами/методами события, а не как в «правильном» ООП.

Назад

 


© 2002 FOSTAS Foundation
Главная страница > Библиотека Карта сайта
Дизайн — Лаборатория НТР