tri_botinka (tri_botinka) wrote,
tri_botinka
tri_botinka

Categories:

Система межведомственного "эмоционального" взаимодействия

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

Для электронного правительства (вспоминаем - что это НЕ информационная система) необходимо создавать технологическую инфструктуру (от слова "инфра" - лат. "под", "внизу" ) , обеспечивающую жизнедеятельность его функциональных элементов.
Вполне возможно, что если срок службы электронного правительства - десятки лет, технические решения и стандарты, лежащие в основе инфраструктуры должны гарантировать сохранность инвестиций, сопровождаемость и гибкость конструкции на все эти годы. Ошибки в архитектуре (как бы не хотелось отдельным персонажам) резко приведут к увеличению бюджета проекта и к самому страшному "греху" программирования - rework - переписывание уже готового и работающего кода. "Технически" сложные системы можно реализовать в различных вариантах:
  • Монолитная система (Monolithic System)
  • Одноуровневая архитектура (Peer-to-peer)
  • Клиент-серверная архитектура
  • Система <классной доски> (Blackboard)
  • Архитектура распределенных вычислений (Distributed Computing)
  • Архитектура неявных вызовов (Implicit invocation)
  • Архитектура каналов и фильтров (Pipes and filters)
  • Расширяемая архитектура (PlugIns)
  • Древовидная архитектура (Three-tier)
  • Структурированная архитектура (Structured)
  • Объектно-ориентированная архитектура
  • Сервисно-ориентированная архитектура
  • Поисково-ориентированная архитектура (Search-oriented)
[дописать по вкусу..]

Не обязательно связывать системы сложными архитектурными связями. Вполне возможно обмен информацией можно реализовать за счет физического размещения ИС на одном вычислительном кластере (что-то типа ОГИЦ) . Но если мы хотим получить синергетический эффект решения best-of-breed  - нужно смириться что компоненты будут гетерогенными, протоколы разными, поставщики не одинаковые - и вообще возможно выпадение в многомерность пространства и многовариантность реальности :-)

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

При таком подходе связывание компонент и сервисов лучше организовать по схеме ESB "шина" ru.wikipedia.org/wiki/Enterprise_Service_Bus с применением сервисно-ориентированной архитектуры.  Практически независимо от поставщика (WebSphere, WebLogic, Sonic ) данное решение будет иметь ESB функциональность:

                      Коммуникационная функциональность
  •                                  Маршрутизация
  •                                  Адресация
  •                                  Различные способы обмена сообщениями (синхронно, асинхронно, подписка)
  •                                  Подключения различных транспортные протоколов
  •                                  Гарантированная доставка сообщений
                      Интеграционная функциональность
  •                                  Различные способы интеграции (службы, адаптеры)
  •                                  Трансформация протоколов
                       Взаимодействие служб
  •                                  Определение интерфейса службы
  •                                  Модель обмена информационными сообщениями
  •                                  Замена реализации служб
                        Безопасность
  •                                  Аутентификация
  •                                  Авторизация
  •                                  Конфиденциальность
                        Обработка сообщений
  •                                  Кодирование логики
  •                                  Логика, зависящая от содержания
  •                                  Преобразование сообщений и данных
  •                                  Проверка (верификация)
  •                                  Хранение и перенаправление запросов

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

Важным в SOA является и такой вроде очевидный, но философский вопрос "кто заплатит за доработку". Поскольку, в отличие от простого инкапсулирования параметры SOA сервисов приближены к реальным доменам и объектам - например "Справочник клиентов" с входами "СНИЛС" и выходами "ФИО" - то вполне выявляется хозяин объекта, который вправе оказывать эти услуги на условно или вполне законно оплачиваемой основе и из этих  денег  сопровождать и развивать сервис. Можно прозрачно проводить аллокацию расходов на процессы оказания госуслуг, и так же явно претендовать на свой кусочек дохода.

Первой "ласточкой" из проектной документации на электронное правительство стали "Общие требования, предъявляемые к электронным сообщениям межведомственного информационного взаимодействия ", одобренные 9 на заседании Правительственной комиссии по проведению административной реформы от 17 сентября 2009 г. № 92 (раздел XI, пункт 3)
www.primorsky.ru/files/13877.doc

Но если вы прочитаете документ, первое ощущение может Вас разочаровать. Ни одного слова про XML !!   И точно - в документах такого класса абстракции и не может быть технических деталей реализации - они должны быть в Технических Требованиях (ТТ)
Однако - между строк можно увидеть главное - определены базовые принципы работы СМЭВ, и строго говоря они имеют широкие границы вариабельности для каждого участника:
  • обеспечение технологической возможности информационного взаимодействия существующих и вновь создаваемых государственных информационных систем, муниципальных информационных систем и иных информационных систем, предназначенных для выполнения государственных задач (далее - информационные системы);
  • обеспечение технологической независимости структуры СМЭВ и регламента ее работы от проводимых технических, административных, организационных и иных изменений в информационных системах, подключенных к СМЭВ;
  • применение единых технологий, форматов, протоколов межведомственного информационного взаимодействия, унифицированных программно-технических средств;
  • правомерное использование программного обеспечения, использование сертифицированных программно-технических средств и средств связи;
  • обеспечение защиты информации путем принятия организационных и технических мер, направленных на обеспечение защиты информации от неправомерного доступа, уничтожения, модифицирования, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий в отношении такой информации;
  • минимизация финансовых и временных издержек при передаче и получении информации;
  • однократный ввод и многократное использование информации в информационных системах, подключенных к СМЭВ;
  • обеспечение функционирования в реальном режиме времени;
  • соблюдение прав граждан при автоматизированной обработке информации, содержащей персональные данные.
