Служба распространения данных осуществляет сбор, накопление и доставку данных в точку согласно Каталогу распространения (точка назначения, перечень данных, регулярность доставки – по событию, по расписанию). Механизмы взаимодействия – push по HTTP, SOAP, FTP и WebDAV. Обеспечивает следующие виды распространения данных и продукции на множество FTP-серверов согласно подписке и перечню данных:

-  глобальное распространение данных, Со стороны внешних пользователей назначаются точки доставки (FTP-сервер, WebDAV-сервер) и вид распространения при обновлении данных, по расписанию, по запросу);

-  распространение данных в НЦ. Фиксируется перечень источников данных и продукции Р-ИСВ и вид распространения (при обновлении данных, по расписанию) в FTP-сервера на стороне НЦ;

-  распространение данных в вышестоящий ГЦИС (с узла ЦСДП). Схема аналогична НЦ, значительно расширен набор данных.

Загрузка, агрегация и реформатирование данных из транспортного формата в другой (CVS, ASCII, XML и т. п.) выполняется службой загрузки и управления данных. Загрузка данных инициируется по событию (обновление данных на стороне ЦСДП, НЦ) или по расписанию. Форматы представления данных и требования к агрегации фиксируются в Каталоге распространения или конфигурации представления данных.

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

3.1.2.4 Сервисная шина

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

-  ядро сервисной шины;

Реализация бизнес-логики работы компонента.

-  реестр веб-сервисов;

База данных искапсулированных сервисов ГЦИС/ЦСДП Р-ИСВ.

-  конструктор цепочек сервисов;

Средство назначения и реализации схем взаимодействия компонентов Р-ИСВ с использование языка BPEL.

-  сервис логирования ошибок

Веб-сервис сбора журналов работы компонентов ГЦИС/ЦСДП и их отображение.

Сервисная шина Р-ИСВ представляет собой специализированное программное обеспечение, позволяющее инкапсулировать веб-сервисы компонент Р-ИСВ и обеспечивающее доступ к этим сервисам через единую точку. Сервисная шина поддерживает веб-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Веб-сервисов). Сервисная шина устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между компонентами, входящих в состав системы.

На рисунке 5 показаны основные составляющие и схема взаимодействия компонент внутри узла на основе методов и средств сервисной шины.

Рисунок 5 – Архитектура внутриузлового взаимодействия на основе сервисной шины

Компоненты подключаются к шине через веб-сервисы, которые раскрывают предоставляемые компонентом функции.

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

-  идентификатор сервиса;

-  название;

-  адрес WSDL-документа;

-  полное описание веб-сервиса.

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

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

Конструктор цепочек сервисов позволяют строить бизнес – цепочки на основе веб-сервисов компонент Р-ИСВ. Т. е. реализация любой бизнес-цепочки является последовательностью вызовов определенных веб-сервисов компонент Р-ИСВ. Результатом замены последовательности вызовов будет новая бизнес-цепочка.

Средства создания и исполнения цепочек веб-сервисов веб-сервисов позволяют получать новые компоненты и новый функционал без написания нового программного кода, а путем объединения в определенной последовательности существующих веб-сервисов компонент. Для создания бизнес-цепочек Р-ИСВ используется основанный на XML-язык описания бизнес-процессов BPEL (Business Process Modeling and Execution). Главным преимуществом BPEL является то, что в итоге каждая цепочка представляет собой веб-сервис, имеющий собственное описание. Т. е. вызов бизнес-цепочки представляет собой вызов стандартного веб-сервиса. Это позволяет включать созданные цепочки в состав Р-ИСВ в качестве веб-сервисов и создавать на их основе новые цепочки.

В качестве графического редактора для визуального объединения веб-сервисов в цепочки используется свободно распространяемая среда Eclipse Galileo с установленным на нем специализированным open source дополнением JBoss Tools. Средством исполнения цепочек является свободно распространяемый BPEL-инструментарий выполнения процессов веб-сервисов Riftsaw, который специально оптимизирован для исполнения цепочек веб-сервисов на сервере приложений JBoss.

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

-  уникальный идентификатор цепочки;

-  версия цепочки;

