Главная      Учебники - Разные     Лекции (разные) - часть 12

 

Поиск            

 

проблема информационного взаимодействия в электронном правительстве

 

             

проблема информационного взаимодействия в электронном правительстве

БЕЛОРУССКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Выпускная работа по
«Основам информационных технологий»

Магистрант

кафедры кибернетики

Быков Сергей Николаевич

Руководители:

ст. преподаватель

Шалатонин Иван Алексеевич,

ст. преподаватель

Кожич Павел Павлович

Минск – 2008 г.

Оглавление

Оглавление. 2

Список обозначений ко всей выпускной работе. 3

. 4

ВВЕДЕНИЕ.. 5

ГЛАВА 1 ВЗАИМОДЕЙСТВИЕ ИНФОРМАЦИОННЫХ СИСТЕМ... 6

ГЛАВА 2 АРХИТЕКТУРЫ ВЗАИМОДЕЙСТВИЯ.. 9

2.1 Java Business Integration. 9

2.2 SPCoop. 10

ГЛАВА 3 РАЗРАБОТКА ПРОТОТИПОВ И АНАЛИЗ РЕЗУЛЬТАТОВ.. 15

ЗАКЛЮЧЕНИЕ.. 20

Предметный указатель к у. 22

Интернет ресурсы в предметной области исследования. 23

Действующий личный сайт в WWW... 24

Граф научных интересов (образец приведен ниже). 25

Презентация магистерской диссертации. 26

Список литературы к выпускной работе. 27

Приложения А. Слайды презентации магистерской работы.. 28

Список обозначений ко всей выпускной работе

EIF – European Interoperability Framework (Европейская Платформа Взаимодействия);

WSDL – Web Service Definition Language (язык описания веб-сервисов);

JBI – Java Business Integration (спецификация интеграции);

SPCoop – Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana (итальянская спецификация для кооперации государственных учреждений);

SOAP – Simple Object Access Protocol (простой протокол доступа к объектам );

XML – Extensible Markup Language (расширяемый язык разметки);

UDDI - Universal Description, Discovery and Integration (универсальное описание, поиск и взаимодействие);

SAML - Security Assertion Markup Language (язык разметки для систем обеспечения безопасности);

OpenSPCoop – Open SPCoop (реализация спецификации SPCoop);

Sirv-Interop – Servizi di interoperabilita per enti ed amministrazioni della regione (реализация спецификации SPCoop);

ГУ – государственное учреждение.

ПРОБЛЕМА ИНФОРМАЦИОННОГО ВЗАИМОДЕЙСТВИЯ В ЭЛЕКТРОННОМ ПРАВИТЕЛЬСТВЕ

ВВЕДЕНИЕ

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

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

В первом разделе рассмотрена проблема информационного взаимодействия с концептуальной точки зрения. В качестве основы использован EIF (European Interoperability Framework). В разделе 2 проводится детальный анализ возможных архитектур для построения систем электронного правительства. Затем, в разделе 3, рассматриваются прототипы, разработанные во время выполнения магистерской работы, проводиться анализ результатов.

ГЛАВА 1 ВЗАИМОДЕЙСТВИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

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

В соответствии с ISO/IEC 2382-01, Словарь Информационных Технологий, Фундаментальные Понятия, взаимодействие определено как: "Возможность коммуницировать, выполнять программы или передавать данные между различными функциональными блоками таким способом, который требует минимальных знаний об уникальных характеристиках данных блоков".[1] В данной работы мы собираемся рассмотреть определенную область проблемы взаимодействия: каким образом можно соединить сервисы различных государственных учреждений или даже различных стран. Это проблема является актуальной в наши дни, потому что уже существует интеграционная тенденция не только в странах Европейского Союза, но и во всем мире. В июне 2002 года на Севильском саммите главы европейских государств приняли «eEurope Action Plan 2005». Как результат был выработан набор концепций для проектов электронного правительства в ЕС. EIF (European Interoperability Framework) содержит информацию о технических нормах и спецификациях, которые призваны помочь соединить между собой информационные системы государственных учреждений ЕС.

«eEurope Action Plan 2005» является набором рекомендаций, которые должны быть приняты во внимание в любом новом проекте, связанным с концепцией электронного правительства на панъевропейском уровне.

Основные принципы взаимодействия, которые были заявлены следующие:

ОРГИНИЗАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ. Этот аспект взаимодействия связан с определением бизнес целей, моделированием бизнес процессов и обсуждением коллаборации администраций, которые желают обмениваться информацией, и могут иметь различную внутреннюю структуру данных и процессов. Более того, организационное взаимодействие ставит своей целью постановку требований по доступности сервисов, простоты идентификации и ориентированности на пользователя.

СЕМАНТИЧЕСКОЕ ВЗАИМОДЕЙСТВИЕ. Этот аспект связан с установлением точного значения информации, которая подлежит обмену, и гарантировании того, что это информация будет правильно интерпретирована даже в том случае, если другая сторона ничего не знала о ней на этапе разработки. Семантическая совместимость дает возможность системам комбинировать полученную информацию с другими информационными ресурсами и обрабатывать их семантическими способами. Таким образом, семантическое взаимодействие – основание для мультиязыковой доступа к информации в программах пользовательского интерфейса.

ТЕХНИЧЕСКОЕ ВЗАИМОДЕЙТСТВИЕ. Этот аспект взаимодействия покрывает технические проблемы связывания компьютеров и сервисов. Он включает в себя такие понятия как: открытые интерфейсы, взаимодействие сервисов, интеграция данных, представление данных и их обмен, доступ и безопасность.

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

ГЛАВА 2 АРХИТЕКТУРЫ ВЗАИМОДЕЙСТВИЯ

2.1 Java Business Integration

