НовостиОбзорыСобытияIT@WorkРеклама
Документооборот/ECM:

Блог

Вот такие Требования – все переходим на Web Services

В продолжение предыдущего поста на тему Минкомсвязи утвердило 27.12.2010 своим приказом N  190 "Технические требования к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия"

Вот начало текста Приказа:

В соответствии с пунктом 3 постановления Правительства Российской Федерации от 8 сентября 2010 года N 697 "О единой системе межведомственного электронного взаимодействия" (Собрание законодательства Российской Федерации, 2010, N 38, ст.4823) приказываю:
1. Утвердить прилагаемые Технические требования к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия
Сами требования приведены, например например на сайте  сайте "КонсультантПлюс".

Я уже говорил, что некоторые интересные замечания-комментарии по поводу Требований уже сделала в своем блоге Наталья Храмцовская.
[spoiler]
Я не очень большой знаток тонкостей ИТ-стандартов, но есть сильное подозрение, что данные требования – это адаптированный перевод какого-то довольно общего стандарта Web Services, возможно 10-летней давности.
Правда, там еще имеется несколько пунктов по поводу ЭЦП. Было бы интересно получить комментарии от наших спецов по этому вопросу. Но на первый взгляд сведения в "Требованиях" выглядят слишком общими и не очень понятым (например, какие именно механизмы ЭЦП должны тут применять).

Попробую сформулировать еще несколько вопросов.
    Правильно ли мое предположение о том, что данные Требования – это перевод какого-то стандарта Web Services?
    Какую юридическую силу имеет данный документ? Это законодательное требование или рекомендации.
    Имеют ли отношение эти Требования имеют к проекту МЭДО, реализуемому ФСО?
    Каково соотношение данных Требований и реальной ситуации в области межведомственного взаимодействия?
    Как эти требования соотносятся в утвежденным в конце 2010 года стандартом обмена электронными сообщениями?
    Участвовало ли как-то российское СЭД-сообщество в подготовке данного документа?

Вот такие Требования – все переходим на Web Services

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

А что плохого в файловом обмене? Особенно для обмена в длинных транзакциях?
Каждый способ хорош для своих задач.

Да, конечно. Более того, известно, что у WS и SOA одна из ключевых проблем - производительность и масштабирование.
Кстати, в Требованиях ничего про ПиМ не говорится. А было бы полезно сказать
Михаил Романов
Ну, например, разработчки-поставщики СЭД
Вариант.
Однако, здесь я вижу 2 проблемы:
- каждый поставщик будет продавливать свои варианты. А заготовки для обмена систем (если даже не готовые механизмы) есть у всех поставщиков, и как человек участвоваший в разработке одного из механизмов обмена скжу честно: переделка такого механизма - процесс не дешовый.
- не ясно какой профит получат поставщики от этого стандарта (если только в качестве стандарта не будет принят их собственный вариант). Они будут продавать больше систем? Вроде нет. Они заработют больше на доработках. Скорее нет, чем да (они уже не смогут разрабатывать такой механизм каждый раз на каждом внедрении, да и вообще - им придется реализовать этот механизм просто чтобы было меньше проблем на тендерах (а там любят включать что ни попадя в требования).

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

Кстати, в Требованиях ничего про ПиМ не говорится.
А что такое ПиМ (сокращение не знакомо).
Михаил Романов
Кстати замечу, что WS - это почти автоматически требование on-line работы, что в общем случае нужно не всегда и не всегда оправдано. А в случае документооборота - даже почти всегда не оправдано (конечно сервисы можно использовать просто как транспорт при периодическом обмене - но это не самый эффективный механизм для подобного режима работы.

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