Наступил первый день весны и вновь счастье от межведомственного взаимодействия не наступило. В основном это связано с неготовностью инфраструктуры рсмэв, и тем, что в субъекты представлены документы по подключению в системе межведомственного взаимодействия, которые содержат ряд противоречий из-за которых организовать корректную работу и к 1 марта и к 1 июля будет затруднительно. Т.е. отсутствие корректных  документов по подключению в смэв от “оператора смэв” делает практически невозможной работу субъектов по реализации ФЗ210. Для примера ниже приведен анализа ряда противоречий по документам РСМЭВ:

Ряд требований проекта Регламента подключения региональной системы межведомственного электронного взаимодействия к единой системе межведомственного электронного взаимодействия, на соответствие которому проверяется РСМЭВ в процессе экспертизы, противоречит требованиям других документов, регламентирующих правила функционирования СМЭВ:

  • приказу Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 г. № 190 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» (далее Приказ 190);
  • методическим рекомендациям по разработке электронных сервисов и применению технологии электронной подписи при межведомственном электронном взаимодействии (далее Методические рекомендации), размещенным на технологическом портале СМЭВ, применение которых одобрено 22 декабря 2011 года Подкомиссией по использованию информационных технологий при предоставлении государственных и муниципальных услуг Правительственной комиссии по внедрению информационных технологий в деятельность государственных органов и органов местного самоуправления;
  • регламенту взаимодействия Участников информационного взаимодействия, Оператора единой системы межведомственного электронного взаимодействия и Оператора эксплуатации инфраструктуры электронного правительства при организации межведомственного взаимодействия с использованием единой системы межведомственного электронного взаимодействия версии 1.1, размещенному на технологическом портале СМЭВ http://smev.gosuslugi.ru/portal/ (далее Регламент взаимодействия).

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

 

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

В Приказе 190 SOAP (через HTTP (HTTPS)) упомянут как единственный протокол для доступа к электронным сервисам участников взаимодействия. Структура сообщений, требуемая Методическими рекомендациями, также требует использования SOAP.

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

Настройка в СМЭВ периода ожидания ответа сервиса Поставщика более чем в 2 раза меньшим, чем период ожидания, определенный в информационной системе Потребителя, снижает вероятность получения ответа Потребителем, и тем самым противоречит здравому смыслу и снижает потребительские качества СМЭВ.

 

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

Методическими рекомендациями рекомендованы 2 модели асинхронного взаимодействия с участием СМЭВ:

  • Модель асинхронного взаимодействия с повторным опросом (для

межведомственных запросов);

  • Модель асинхронного взаимодействия с обратным вызовом (для подачи заявлений с ЕПГУ).

Ни одна из этих моделей не предусматривает организации очереди для промежуточного хранения сообщений с СМЭВ. ? та, и другая модели требуют организации асинхронного взаимодействия из 2 актов синхронного взаимодействия – подачи запроса и получения ответа. Промежуточное хранение в очереди сообщений при этом требуется как на стороне Потребителя, так и на стороне Поставщика, но не СМЭВ.

 

РСМЭВ должна поддерживать маршрутизацию поступивших запросов, в том числе:

  • маршрутизацию по контенту и контексту сообщения;
  • маршрутизацию, основанную на правилах бизнес-процессов.

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

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

 

РСМЭВ должна поддерживать механизмы преобразования данных во входящих и исходящих сообщения к внутреннему каноническому формату сообщений передачи данных.

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

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

Требование преобразования данных в сообщениях противоречит пункту 40 приказа 190 «Система взаимодействия обеспечивает гарантированную доставку неискажённых сообщений…», так как преобразование является искажением сообщения.

Единственным вариантом преобразования данных во входящих и исходящих сообщениях к внутреннему каноническому формату сообщений передачи данных, не противоречащим Методическим рекомендациям и Регламенту взаимодействия, является каноникализация (Exclusive XML Canonicalization от 18 July 2002, http://www.w3.org/2001/10/xml-exc-c14n#) данных сообщения при формировании электронной подписи.

 

РСМЭВ должна обеспечивать функции широковещательной рассылки информации нескольким информационным системам, подключенным к ней.

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

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

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

     

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

    В Приказе 190 SOAP (через HTTP (HTTPS)) упомянут как единственный протокол для доступа к электронным сервисам участников взаимодействия. Формат данных сообщений, требуемый Методическими рекомендациями, явно определен и также требует использования SOAP.

    Без вступления в противоречие с требованиями Приказа 190 и Методических рекомендаций организация взаимодействия между гетерогенными транспортными системами возможна только в части использования гетерогенных протоколов, которые располагаются ниже прикладного уровня модели OSI, при использовании в качестве протоколов прикладного уровня только  SOAP через HTTP (HTTPS).

     

    Share|