JBI определяет архитектуру, которая позволяет конструировать интеграционные системы с гибкой структурой. Основа такой системы – промежуточная среда, позволяющая обмениваться сообщениями. Модель обмена сообщениями основана на языке описания веб-сервисов WSDL 2.0 [2].

Рисунок 1 Архитектура динамического подключения JBI

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

Все сообщения, которые используются для обмена информацией, описаны с помощью WSDL версии 1.1 или 2.0 [3]. WSDL основан на декларативной модели обмена сообщениями, которая базируется на двух уровнях:

· Модель абстрактного сервиса. Сервис определен как абстрактная модель обмена сообщениями, без указания определенного протокола или формы передачи данных.

· Конкретная модель. Абстрактный сервис связывается с определенным протоколом и способом представления данных.

JBI использует модель абстрактного сервиса, как основу взаимодействия компонентов. Компоненты могут играть одну из двух ролей:

· Поставщик Сервиса. Компонент выполняет заданный сервис (либо напрямую, либо как прокси для внешнего провайдера);

· Потребитель Сервиса. Компонент, который вызывает данный сервис (либо напрямую, либо как прокси для внешнего потребителя).

Существует несколько имплементаций, которые выполнены на основе JBI стандарта: OpenESB, Apache ServiceMix, Mule, OW2 PEtALS.

2.2 SPCoop

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

Рисунок 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), и только после обозначения концепций и стандартов переходит в руки к ИТ специалистов, призванных воплотить концептуальные идеи в конкретный программный продукт.

Беларусь не стоит в стороне от прогрессивного перехода к электронному правительству. Общенациональная стратегия перехода к информационному обществу нашла свое отражение в Государственной программе информатизации Республики Беларусь «Электронная Беларусь». На этапе 2006-2010 годов должны быть завершены работы по созданию общегосударственной автоматизированной информационной системы, сформирована единая информационная и телекоммуникационная инфраструктура, обеспечено внедрение системы электронной торговли для государственных нужд на республиканском уровне, стандартизованного электронного документооборота и систем обеспечения национальной безопасности. Кроме того, одним из важных результатов программы станет расширение числа пользователей сети Интернет и объемов получаемых с ее помощью услуг.


Список литературы к у

1 Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.

3 Web Services Description Language (WSDL) 1.1 , http://www.w3.org/TR/wsdl

4 Roberto Baldoni1, Stefano Fuligni, Massimo Mecella1, and Francesco Tortorelli. The Italian e-Government Service Oriented Architecture. Strategic Vision and Technical Solutions.

5 DeltaDator s.p.a., http://www.deltadator.it/

Предметный указатель к у


EIF, 5,6,20

JBI, 9

OpenSPCoop, 16,17

Sirv-Interop, 17

бизнес процесс, 7

взаимодействие, 6,9

онтология, 12

семантика, 7,12,13

электронное правительство, 5,20


Интернет ресурсы в предметной области исследования.

http:./www.epractice.eu – сайт содержит базу данных проектов связанных с электронным правительством в Европейском Союзе. Представлено краткое описание проектов, результаты, а также где можно найти детальное описание.

http://www.egovmonitor.com/ – на сайте представлены новости текущих проектов электронного правительства в Англии и Европе.

http://info.minsk.by – информационный портал Минска. Содержит информацию, как для бизнеса, так и для обычных граждан. Служит хорошим примером развития концепции «Электронная Беларусь»

http://servicemix.apache.org/ – сайт, посвященный серверу ServiceMix, являющийся самым широко распространенным программным продуктом на базе JBI. Содержит множество статей, посвященных проблеме информационного взаимодействия в целом.

http://www.digital-government.net/ – портал, посвященный электронному правительству. Содержит новости, статью обзоры, ссылки на другие сайте по данной тематике.

http://www.ctg.albany.edu/ – сайт исследовательской лаборатории университета Албани (University at Albany). Содержит материалы собственных исследований, а также описание проектов в США, связанных с электронным правительством.

Действующий личный сайт в WWW

http://siarhei-bykau.narod.ru/

Граф научных интересов (образец приведен ниже).

магистранта (аспиранта) Быкова С.Н. факультет радиофизики и электроники

Специальность «Компьютерная безопасность»

Смежные специальности

01.04.03 – радиофизика

1. Оптические методы обработки информации.

2. Статистическая радиофизика.

Основная специальность

05.13.19 – методы и системы защиты информации, информационная безопасность

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

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

Сопутствующие специальности

05.13.11 – математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

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

05.13.17 – теоретические основы информатики

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

2. Разработка теоретических и технических основ, используемых при создании современных баз данных, баз знаний, прикладных экспертных систем и систем искусственного интеллекта.

Презентация магистерской диссертации

Ссылка на презентацию магистерской работы.

Список литературы к выпускной работе.

1. Гилен Р. Моя первая книга о Microsoft Office PowerPoint 2003. Эксмо, 2005.

2. Дьяконов В., Новиков Ю., Рычков В. Компьютер для студента. Самоучитель. Спб.: Питер, 2001.

3. Хабрейкен Д. Microsoft Office 2003: Word, Excel, Access, PowerPoint, Publisher, Outlook. Все в одном. Вильямс, 2006.

4. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.

5. Roberto Baldoni1, Stefano Fuligni, Massimo Mecella1, and Francesco Tortorelli. The Italian e-Government Service Oriented Architecture. Strategic Vision and Technical Solutions.

6. S. Vinoski, Integration with Web Services, IEEE Internet Computing 7(6), 2003, pp. 75-77, http://csdl.computer.org/comp/mags/ic/2003/06/w6075abs.htm.

7. Web Services Interoperability Organization, Basic Profile Version 1.1 , http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html.

Приложения А. Слайды презентации магистерской работы