Концепция построения типовой системы ввода,
учета и выдачи информации

В настоящее время значительное внимание уделяется созданию систем ввода, учета и выдачи информации о различного рода документах, информационных ресурсах и системах. К таким системам можно отнести, например, систему “Наука России” (БЕН РАН), СМИРС (ЦИТиС) и многие другие. Все эти системы решают одни и те же задачи, строятся на основе сходных бизнес-процессов и, как следствие, могут быть заменены типовой системой ввода, учета и выдачи информации, настраиваемой под определенную предметную область и определенный круг задач.

В системе “Наука России” [1,2] и производных от нее основное внимание уделено настраиваемости схемы данных. Существует возможность задания произвольных сущностей (таблиц), их полей (на основе фиксированных в системе типов данных) и отношений между ними. При всем этом системы на базе “Науки России” являются системами централизованного типа, с четко выраженным центральным сервером и процессом переноса данных с одного центрального сервера на другой путем процедур импорта и экспорта.

Система мониторинга и анализа государственных информационных ресурсов и систем (СМИРС) Минэкономразвития России ориентирована на определенную узкую предметную область и не представляет возможностей настройки без существенного изменения исходного кода. Кроме того, существующий вариант системы достаточно жестко привязан к определенной архитектуре и подходам к организации клиентских мест – через J2EE/EJB и “толстых” клиентов на основе Java.

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

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

Основная задача ЛК – ввод, редактирование, хранение данных и представление их в форме различных отчетов и справок.

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

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

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

ЛК может использоваться в качестве самостоятельной системы в случае работы с небольшими объемами данных либо с данными, работа с которыми ведется, в основном, в пределах одной организации. При этом ЛК взаимодействует только с пользователями, отвечая на их запросы по протоколу http. Не имеет значения, где при этом находится пользователь и как он осуществляет доступ к системе: с локальной машины (на которой установлен и сам ЛК), через ЛВС (внутри той же организации) или через глобальную сеть Интернет; средства взаимодействия и обмена данными с другими ЛК отсутствуют.

Здесь же стоит отметить, что данная архитектура не накладывает никаких ограничений ни на объем данных, работа с которыми может быть возложена на ЛК, ни на другие его внутренние характеристики. Такие ограничения возникают при выборе методов и средств разработки внутренней архитектуры ЛК, вспомогательных программных средств (таких как СУБД, Web-сервер и т.д.) на этапе проектирования уже конкретной системы.

Для создания более сложных систем имеет смысл применять распределенный подход. В этом случае система строится из нескольких ЛК, объединенных в единую сеть.

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

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

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

РК могут быть связаны с использованием одной из двух схем:

1. интеграция в единое хранилище – импортирование данных из подчиненного компонента в вышестоящий;

2. виртуальная интеграция – данные физически хранятся только в одном РК, передача данных между БД не происходит; поиск и получение информации выполняются с помощью распределенного запроса.

Первую схему предполагается использовать в следующих случаях:

• затруднена передача данных между РК по постоянному каналу (физически нет быстрого доступа в Интернет, предъявляются повышенные требования к безопасности и т.п.);

• данные в нижестоящей организации обновляются достаточно редко и предпочтительнее иметь их экспортированную копию в вышестоящем РК;

• объемы данных в нижестоящей организации достаточно малы (возможно также, что в этом случае нецелесообразно использовать РК, а достаточно предоставить авторизованный доступ для этой организации к вышестоящему ЛК).

Преимуществами второй схемы являются:

• снижение требований к программно-аппаратным комплексам каждого РК в отдельности (вследствие существенного снижения объемов хранимой информации);

• максимальная актуальность получаемых при поиске результатов (т.к. нет промежуточных синхронизаций).

Для реализации второй схемы необходимо дополнить поисковую систему каждого РК модулем поддержки распределенных запросов (на основе технологии XMPP/Jabix). При этом усложняется решение вопросов безопасности.

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

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

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

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

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

Разработку системы целесообразно разделить на четыре этапа, в соответствии с изложенными выше структурными элементами:

1. Разработка полнофункционального ЛК;

2. Разработка РК: добавление к ЛК функций обмена данными между собой;

3. Добавление к РК поддержки распределенного поиска и получения информации на основе технологии XMPP/Jabix;

4. Коммутация РК с различными схемами данных.

Первый этап является основным и наиболее трудоемким. По его окончании мы имеем полнофункциональную локальную систему с on-line доступом.

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

Завершение третьего этапа дает нам возможность сроить системы с виртуальной и смешанной интеграцией. При этом трудозатраты на написание конвертеров для системы Jabix минимальны, т.к. на этом этапе схема данных во всей системе остается единой, следовательно, и все конвертеры одинаковы.

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

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

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

В первом случае задача ведения БД в каждом из РК не представляет особых сложностей; создание конвертеров для импортирования, экспортирования данных и поддержки Jabix можно автоматизировать.

Трудозатраты и возможные проблемы во втором случае пока оценить довольно трудно.

Если сравнить предполагаемый вариант реализации системы (в соответствии с описанной концепцией) и существующие варианты реализации системы “Наука России”, можно отметить следующее:

1. Типовая система является распределенной системой, тогда как “Наука России” - жестко централизованная и любой межсистемный обмен возможен только в ручном варианте (с помощью операций импорта-экспорта).

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

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

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

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

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

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

Литература

1. Каленов Н.Е., Васильев А.В., Власова С.А., Глушановский А.В. Автоматизированная информационная система "Наука России" // Информационно-библиотечное обеспечение науки: Проблемы интеграции информационных ресурсов: сб. статей. – М., 1995. – С. 112-115

2. Якшин М.М. WEB-интерфейс системы "Наука России" // Современные технологии в информационном обеспечении науки. - М., 2003. – С. 47-52