CC BY
96
л )
о
PQ •<
PLh
И
К
t-ч
О
Ч
ас ££
к
о щ
о
м
Ли/пу/нщоВ ПаВлоВин,
Жёомросу об интеграции гос/ударс/тВен/ных и/нформацшунмыж систем
Межведомственный характер административных процессов предполагает активное взаимодействие ведомственных информационных систем, как в горизонтальном направлении, так и по административной вертикали. Взаимодействие информационных систем реализуется с использованием технологий интеграции. Особенности информационного пространства государственного сектора требуют серьезной адаптации подходов, используемых при интеграции корпоративных информационных систем.
Интеграция, информационное пространство, взаимодействие, государственный сектор.
ведение
Межведомственный характер административных процессов предполагает активное взаимодействие ведомственных информационных систем, как в горизонтальном направлении, так и по административной вертикали. Взаимодействие информационных систем реализуется с использованием технологий интеграции. В области интеграции информационных систем накоплен значительный опыт в корпоративном секторе. Особенности информационного пространства государственного сектора требуют серьезной адаптации подходов, используемых при интеграции корпоративных информационных систем. Связано это в том числе с безопасностью и организацией доступа к персональным данным.
Следует отметить, что интеграция - достаточно сложная процедура, в которой решения в области технологического слоя тесно связаны с особенностями слоя данных. Два слоя архитектуры, отражающие виртуальную реальность, данные и технологии, оказывают существенное влияние друг на друга. Поэтому этап планирования интеграции, выбор архитектурного шаблона играет важную роль как инструмент для описания концептуальной схемы взаимодействия систем.
Предоставление государственных электронных сервисов в электронном виде может включать разные модели интеграции. В зависимости от типа необходимой информации, исходных или агрегированных данных, частоты запросов, пропускной способности каналов передачи разрабатывается архитектура интеграции, где определяются модели и технологии. Таким образом, на предварительном этапе создания среды интеграции описывается шаблон, который в последующем будет наполняться функциональными компонентами, выполняющими определенные функции.
Рассмотрим основные классы моделей интеграции. При описании моделей будем акцентировать внимание на двух слоях архитектуры: данные и приложения.
Модели интеграции
В литературе по интеграции встречаются разные типы классификации архитектуры интеграции [SOA integration1,Giordano 2011]. За основу рассмотрения методов классификации возьмем работу [Giordano 2011], в которой выделено четыре типа интеграции: интеграция на уровне приложений, федеративная модель, создание единой базы данных и сервисно-ориентированная архитектура.
1 В [SOA integration, 26 стр.] выделяется четыре класса архитектуры интеграции приложений (точка - точка, хаб, шина, сервисно-ориентированная архитектура) и три типа интеграции данных: федерация, популяция и синхронизация. Федерация предполагает предоставление доступа пользователю ко всем источникам исходных данных через единый интерфейс на основе схемы метаданных, популяция аналогична схеме ETL, синхронизация предполагает двунаправленное движение данных для отражения изменений, происходящих в одном из источников, на все остальные.
Интеграция на уровне приложений
Интеграция на уровне приложений (Enterprise Application Integration; EAI) подразумевает попарное соединение приложений и предполагает создание адаптера для взаимодействия между каждой парой систем. Адаптер формирует запрос к сопредельной системе, переводит данные, полученные в результате запроса, к сопоставимому виду и загружает данные. Использование этой модели интеграции целесообразно, когда есть необходимость достаточно быстро установить взаимосвязь между двумя системами. Узким местом этого метода являются ограниченные возможности на распространение написанного адаптера для аналогичных приложений. При написании адаптера учитываются конкретные условия применения этого программного обеспечения для межсистемного взаимодействия, и не ставится задача написания универсального продукта, пригодного для всех возможных вариантов. Это решение целесообразно, когда существует ограниченное количество систем и соединений, не предполагается существенная модификация систем.
На рис. 1 показана схема взаимодействия систем трех ведомств в рамках оказания электронной комплексной услуги «Рождение ребенка».
Услуга 1. Государственная регистрация рождения
Запрос по услуге 4 к ИС ЗАГС
Услуга 4. Выдача страхового полиса
•v , , 0МС
Услуга 2. Запись в паспорт
родителей информации о ребенке
Услуга 3. Постановка на учет по
месту жительства
Рис. 1. Взаимодействие между системами при выполнении отдельных этапов услуги
«Рождение ребенка»
Слой данных: Этот тип интеграции не предполагает выделение слоя данных: формирование запроса к данным, проверка их качества, преобразование и публикация соединены с кодом адаптера.
Слой приложений: положительным моментом этого метода является то, что при интеграции не затрагиваются функциональность и архитектура существующих систем. Вместе с тем отсутствуют стандарты на написание адаптеров [SOA integration, 28 стр.].
Федеративная модель интеграции
Федеративная модель интеграции предполагает взаимодействие систем путем организации взаимодействия на уровне метаданных. Более совершенные варианты реализации этого метода интеграции предполагают создание системы управления базой метаданных. Пользователям такой системы предоставляется единый интерфейс для выполнения операций с данными в локальных базах данных, даже если локальные базы данных неоднородны.
Для предоставления таких возможностей пользователям в системе управления метаданными реализуются инструменты для декомпозиции запроса пользователя на подзапросы к локальным СУБД, после чего система представляет пользователю композитный результат на основе наборов данных, полученных по подзапросам. Поскольку различные системы управления базами данных могут использовать различные языки запросов, федеративная система базы данных включает модуль для перевода подзапросов на соответствующие языки запросов.
Выделяется несколько уровней развития схемы интегрирования баз данных с использова-
И О U3
о
я и
СП
>
О ■п К
¡=1
•по
>■
bd О
1
Ц ||
л )
о
PQ •<
PLh
И
К
U-i О Ч
ас ££
к
о щ
о
м
нием метаданных1.
Первый уровень предполагает выполнение набора операций с использованием модели метаданных локальных систем. В этом случае для каждой операции составляется своя схема связи данных (mapping).
Второй уровень предполагает построение общей модели данных, где отражаются элементы всех локальных схем данных. Построение общей модели позволяет решить вопрос семантической связи между локальными базами.
Третий уровень позволяет реализовать экспорт схемы локальной базы данных в обобщенную модель. Таким образом, решается вопрос миграции локальных схем. Этот уровень включает в себя контроль доступа к информации со стороны отдельного пользователя федерации.
Четвертый уровень предполагает экспорт схемы данных и интеграцию данных на основе полученных схем. Центральная база содержит информацию о распределенных данных, которые доступны для пользователей.
Пятый уровень предполагает более гибкое управление правами пользователей, когда для определенного класса пользователей создается своя схема данных отдельного приложения с учетом прав доступа этой категории пользователей. Для группы пользователей определяется схема интеграции наборов данных, доступных для этой категории пользователей.
На рис. 2 показана схема взаимодействия по принципу федерации интеграции ведомств в рамках оказания электронной комплексной услуги «Рождение ребенка» (адаптировано [Борисов 2010]).
ПО интеграции
по принципу
федерации
\
Услуга 1. Государственная регистрация рождения
Услуга 2. Запись в паспорт
^—________—' родителей информации о ребенке
Услуга 3. Постановка на учет по месту жительства
Рис. 2. Организация межведомственного взаимодействия по принципу Федерации
Слой данных: В основу взаимодействия систем положена организация связей на уровне метаданных. Схема метаданных занимает центральное место модели, возможность оперирования схемой предопределяется уровнем зрелости модели интеграции. При этом физические данные остаются в локальных системах. Поэтому этот метод интеграции целесообразно использовать в тех случаях, когда нет возможности организовать хранение физических данных по технической, юридической или другой причине, а также существуют причины для сокращения числа копий физических данных, в том числе для обеспечения безопасности данных.
Слой приложений: При данном методе интеграций достигается независимость приложений, снижается сложность организации взаимодействия по сравнения с использованием адаптеров для каждой пары систем. Узким местом этого метода интеграции является управ-
1 http://en.wikipedia.org/wiki/Federated
24
system
ление быстродействием. Для получения ответа на запрос пользователя системе необходимо выполнить декомпозицию запроса, получить данные от локальной системы проверить их качество, выполнить трансформацию и опубликовать ответ. На это требуется определенное время. Если пользователем является система, выполняющая определенный административный процесс и для исполнения процесса определено приемлемое время, то какой метод интеграции может быть использован.
Если пользователем является человек, то это может быть ограниченный круг пользователей со специфическими задачами, в том числе аналитического характера. Поэтому следует учитывать, что эта модель интеграции позволяет организовать взаимодействие связанных систем в режиме, близком к режиму реального времени, но для выполнения он-лайн транзакций скорее непригодна.
Создание единой базы данных (ETL)
Интеграция путем сбора данных в центральном хранилище (Extract, Transform, Load; ETL) реализуется путем сбора и агрегирования данных локальных систем, как показано на рис. 3. Формирование единой базы данных на основе данных, полученных из различных источников, производится с целью составления отчетности, проведения аналитики и предоставления данных для выполнения отдельных транзакций. В результате преобразования данных могут быть получены новые данные, которые не присутствуют в исходных данных в явном виде, например агрегированные данные. В результате создания единой базы формируется массив данных большого объема, однако на сегодня это не является ограничивающим фактором.
1. Получение данных из ведомственных систем
2. Выполнение операций после получения всех необходимых данных из локальных систем
3. Загрузка соединенных данных в базу
Услуга 1. Государственная регистрация рождения
Услуга 2. Запись в паспорт родителей информации о ребенке
Услуга 3. Постановка на учет по месту жительства
Услуга 4. Выдача страхового полиса ОМС
Mather Father
Person
Family Name Given Name Gender Citizenship
и
City
Country of Birth Place of Birth Date of Birth
Insurance
Contract Date of issue
Medical institutions
Type
Agency of issue
Рис. 3. Схематичное представление услуги «рождение ребенка» с использованием интеграции в центральной базе
i
И О
m
о
s s
и
Sern >
о ■-п s
Слой данных: При реализации этого метода интеграции слой данных имеет определяющее значение. На втором этапе (рис 3.) в традиционном варианте выполняется интеграция бизнес- и технических метаданных. С развитием технологий интеграции комбинирование данных должно предусматривать интеграцию XML форматов и неструктурированных данных.
Слой приложений: Одной из сложностей, возникающих при реализации этого метода, является управление выполнением разных процедур с данными, загруженными в центральную базу, в частности таких операций, как загрузка данных, очистка, модификация. При их реализации необходимо описывать последовательность формирования массива данных из разных источников. Этапы очистки и модификации предполагают изменение данных в центральной базе, и эти изменения должны производиться асинхронно от загрузки.
Приложения интеграции по технологии ETL предполагают задержку по времени между выполнением операции и занесение ее в центральную базу, поэтому этот вид приложений не может быть реализован для поддержки он-лайн транзакций [Giordano 2011, стр.15].
Сервисно-ориентированная архитектура
Сервисно-ориентированная архитектура представляет собой модель интеграции данных
¡=1
•по
>■
bd О
1 V
на основе маршрутизации и оркестровки сообщений на создание информационных объектов.
О
PQ •<
PLh
И
К
U-I
О
Ч
ЕВ
К
о öd о м
Услуга 4. Выдача страхового полиса ОМС
Услуга 1. Государственная регистрация рождения
Услуга 2. Запись в паспорт родителей информации о ребенке Услуга 3. Постановка на учет по месту жительства
Рис. 4. Схематичное представление услуги «рождение ребенка» с использованием сервисной архитектуры
Слой данных. SOA представляет собой технологическое решение интеграции на следующем уровне абстракции по сравнению с моделью парных взаимодействий. При переходе на следующий уровень абстракции скрываются слой исходных данных и технологические особенности систем, в которых эти данные находятся.
Слой технологий. SOA представляет собой интеграционную шину (Enterprise Service Bus), посредством которой осуществляется взаимодействие между системами, когда каждая система может взаимодействовать с любой другой ИC для обмена данными и функциями. Такая архитектура интеграции позволяет подключать новые информационные системы.
Рассмотрим отдельные особенности интеграции государственных информационных систем посредством сервисов. Если посмотреть на количество административных процессов и количество запросов, необходимых для выполнения этих процессов, то все это многообразие создает достаточно емкий шерстяной клубок (hairball).
Пользователи
(МВД России) (МИД России^ ЗАГС УФМС ) ( CK ОМС )
Ведомственные АИС и реестры
Источник: Адаптировано [Schmidt 2010, стр. 337]
Рис. 5. Сервисы в SOA создают шерстяной клубок
Помимо того, что совокупность сервисов требует правильной интерпретации полученных результатов, могут возникнуть сложности при совместном использовании разрозненных наборов данных. Недостаток интеграционного решения в форме веб-сервисов проявляется и при необходимости дальнейшей совместной обработки пакетов данных, полученных из одного источника с помощью отдельных сервисов. Для их корректного связывания необходимо взаимодействие с источниками данных.
Рассмотрим это на примере. Предположим, система аккредитации пользователей на дисциплины виртуальной среды обучения имеет следующую модель данных.
Рис. 6. Схема данных локальной системы
Пусть приложение позволяет посредством сервисов получить три пакета данных:
- аккредитованные пользователи на курсы;
- аккредитованные группы на курсы;
- состав групп.
Необходимо сформировать ведомость студентов по определенной дисциплине. Представленных трех сервисов для выполнения этой задачи будет недостаточно. Сервисы содержат достаточно данных, но для установления правильного соотношения между пакетами данных необходимо знать тонкости схемы данных источника, такие, например, как «преподаватель не является членом группы», «один студент может быть в нескольких группах» и т.д. Не владея схемой данных, необходимо будет заказать новый сервис.
Для разрешения этих проблем нужно создавать дополнительные модели, которые дадут представление о моделях данных локальных систем. При реализации проектов по интеграции в корпоративном секторе архитекторы систем к «бизнес»-сервисам, которые поставляют наборы данных для конкретных этапов процессов, добавляют сервисы по представлению модели данных в локальных системах. Как правило, это модели логического уровня, на основе которых составляется каноническая модель данных интегрированной системы.
«Такая схема или модель включает в себя критически важные для предприятия данные и их связи. Модель публикуется в формате, позволяющем организовать доступ пользователей к ней независимо от основного приложения. Это позволяет создать сервисы для чтения и записи этих логических канонических моделей. В идеальном случае совокупность элементов, состоящая из канонической схемы и основных сервисов по поставке данных, включая чтение и запись данных в физических системах, будет функционировать как обычная реляционная база данных, а виртуальная база данных будет охватывать все информационные системы, которые необходимы для выполнения запроса пользователя» [Schmidt 2010, стр. 337].
Создание и поддержание в актуальном состоянии виртуальной модели данных требуют детальной проработки темы семантики данных при интеграции. Среди разделов этой темы есть разделы, которые требуют активного участия сотрудников, обладающих предметными знаниями в области ключевых административных процессов. Сюда попадают, в частности, такие вопросы, как описание процесса, представление его стадий, предполагаемая частота обновлений, существующие юридические ограничения, доступ к актуальным данным сопредельных систем, правила связи с сопредельными системами, модели метаданных сопредельных систем, правила взаимодействия с ними.
В таком случае пользователи интеграционного сервера получат возможность обращаться
И О U3
о
я и
СП
>
О ■п К
¡=1
•по
>■
ьа
О
к данным напрямую путем создания запросов к базе данных в дополнение в веб-сервисам, которые публикует приложение. При этом возможности отдельных пользователей регулируются управлением прав доступа. Схема взаимодействия пользователя с данными будет выглядеть следующим образом (рис. 7).
Пользователи
(МВД России)(мИД Россйи)( ЗАГС УФМС ) ( CK ОМС )
Ведомственные АИС и реестры
Источник: Адаптировано [Schmidt 2010, стр. 338]
Рис. 7. Каноническая модель и сервисы доступа к данным в SOA
К
I—I
о ев
к о
ЕП О
М
Следует отметить, что в статье ставилась задача рассмотрения типов интеграции и не были затронуты отдельные этапы интеграции, такие как получение данных, контроль качества, трансформация, загрузка. Помимо этого, существенными являются вопросы, связанные с формирование организационной единицы, ответственной за интеграцию и накапливающей опыт в области интеграции. Опыт корпоративного сектора по созданию центров компетенций в области интеграции и постановка интеграции как одной из базовых, постоянно совершенствующихся разделов стратегии организации представлены в [Schmidt 2005, Schmidt 2010].
Выводы
С развитием информационных технологий происходит сращивание или взаимопроникновение технологий интеграции. В [Giordano, 2011, стр. 15] отмечается, что с развитием технологии Change Data Capture (CDC) и активном их использовании различия между EAI и ETL будут размываться.
В [Art of EIA, стр. 224] построение виртуальной схемы метаданных (federate) наряду с трансформацией и репликацией рассматривается как отдельный самостоятельный этап процесса интеграции. «Целью этапа "федерация" является предоставление единого виртуального образа всех систем источников данных. Возможности этапа имеют тесную связь с возможностями SOA приложений. При проектировании таких приложений требуется агрегированная, качественная информация от совокупности всех источников. Кроме того, с ростом интереса к таким технологиям, как грид и облачные вычисления, "федерация" может стать гораздо более распространенной технологией, чем в настоящее время».
С учетом этого из представленных типов интеграции можно выделить два базовых варианта - это интеграция с загрузкой данных в единую базу данных и виртуальная интеграция путем построения канонической модели данных, позволяющая работать с данными локальных систем.
Доминирующей технологической схемой интеграции является взаимодействие через интеграционную шину, которая позволяет организовать взаимодействие разнородных приложений путем предоставления совокупности сервисов. Интеграция, реализуемая через взаимодействие на уровне приложений, при современном уровне технологий становится частным случаем
одного из этих типов.
Использование сервисно-ориентированной архитектуры как инструмента интеграции государственных информационных систем без дополнительных сервисов скрывает слой данных, что делает использование этой технологии в случае масштабной интеграции проблематичным.
Для разрешения этой проблемы необходимо инициировать проекты по разработке канонической модели данных для кластеров государственных информационных систем, используя в том числе зарубежный опыт [ASDM], а также отечественные наработки по проектам [СЭВ МЭМ], и дополнять этими моделями решения по интеграции. Наиболее актуально это для региональной информатизации - в каждом регионе выполняются идентичные операции и возможно создание рамочной схемы данных логического уровня.
Литература
Борисов 2010 - Борисов А. В. Организация предоставления электронных услуг в регионе. Software AG & IDS Scheer CNews FORUM 2010.
СЭВ МЭМ - К. Жигунов, А. Фишер Информация - это главное http://ui.mos.nu/ru/projects/city infrastructure/mem/index.php?id18=40.
Art of EIA - The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight M. Godinez, E. Hechler, K. Koenig, S. Lockwood, M. Oberhofer, M. Schroeck, IBM Press 2010.
ASDM - Asset Description Metadata Schema: Towards a common language for describing e-Government metadata. http://www.semic.eu/semic/view/documents/ISA Programme-ADMS-Brochure.pdf.
Giordano 2011 - Giordano Anthony David, Data Integration Blueprint and Modeling Techniques for a Scalable and Sustainable Architecture, IBM Press 2011.
NSTIC National strategy for trusted identities in cyberspace www.dhs.gov/xlibrary/assets/ns tic.pdf.
Schmidt 2005 John Schmidt, David Lyle, Integration Competency Center: An Implementation Methodology; Informatica Corporation, 2005.
Schmidt 2010 - John G. Schmidt, David Lyle; Lean Integration: An Integration Factory Approach to Business Agility, Addison-Wesley 2010.
SOA integration - G. Schmutz, D. Liebhart, P. Welkenbach; Service Oriented Architecture: An Integration Blueprint, A real-world SOA strategy for the integration of heterogeneous Enterprise systems, Packt Publishing 2010.
И О
pq о
s я и
Ш >
О ■п К
¡=1
•по
>■
bd О