-  дата создания цепочки;

-  дата запуска цепочки;

-  информация о запуске;

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

-  содержание всех сообщений, которыми обмениваются веб-сервисы внутри цепочки;

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

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

Построение и ведение журнала обработки выполняется по следующим правилам:

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

- модули реализуют Процессы (один или несколько экземпляров), состоящие из этапов – транзакций в применении к конкретным объектам процессов;

- экземпляром процесса является одно выполнение процесса для конкретного субъекта. Компонент может выполнять один или несколько (обычно) экземпляров одного процесса;

- транзакция является совокупностью неделимых действий. Минимальной составляющей транзакции является одно действие;

- компоненты, процессы и их экземпляры, транзакции, объекты процессов – уникально идентифицируются по общим правилам, описанным в пункте 2.1 «Правила идентификации»;

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

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

-  в случае уровня ошибки должен быть зафиксирован класс ошибки. Выделены 4 класса ошибок: ошибки, связанные с web, ошибки работы с базой данных, ошибки ГИС, прикладные ошибки работы программы;

-  не все параметры записи являются обязательными. Если параметр записи не обязателен и не указывается, то его значение должно быть задано как Null;

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

Ведение журнала обработки позволяет:

–  осуществлять мониторинг работы компонент на узлах;

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

–  осуществлять контроль нагрузок на сеть при работе компонент;

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

–  отслеживать длительность выполнения процессов компонентами;

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

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

–  идентификатор узла, на котором работает компонент;

–  идентификатор логируемого компонента;

–  идентификатор процесса компонента;

–  идентификатор экземпляра процесса;

–  идентификатор объекта процесса. Здесь объектом процесса является сущность, над которой осуществляется процесс (этап), и которая имеет заданные значения свойств (атрибутов), хранящиеся в метаданных. Например: информационный ресурс, слой, пользователь и др;

–  идентификатор этапа процесса;

–  планируемая дата начала процесса (этапа);

–  реальная дата начала процесса (этапа):

–  дата окончания процесса (этапа);

–  объем перерабатываемой процессом информации;

–  идентификатор уровня логирования;

–  идентификатор класса ошибки (в случае ошибки в выполнении процесса или этапа);

–  содержимое сообщения-лога.

Регистрация события в журнале обработки происходит путем вызова метода postMessage web-сервиса логирования, входящего в состов ПО Сервисной шины. Метод возвращает булево значение «true», если запись лога прошла удачно и «false» в противном случае.

3.1.2.5 Каталог метаданных

Каждый узел ответственен за комплект метаданных по своей зоне ответственности. Ответственность включает в себя:

- создание первоначального набора метаданных;

- поддержание в актуальном состоянии набора метаданных;

- представление метаданных другим ГЦИС/ЦСДП

- загрузка метаданных из других ГЦИС/ЦСДП и поддержание их в актуальном состоянии;

- публикация полного комплекта метаданных.