А чтобы соисполнители "не забаловали" при присоединении к СМЭВ оговариваются и детали:
  • территориальное расположение места подключения;
  • перечень должностных лиц, уполномоченных осуществлять межведомственное информационное взаимодействие со стороны Участника;
  • список электронных сервисов, доступных данному Участнику через СМЭВ на условиях соглашения на присоединение к СМЭВ;
  • список электронных служб, которые Участник обязуется предоставлять СМЭВ на условиях соглашения на присоединение к СМЭВ;
  • описание структуры получаемых и отправляемых электронных сообщений;
  • возможность использования информации, доступ к которой ограничен федеральными законами, и порядок обращения с ней;
  • при необходимости дополнительные положения, отражающие специфику межведомственного информационного взаимодействия.
Увы, но в "информационной коммуналке" без старшего по квартире не обойтись. Не забыта не только физическая интероперабельность, но и семантическая - "Для обеспечения совместимости на семантическом уровне необходимо выполнение следующих требований:
  • справочники и классификаторы информационных систем, подключаемых к СМЭВ, должны соответствовать общероссийским классификаторам технико-экономической и социальной информации в социально-экономической области, перечень которых утвержден нормативным правовым актом об общероссийских классификаторах технико-экономической и социальной информации в социально-экономической области;
  • схемы данных информационных систем для используемых в межведомственном информационном обмене объектов и отношений должны соответствовать единому нормативному источнику информации о способах электронного представления данных - Единому реестру схем данных.
Для обеспечения совместимости на техническом уровне необходимо обеспечить соответствие технологий, стандартов и спецификаций, применяемых в информационных системах, требованиям к стандартизации информационных технологий и программного обеспечения, используемого в государственных информационных системах, в следующих областях:
  • стандарты коммуникационного взаимодействия;
  • стандарты интеграции данных;
  • стандарты управления схемами данных;
  • стандарты доступа к данным и представления информации;
  • стандарты информационной безопасности.  "
Однако - главное, вовремя остановится - пока не получился эдакий SOAsaurus - поэтому дав принципы не нужно переходить на написание инструкции по хождению для сороконожки. Все же это лишь правила, а не "Война и мир" Л.Н.Толстого
Нет, ну а где же все же XML, SOAP и прочие нужные и модные цацки ? Приоткрыв страничку - скажу - и это все есть.
"
2.1.1.    Информационный обмен в СМЭВ осуществляется в технологии веб-сервисов. Обмен данными производится путем передачи SOAP-сообщений (Simple Object Access Protocol) в соответствии со спецификацией SOAP 1.1 (http://www.w3.org/TR/soap). В качестве транспорта доставки таких сообщений выступает протокол HTTP(S) - Hypertext Transfer Protocol (Secure).
2.1.2.    Для обеспечения технологической совместимости, веб-сервисы СМЭВ должны соответствовать спецификации WS-I Basic Profile 1.1 (http://www.ws-i.org/Profiles/BasicProfile-1.1.html), разработанной организацией Web Services Interoperability Organization.
2.1.3.    Указанное требование в частности означает, что описание интерфейсов веб-сервисов должно выполняться согласно спецификации WSDL 1.1 (http://www.w3.org/TR/wsdl), а описание схемы метаданных сообщений - согласно спецификации XML Schema 1.1 (http://www.w3.org/XML/Schema).
2.1.4.    Схемы метаданных ИО СМЭВ также должны соответствовать спецификации XML Schema 1.1 в целях обеспечения возможности их использования в схемах метаданных сообщений веб-сервисов СМЭВ.
2.1.5.    Преобразование данных и метаданных должно осуществляться в соответствии со спецификацией XSL 1.1 (Extensible Stylesheet Language) (http://www.w3.org/TR/xsl), определяющей язык преобразования XML-документов XSLT (XSL Transformation) (http://www.w3.org/TR/xslt).
2.2.    Структура сообщения
2.2.1.    Общая структура SOAP-сообщения
2.2.2.    Заголовок сообщения (soap:header)
     Передача сведений  об аутентификации и авторизации (WS-security)
     Передача параметров при асинхронном взаимодействии (WS-Addressing)
2.2.3.    Тело сообщения (soap:body)
2.2.4.    Сообщение об ошибке (soap:Fault)
2.3.    Документирование элементов метаданных
2.3.1.    Все элементы метаданных в XML-схеме ИО должны быть документированы на русском языке.
"   и т.д.

и еще 8 страниц "сурового" архитектурного текста.  Естественно - наличие вменяемых стандартов - не приведет к тому, что у бесталанного программиста руки мгновенно оторвутся от того месте, на котором он сидит и прирастут обратно к плечам :-) Но правила СМЭВ определяют и это, заложены механизмы четкого арбитража и ответственности.

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

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

p.s.  А про типы файлов так и не сказал. Будет OpenOffice , будет ! 
Tags: информационное общество, электронная россия, электронное правительство
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 15 comments