проблема информационного взаимодействия в электронном правительстве (стр. 2 из 3)
Рисунок 2 Компоненты SPCoop
Модель, предложенная SPCoop, основывается на следующих принципах: [4]:
· ГУ взаимодействуют при помощи и посредством сервисов приложений; эти сервисы предлагаются через уникальный (логический) элемент, принадлежащий к его собственной информационной системе – Шлюз Домена (Domain Gateway). В этом случае полная автономия каждой администрации гарантирована. Что касается разработки и управления предлагаемых сервисов, то они могут быть основаны на любой платформе, созданы с нуля или усовершенствованы. Вызов сервисов приложений проводится посредством обмена сообщениями, основанных на стандарте, известным как электронный конверт (e-Gov Envelop). Такой стандарт представляет собой расширение SOAP;
· Сервис работает на основании соглашения между двумя субъектами (поставщик и клиент); такое соглашение имеет под собой как техническую основу, так и юридическую силу. Соглашения должны быть формализованы для того, чтобы обеспечить разработку и жизненный цикл сервисов в (полу-)автоматическом режиме. Спецификация соглашения называется Соглашение Сервисов (Service Agreement) и основывается на языке XML.
· Несколько администраций, которым необходимо кооперировать друг с другом для предоставления составного сервиса, образуют Домен Кооперации (Cooperation Domain); сервисы, поддерживаемые таким доменом, внешне описаны с помощью Соглашения Сервисов, и внутренне - Соглашением Кооперации.
Для того, чтобы поддержать выше изложенные принципы SPCoop имеет следующие компоненты:
· Хранилище Соглашений это программный компонент, используемый для регистрации и поддержки Соглашения Сервисов\Кооперации. Он может быть рассмотрен, как база данных для кооперации. Хранилище Соглашений предлагает функционал по регистрации, доступу, обновлению и поиску соглашений. Основанием данного хранилища является UDDI (Universal Description, Discovery and Integration) стандарт, однако данный стандарт не имеет полного набора требуемого функционала, вследствие чего он был программно расширен;
· Хранилище Схем Данных (Онтологий) это программный компонент позволяющий работать с семантикой сервисов и информации, для того, чтобы обеспечить удобный поиск сервисов, наиболее подходящих для решения поставленной задачи. Компонент действует как структура для хранения онтологий и концептуальных схем, предоставляя функционал по регистрации, доступу, обновлению и обоснованию онтологий.
· Федеративное Управление Паролями используется для авторизации и контроля доступа к сервисам приложений SPCoop; федеративное управление необходимо для повторного использования паролей региональных и национальных уровней. Интеграция реализована через SAML (Security Assertion Markup Language) v2.0.
· Сервис Мониторинга служит для наблюдения за тем, как различные сервисы соблюдают Соглашения Сервисов. Ее разработка запланирована на будущее (таким образом, она не была включена в текущую версию).
Соглашение сервисов это точно определенный XML документ, который регламентирует отношения между поставщиком и клиентов в следующих аспектах:: (i) интерфейс сервиса, (ii) диалоги, поддерживаемые сервисом, (iii) точку доступа, (v) Уровень Соглашения Сервиса, (v) характеристики безопасности и (vi) семантическое описание сервиса. Формальная и четко заданная природа соглашения сервисов была сделана для поддержки разработки и функционирования сервисов в (полу-)автоматическом режиме. Более того, открытая архитектура соглашения сервисов делает проще разработку доменных онтологий, которые позволяют объединить сервисы со схожей семантикой. Наконец, в контексте набора государственных учреждений, сервисы могут быть соединены и организованы, образовывая другие сервисы с помощью соглашений.
Соглашение Сервисов описывает двухсторонние отношения с целью предоставления и вызова сервисов. Множество административных процессов не могут ограничивать использованием ресурсов одной администрации, и поэтому вовлекают в свои процессы другие. Домен Кооперации – формализации желания различных субъектов объединиться для образования композиционного сервиса, который позволит автоматизировать административные процессы. Внутри Кооперационного Домена можно выделить ответственного координатора, задачей которого является координация вовлеченных субъектов, а также композитных приложения, образованных посредством Домена Кооперации. Домен Кооперации можно рассматривать как проводник сервиса, действующий как обычный домен какой-либо администрации. Главное различие в способе, которым эти сервисы были спроектированы и разработаны: в Домене Кооперации они построены композицией и интеграцией простых сервисов, предложенных вовлеченными администрациями, тогда как для обычного домена поддержка сервиса полностью связана с приложением, которое полностью под контролем одной администрации.
ГЛАВА 3 РАЗРАБОТКА ПРОТОТИПОВ И АНАЛИЗ РЕЗУЛЬТАТОВ
В качестве основы для прототипа OpenSPCoop было выбрано приложение «Биржа Труда». 3 сервиса образуют простейшую клиент-серверную архитектуру. «Союз Работников» принимает заявки безработных граждан ищущих работу. Каждый ищущий может разместить (publishProfile), обновить (updateProfile) или же удалить свою анкету (deleteProfile). В то же самое время, «Офис Компаний» дает возможность компаниям размещать свои предложения об открытых вакансиях. «Брокер» служит посредником между «Союзом Работников» и «Офисом Компаний» и позволяет каждой анкете безработного быть проверенной на все предложения компаний (searchJOffer) и наоборот – каждой заявке компании проверить все анкеты безработных (searchProfile) (Рисунок 3):
Рисунок 3 Архитектура приложения «Биржа Труда»
В качестве примера, иллюстрирующего принцип работы «Биржи Труда» можно использовать диаграмму последовательности (Рисунок 4):
Рисунок 4 Диаграмма последовательности для приложения «Биржа Труда»
Рассмотрим все шаги диаграммы последовательно: безработный гражданин посылает свою анкету в «Союз Работников»(publishProfile), «Союз Работников» сохраняет анкету в своей базе данных и уведомляет «Брокера» о том, что появилась новая анкета(notifyNewProfile). В свою очередь, «Брокер» посылает запрос «Офису Компаний» с тем, чтобы найти все подходящие вакансии в компаниях(searchJOffer). «Офис Компаний» проводит поиск, и все результаты отсылает владельцу анкету посредством электронной почты(sendOffers2Profile). Данное приложения имеет достаточную сложность, чтобы проверить возможности, которые предоставляет OpenSPCoop. Все сообщения, которыми обмениваются компоненты, - сообщения SOAP, и все сервисы реализованы как веб-сервисы. Идея построения прототипа – представить «Союз Рабтников» и «Офис Компаний» как два государственных учреждения, которым необходимо взаимодействовать друг с другом для предоставления более качественного сервиса (теперь ручной труд по поиску соответствий будет заменен автоматическим поиском). В качестве такого «клея» служит OpenSPCoop, который дает возможность построить единую информационную систему. Вот набор шагов, необходимых для публикации сервисов:
1. Настроить реестр OpenSPCoop;
2. Настроить домен «Союза Работников» внутри OpenSPCoop;
3. Настроить домен «Офиса Компаний» внутри OpenSPCoop.
Результаты проведенного эксперимента с платформой OpenSPCoop следующие:· Была проведена настройка платформы, позволяющая опубликовать веб-сервисы;· Вся настройка была проведена без написания кода;· Веб-сервисы могут быть разработаны на любом языке, и работать на любой платформе;· Проведена настройка безопасности данных сервисов (аутентификация при помощи паролей).
В качестве основы для Sirv-Interop прототипа было выбрано приложение Civilia компании DeltaDator, крупнейшего производителя решений в области электронного правительства в Италии [5].Civilia состоит из двух компонентов: PrometeoWeb, который позволяет управлять бюджетом организаций, и Contabilità Finanziaria, которое производит аудит бюджета. Задача Sirv-Interop объединить эти два приложения в единую систему, в случае, если они работают в различных ГУ. Например, одна администрация может составлять бюджет, а другая проводит аудит.
Мы можем проиллюстрировать взаимодействие между PrometeoWeb и Contabilità Finanziaria используя диаграмму последовательностей Рисунок 5:
Рисунок 5 Взаимодействие между PrometeoWeb и Contabilita Finanziaria
Из диаграммы следует, что PrometeoWeb предоставляет три метода для Contabilità Finanziaria: getStruttura, getBudget, getVariazioniBudget. getStruttura возвращает структуру бюджета, после того как Contabilità Finanziaria получает структуру, оно может запросить сам бюджет, используя метод getBudget и, если необходимо, может запросить вариации бюджета (getVariazioniBudget).
Разработка прототипа Sirv-Interop включает следующие шаги:
1. Написание модели данных в формате WSDL;
2. Построение модуля единой информационной системы на базе Sirv-Interop.
В результате анализа, проведенного после разработки прототипа, можно отметить:
· Для публикации сервисов необходимо написание кода (классы-обертки);
· Сервисы могут образовать федеративные домены для упрощенной аутентификации (технология единого входа);
· Сервисы могут быть разработаны на любой языке, работать на любом типе сервера.
ЗАКЛЮЧЕНИЕ
Концепция электронного правительства стала не просто идеей на бумаге, а получило широкое практическое распространение во всем мире. Задачи, решаемые электронным правительством, требует междисциплинарных навыков у разработчиков. Поэтому в таких проектах участвуют специалисты из ИТ области, права, экономики, политики, философии. Как показывает опыт, первичная инициатива по переходу к новому подходу в правительстве исходит с самых верхних уровней (EIF), и только после обозначения концепций и стандартов переходит в руки к ИТ специалистов, призванных воплотить концептуальные идеи в конкретный программный продукт.