Создание и поддержание в актуальном состоянии, публикация метаданных и реализация технологии поиска метаданных осуществляется с использованием пакета GeoNetwork. Выполняет сбор и синхронизацию метаданных между распределенными каталогами (GeoNetwork, CSW, Z39.50, OGC WxS, WebDav, Thredds, Local filesystem, OAI-PMH). Поддерживает CSW 2.0.2 ISO Profile, OAI-PMH, Z39.50 протоколы. Реализация синхронизации метаданных, т. е. загрузка и представление обновлений осуществляется на основе технологии «сбора метаданных», которая также реализуется пакетом GeoNetwork (http://geonetwork-opensource. org/) .

3.1.2.6 Портал

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

-  Регистрация пользователя

-  Предоставление справочной, каталожной информации и метаданных

-  Поиск данных и служб на основе метаданных (DAR)

-  Заказ данных для распределения на основе расписания

-  Представление данных по запросам

Портал реализует функции информационного обслуживания и имеет следующий состав:

-  Ядро портального приложения

-  Служба сервера

-  Служба управления статичным cодержимым (CMS)

-  Служба для удалённых портлетов

-  Служба администрирования портала

-  Служба управления пользователями

-  Портлет доступа к метаданным/данным Р-ИСВ

-  Служба доступа к справочным данным

Базовый программный комплекс портала построен на основе открытого ПО JBoss Portal (http://www. jboss. org/jbossportal). Ядро портального приложения выполняет интеграцию фрагментов разметки, полученных от портлетных приложений, и формирование страниц для представления конечным пользователям. В дополнение к базовому функционалу разрабатываются дополнительные шаблоны разметки страниц и темы оформления страниц.

Служба сервера является точкой обслуживания запросов пользователей, т. е. точкой входа в портал. Здесь происходит назначение политики безопасности портала и подключение механизма технология единого входа (SSO, Single Sign On) для узла.

Служба управления статичным содержимым (CMS) выполняет хранение и управление статичным содержимым, построена на основе технологии Apache JCR (Java Content Repository).

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

Служба для удалённых портлетов выполняет публикация удалённых портлетов и получение удалённых портлетов, которые являются разновидностью веб-сервисов.

Служба для бизнес-процессов формирует и управляет бизнес-процессами. В базовой конфигурации портала таким образом реализован процесс регистрации пользователя с одобрением администратора портала и уведомлением пользователя.

Служба администрирования портала выделена в субпортал, который визуализирует формы для: управления учетными записями пользователей и ролевой информации (базовая версия), управления CMS, создания и настройкой экземпляров портлетов, управления удалёнными портлетам.

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

Портлет доступа к метаданным/данным Р-ИСВ. Портлет реализует следующие функции:

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

-  Просмотр описаний информационных ресурсов, сведений о параметрах наблюдений/обобщений;

-  Получение данных информационных ресурсов согласно критериям поиска;

-  Возможность загрузки полученных данных в zip-архиве в виде NetCDF и ASCII;

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

-  Возможность экспорта данных в виде CSV, XML, Excel и PDF;

-  Просмотр полученных данных в табличном, графическом виде и на карте;

Служба доступа к справочным данным предоставляет доступ к справочным данным на узле для всех компонент и для удалённых узлов через веб-сервисы.

3.1.2.7 Сервис безопасности

Управление доступом к данным на основе единой политики информационной безопасности, ведение каталогов ролей и пользователей;

Управление доступом обеспечивается выбранным методом контроля доступа, реестром объектов (ресурсов), с присвоением меток доступа или ролей, и каталогом пользователей (субъектов доступа), так же с присвоением ролей. Для узлов Р-ИСВ используется ролевая модель контроля доступа.

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

Для узла Р-ИСВ используется централизованная система идентификации на основе JOSSO (http://www. josso. org). Архитектура приведена на рис. 6.

Рисунок 6 - Архитектура централизованной системы идентификации на основе JOSSO

Серверная часть или провайдер идентификации (IdP) является сервером единого входа для всех общесистемных компонент узла Р-ИСВ. Провайдер идентификации разворачивается на сервере приложений J2EE или сервлетном контейнере и основан на стандартах JAAS, Web Services/SOAP, SAML. Взаимодействие с агентами осуществляется через набор веб-сервисов SOAP.

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

Общесистемные компонены, разворачиваемые на серверах приложений J2EE или сервлетных контейнерах, имеют один домен безопасности JAAS: java:jaas/josso. Его назначение определяет использование логин-модуля от провайдера идентификации. При успешной аутентификации создаётся сессия пользователя, параметры которой сохраняются в “кукисах” браузера. Таким образом, при запросах пользователя к защищаемому ресурсу любого компонента узла не происходит повторных обращений к хранилищу учетной информации, что снижает нагрузку на сервер идентификации и базу данных.

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

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

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

Такими мерами являются:

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

·  использование для развёртывания сервлетного контейнера Tomcat для снижения нагрузки на сервер;

·  постоянный мониторинг состояния сервера и провайдера идентификации;

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

·  внедрение дублирующей системы для базы данных.

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

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

Портал Р-ИСВ имеет собственный реестр ресурсов, состоящий из дерева узлов портала (субпорталы, меню, страницы), набора экземпляров портлетов и набора «точек входа» для системы хранения содержимого. Информация о роли и разрешениях для доступа к каждому ресурсу сохраняется в базе данных портала и соответствует общесистемному перечню ролей. Авторизация для портальных ресурсов осуществляется через программное средство на основе Java Authorization Contract for Containers (JACC).

3.1.2.4 Компоненты управления системой включают:

Телекоммуникации реализуются с применением ведомственной сети связи (ВСС) Росгидромета и сетей общего назначения, объединенных с виртуальной VPN (Virtual Private Network) сетью Р-ИСВ.

3.1.3 Компоненты ЦСДП

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

3.1.4 Построение Р-ИСВ

Предусматривается развертывание прототипа ГЦИС в г. Москва (ФГУ «Авиаметтелеком») и ЦСДП в г. Обнинск (ГУ “ВНИИГМИ-МЦД”). При этом функции НЦ выполняют узлы ГСТ/АСПД в г. Обнинск и г. Москва.

Источником данных глобального обмена, поступающих в систему через прототип ГЦИС, является глобально распространяемая по ГСТ информация, принимаемая ЦКС ГРМЦ.

Источником региональных и глобальных данных, поступающих в систему через прототип ЦСДП, служат данные принимаемые ЦКС Обнинск.

Построение ГЦИС и ЦСДП осуществляется посредством комбинирования перечисленных выше компонент в виде узлов Р-ИСВ функционала ГЦИС и ЦСДП, их установки на площадках Р-ИСВ в г. Москва и г. Обнинск соответственно, настройки и наладки информационных и программных интерфейсов между узлами.

3.1.4.1 Состав и характеристики прототипа ГЦИС Р-ИСВ

Общая характеристика состава компонент, ожидаемого функционала и данных прототипа ГЦИС Р-ИСВ представлены в таблице 3.

Таблица 3. Состав и характеристики прототипа ГЦИС Р-ИСВ

Состав компонент

Функции

Данные

Обработчик ГСТ

Поставщик Данных

Сервер Интеграции

Сервисная шина

Каталог метаданных

Портал ГЦИС

-  накопление данных от НЦ и ЦСДП (г. Обнинск);

-  обмен информацией между ГЦИС (имитация другого ГЦИС – стенд экземпляра РЦИТУ в г. Обнинск);

-  предоставление и распространение информации от подведомственного ЦСДП (г. Обнинск), других ГЦИС (имитация, см. выше) по технологиям "pull" и “push” для национальных и зарубежных пользователей согласно их прав;

-  обеспечение доступа к каталогам информации других центров, включая внешние ГЦИС;

-  хранение глобально распространяемой информации в течении не менее 24 часов

-  хранение метаданных;

-  обеспечение связи 24/7;

-  резервное копирование и восстановление данных и служб;

-  участие в мониторинге производительности системы по своей зоне.

·  данные ГСТ, АСПД Москва;

·  данные ЦСДП г. Обнинск

3.1.4.2 Состав и характеристики прототипа ЦСДП Р-ИСВ

Общая характеристика состава компонент, ожидаемого функционала и данных прототипа ЦСДП Р-ИСВ даны в таблице 4.

Таблица 4. Состав и характеристики прототипа ЦСДП Р-ИСВ

Обработчик ГСТ

Поставщик Данных

Сервер Интеграции

Сервисная шина

Каталог метаданных

Портал ЦСПД

-  сбор информации, предназначенной для распространения в НЦ по зоне своей ответственности;

-  сбор специализированных, программно-ориентированных данных и продукции;

-  обеспечение информацией ГЦИС (г. Москва) для международного обмена (глобально распространяемая информация);

-  предоставление и распространение информации по технологии по технологиям "pull" и “push” для национальных и зарубежных пользователей согласно их прав;

-  обеспечение доступа к каталогам информации других центров, включая ГЦИС;

-  обеспечение процедуры резервного копирования и восстановления данных и служб;

-  участие в мониторинге производительности системы;

-  хранение метаданных;

-  обеспечение связи 24/7

·  данные ГСТ, АСПД Обнинск;

·  данные ГЦИС г. Москва

3.2 Способы и средства связи между компонентами

3.2.1 Средства взаимодействия и взаимосовместимости

Архитектура Р-ИСВ предусматривает программные и информационные связи как между узлами системы ГЦИС, ЦСДП и НЦ, так между компонентами внутри узла Р-ИСВ.

Взаимодействие производится на основе:

-  средств взаимосовместимости компонентов;

-  сервисной шины.

Средства взаимосовместимости компонентов состоят из спецификаций метаданных, данных и веб-сервисов, протоколов информационного и программного взаимодействия компонент через веб-сервисы, API (Application Programme Interface) и файловый обмен, а также:

-  спецификации форм регламентированной отчетности о работе системы в виде стандартизированных HTML-страниц и их версий для печати;

-  спецификации графических интерфейсов пользователей (GUI) на порталах системы.

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

3.2.3 Общие схемы взаимодействия

Взаимодействие между ГЦИС, ЦСДП и НЦ организуются на основе принципов, заложенных протоколами ИСВ ВМО. Эти протоколы реализуются на основе синхронизации метаданных с использованием «харвестинга» (технологии сбора) и синхронизации данных по схемам “push” и “pull”.

Внутри узла взаимодействие компонент осуществляется на стандартах взаимосовместимости под управлением сервисной шины.

3.3 Взаимосвязи со смежными системами

Предусматривается взаимодействие Р-ИСВ с другими элементами Информационной системой ВМО, такими как зарубежные ГЦИС, а также с информационными системами и комплексов, действующими в Росгидромете:

-  Автоматизированная система передачи данных (АСПД);

-  технологии сбора и первичной обработки режимной метеорологической, гидрологической, океанографической информацией (ПЕРСОНА –МИС, ПЕРСОНА-БЕРЕГ, ПЕРСОНА-РЕКИ и КАНАЛЫ);

-  проблемно-ориентированные комплексы обработки и анализа информации в организациях Росгидромета (ГМЦ России, ВНИИГМИ-МЦД и др.),

другими информационными системами (например, ЕСИМО, СЦ Минприроды России и др.).

В общем случае, взаимосвязи обеспечиваются посредством реализации следующих процессов (рисунок 7):

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

-  включение информации из информационных систем (комплексов) в Р-ИСВ посредством подключения их источников данных к системе распределенных данных Р-ИСВ.

Рисунок 7 – Общая схема взаимосвязи Р-ИСВ с внешней информационной системой

Взаимодействие с внешними информационными системами (ВИС) осуществляется по схеме “портал” – “портал” через Сервер Интеграции ГЦИС Р-ИСВ, который:

- предоставляет по расписанию или разовому запросу заданный набор метаданных и данных по заданному адресу порталов ГЦИС ВИС;

- загружает метаданные и данные ВИС в СРБД для применения в Р-ИСВ.

Взаимодействие осуществляется по протоколам FTP, FTPS, SMTP, HTTP, HTTPS и SOAP, причем предполагается, что ВИС имеет возможность предоставить метаданные согласно спецификациям совместимости центров ИСВ (ИСО 19915/19139) или в другом согласованном с Р-ИСВ формате.

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

3.4 Режимы функционирования и диагностирования системы

Для Р-ИСВ (каждого узла системы – ГЦИС, ЦСДП и НЦ) определены следующие режимы функционирования:

-  нормальный режим функционирования;

-  аварийный режим функционирования.

Основным режимом функционирования Р-ИСВ является нормальный режим. В этом режиме задействованные базы данных (метаданных), программное обеспечение, телекоммуникационные и вычислительные средства обеспечивают работу в режиме 24*7*365.

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

-  схемы восстановления работоспособности компонент с обеспечением возврата к последнему нормально выполненному процессу согласно лога компоненты;

-  схемы архивации информации, резервного копирования и восстановления компонент после аварийных ситуаций.

Каждый компонент Р-ИСВ содержит средства диагностики, используя при этом типовую структуру журнала работы.

Технические спецификации режимов функционирования и средств диагностирования Р-ИСВ рассмотрены в разделах 4.1. (типовая структура журнала работы) и 4.2. (программное обеспечение компонент) документа.

3.5 Функции, выполняемые системой

Перечень комплексов функций (задач) Р-ИСВ дан на рисунке 8 .

Рисунок 8 - Комплекс функций Р-ИСВ

Задача 1. Сбор, загрузка данных/метаданных и их интеграция. Реализует требования Технических спецификаций ИСВ:

-  ТС 1 ИСВ - Загрузка метаданных о данных и продукции.

-  ТС 2 ИСВ - Загрузка данных и продуктов:

-  ТС 3 ИСВ - Централизация глобально распределяемых данных.

В рамках этой задачи Р-ИСВ (компоненты Обработчик ГСТ, Поставщик Данных, Сервер Интеграции, Сервисная шина) обеспечивает выполнение следующих функций:

-  взаимодействие с действующей системой сбора данных наблюдений и низовой сетью связи Росгидромета и Автоматизированной Сетью Передачи Данных (АСПД) Росгидромета на переходный период.

-  регистрация источников данных и генерация актуальных метаданных для поиска и доступа к информационным ресурсам центров Р-ИСВ и обмена информацией;

-  сбор метаданных на уровне ГЦИС и ЦСДП согласно назначенным федерациям данных;

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

-  выполнение процедур “кэширования” глобально распространяемой информации на уровне ГЦИС в целях обеспечения их хранения и восстановления при аварийных состояниях;

-  включение в распределенную систему данных Р-ИСВ информации зарубежных ГЦИС и ЦСДП.

Задача 2. Обеспечение единой политики информационной безопасности системы

Реализует требования Технических спецификаций ИСВ:

-  ТС 4 ИСВ - Идентификационная и ролевая информация для системы безопасности.

-  ТС 5 ИСВ – Консолидированное представление информации о пользователях.

-  ТС 6 ИСВ - Аутентификация пользователя.

-  ТС 7 ИСВ - Авторизация пользователя.

Функции (компонент Безопасность):

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

-  ведение баз ролевой информации для компонент системы, каталогов ресурсов и сервисов на разных уровнях Р-ИСВ;

-  консолидация и межузловая синхронизация информации системы безопасности, обеспечение доступности информации с учетом прав ее потребителей;

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

Задача 3. Управление метаданными и предоставление доступа к метаданным. Реализует требования Технических спецификаций ИСВ:

-  ТС 9 ИСВ – Консолидированное представление метаданных.

-  ТС 13 ИСВ - Обеспечение распределения метаданных.

-  ТС 14 ИСВ – Консолидированное представление распределенных каталогов метаданных.

Функции (компоненты Сервер Интеграции, Поставщик Данных, Каталог метаданных, Сервисная шина):

-  формирование и поддержка актуальности наборов метаданных категорий:

-  Каталог данных для поиска, доступа и извлечения информации из распространенных и разнородных источников данных по запросам;

-  Каталог распространения информации для реализации механизма распространения информации по подписке.

-  консолидация метаданных узлов и синхронизация каталогов в узлах Р-ИСВ (ГЦИС, ЦСДП, НЦ), обеспечение их хранения и восстановления в случае аварий;

-  обеспечение доступности каталогов в режиме 24/7/365, их предоставление и распространение с учетом прав пользователей.

Задача 4. Доставка информации пользователям. Реализует требования Технических спецификаций ИСВ:

-  ТС 8 ИСВ - Поиск и выборка данных через каталог метаданных

-  ТС 10 ИСВ - Скачивание файлов через выделенные сети.

-  ТС 11 ИСВ - Скачивание файлов через невыделенные сети.

-  ТС 12 ИСВ - Скачивание файлов другими способами.

Функции (компоненты Обработчик ГСТ, Сервер Интеграции, Сервисная шина, Портал):

-  распространение данных по подписке (“push”) авторизованным (внутренним и внешним) пользователям согласно каталогу распространения информации и заданных в нем условий (состав данных и точка доставки, временной график, пространственно-временным критериям, формат данных, метод);

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

-  представление данных в зарубежные сегменты ИСВ в соответствии политиками доступа к данным ВМО и Росгидромета, включая представление глобально распространяемой информации с уровня ГЦИС во внешние ГЦИС и запросы внешних ГЦИС и ЦСДП;

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3