Гайсин Р.Р., Шараев А.Г.
МУП «МИТЦ» ГО (Уфа)

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

Рис 1. Поставка данных, с учётом необходимой функциональности (топология «точка-точка»)

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

Хотелось бы понять, как именно ФНС смогло бы обеспечь своевременное информирование всех заинтересованных в такой информации лиц? Ведь наличие актуальной информации непосредственно влияет на экономическую безопасность, как любого профильного подразделения, так и муниципалитета или субъекта федерации в целом.

Хотелось представить хотя бы примерные технологические и, как следствие, экономические затраты на организацию такого взаимодействия при использовании схемы «прямого информирования» (точка-точка).

Рис 2. Техпроцессы поставки данных (рассылки обновления), возникающие при изменении данных (топология «точка-точка»)

В случае обнаружения долгов данного юридического лица видимо необходимо приостановить ликвидацию предприятия, путём информирования ФНС о наличии у юридического лица долгов перед бюджетом.

В этом случае возникают «обратные связи».

Рис 3. Поставка данных с организацией «обратных связей» (взаимодействие)

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

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

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

Рис 4. Организация полного взаимодействия (топология «точка-точка»)

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

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

Рис 5. Организация двустадийной обработки данных (топология «звезда»)

Но интеграция это не просто «перевалочный пункт», это, прежде всего, синхронизация данных от различных поставщиков (в различных форматах!), их проверка и консолидирование.

Рис 6. Интеграционная технология с применением двустадийной обработки данных (топология «звезда»)

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

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

Рис 7. Технологические и экономические затраты ИС-доноров и интегратора

Интеграционное взаимодействие это медленно?
Якобы без интеграции возможно взаимодействие в «живом режиме», т.е. как только кто-нибудь где-нибудь, что-то изменил тут же всё это видят остальные. Это заблуждение. Всё равно, для того чтобы выявить изменение данных в одной ИС и отправить его в другую ИС (а там ещё и принять!) потребуются не малые вычислительные ресурсы. Так как для того чтобы отправлять «каждый чих» пользователей сразу всем потребителям данных потребуются высокоскоростные постоянно доступные каналы связи, то такой способ взаимодействия очень сложен, дорог и не целесообразен.

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

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

Почему нельзя «посадить всех на одну единую крупную (корпоративную) ИС»?
Почему ещё сложнее такой процесс для единой муниципальной ИС?

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

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

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

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

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

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

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

Центральный Концентратор Реестровых Данных
Центральный Концентратор Реестровых Данных проект, венцом которого стало ядро Data Manipulation Core. Данное ядро имеет в себе все вышеописанные функции:
входной контроль данных;
преобразование данных;
синхронизация и выверка данных;
контроль ключевой целостности данных;
контроль данных на соответствие установленным форматам данных;
размещение данных в интегрирующем хранилище;
выборка данных по подпискам, с учётом имеющихся расписаний и регламента, контроль исполнения Регламента;
контроль исполнения сеансов обмена данными согласно Регламента,
специализированная многоролевая система контроля прав доступа;
система управления и контроля приоритетов (в случае приоритетного разграничения права редактирования данных для различных организаций, имеющих равные права доступа информационному реестру);
синхро-асинхронная обработка клиентских запросов;
асинхронная обработка долговременных крупных запросов и пакетов обновлений;
не отключаемый системный историзм информационных объектов и ролевых связей информационных объектов;
возможно организации различных древовидных и сетевых справочников, в том числе и с многоролевыми отношениями.

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

Унифицированный формат обмена данными
Унифицированный Формат Обмена Данными это фактически соглашение по разметке структурированных данных определённым способом. Естественно основой соглашения стал широко известный формат XML. Данное соглашение позволило разработать конвертеры данных. Фактически конвертер данных преобразует данные из одной структуры (одного формата данных) в другую структуру, данные в обеих структурах (в обоих представлениях) соответствуют формату УФОД.

Формат УФОД не является каким-либо стандартом, минимально необходимым для организации взаимодействия различных ИС. УФОД не содержит в себе конкретные инструкции по тому, как именно структурно размечать те или иные данные. Структура данных, представленных в УФОД XML может существенно различаться, непосредственно отражая ту или иную структуру данных ИС-поставщика или ИС-получателя данных.

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

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

Фактически клиентское ПО не то чтобы не ждёт ответа от сервера, а в обязательном порядке его получает. Таким образом, клиентское ПО не зависает в случаях, когда пользователи отправляют сложные поисковые запросы и ожидают большого количества данных.

Также для отображения результатов поиска применяется постраничное порциональное разбиение результатов поиска. При этом сервер данных имеет в памяти полный результат поиска, но на клиенте отображается только страница, запрошенная в данный момент пользователем. Это также резко уменьшает время отклика клиентского ПО, ведь клиентская часть DMC не ожидает огромного количества данных, а потому не тратятся системные ресурсы на упаковку в УФОД XML данных и транспортную накладки между клиентом и сервером. Подобная оптимизация работы жизненно важная необходимость.

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

Запрос в очереди также может удалится и автоматически. Любому клиентскому запросу даётся 15 попыток, время на каждую следующую попытку каждый раз увеличивается. В случае если за 15 временных попыток выполнения процесса, процесс так и не получил результатов, то данный процесс удаляется из очереди вообще. Все занятые им ресурсы высвобождаются.

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

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

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

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

Российская информационная инфраструктура (рекомендуемая интеграционная модель)

Рис 8. Предполагаемая общероссийская интеграционная информационная инфраструктура (ОИИИ) (топология «многокаскадная звезда»)

ЕГИИС единая государственная интегрирующая информационная система.
РИИС региональная интегрирующая информационная система.
МИИС муниципальная интегрирующая информационная система.
ВИС ведомственная информационная система.
АРМ автоматизированное рабочее место.

Как будет происходить синхронизация данных посредством интегрирующей инфраструктуры?

Рис 9. Обновление связанных данных (или рассылка обновлений) при использовании ОИИИ

Например, сотрудники федерального и регионального ведомства интересует адресный реестр РФ.
Конечное ведение адресного реестра осуществляет муниципальный служащий. Допустим, что сегодня служащий изменил наименование улицы в городе.
Благодаря тому, что служащий работает в ведомственной ИС (ВИС), данное изменение сразу же сохраняется в ВИС и доступно сотрудникам его ведомства.
Благодаря имеющейся муниципальной интегрирующей ИС, в туже ночь о данном изменении становится известно МИИС.
Под утро МИИС информирует о данном изменении все ВИС муниципалитета и региональную ИИС. (Задержка обновления до ближайшего утра)
Утром сотрудник другого муниципального ведомства уже знает об изменении благодаря информированию из его ВИС, и, к примеру, приступает к замене адресного аншлага.
РИИС в следующих сеансах синхронизации данных информирует об этом изменении ЕГИИС и региональные ВИС. (Ещё сутки)
ЕГИИС информирует об этом изменении, как ВИС федерального уровня, так и региональные ИИС других регионов. (Ещё сутки)
Далее данное изменение отправляется в МИИС муниципального уровня, и в региональные ВИС соответствующих регионов. (Ещё сутки)
Итак, о переименовании улицы все заинтересованные лица в стране узнали за неделю*!

ИИС «следят» не за всеми данными всех ИС, а только за базовыми данными, необходимыми сторонним организациям.

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

В плане реализации РИПД есть заинтересованность в консолидации пространственных данных из муниципальных геоинформационных систем (МГИС) всей России.

*Неделя в случае развёртывания ежедневной синхронизации всех серверов. При еженедельной синхронизации серверов процесс займёт 2 месяца