Пояснительная записка Руководитель работ Потемкин М. И. Москва 2003 список исполнителей исполнитель Родионов И. В

Вид материала

Пояснительная записка

Содержание Описание архитектуры Список исполнителей Основы взаимодействия Архитектура программно-технических средств Набор процессов взаимодействия Общая схема процесса взаимодействия Клиент посылает сообщение с указанием кода процесса и другими данными диспетчеру сообщений. Ядро ЕИС Сервер получает запрос, разбирает его и обрабатывает, формирует ответ и отсылает его диспетчеру. Ядро Требования к протоколу передачи сообщений Требования к описанию сервисов Описание основных видов взаимодействий

Подобный материал:

• Пояснительная записка Директор предприятия О. А. Потемкин Начальник лесоустроительной, 4313.1kb.
• Лиснюк Оксаны Вячеславовны по русскому языку Рассмотрено на заседании педагогического, 2394.08kb.
• Пояснительная записка к выпускной квалификационной работе Исполнитель, 152.22kb.
• Пояснительная записка 5 Руководитель базы интернатуры обеспечивает в пределах своей, 683.14kb.
• Пояснительная записка к дипломному проекту Исполнитель, 97.94kb.
• Пояснительная записка Внашей стране, как и во всем мире, существует реальная угроза, 257.65kb.
• Гарина Елена Фёдоровна 2010-2011 учебный год пояснительная записка, 564.93kb.
• Список организаций, включенных в перечень исполнителей Плана реализации Государственной, 457.96kb.
• Программа элективного курса Москва 2011, 52.6kb.
• Никонов Юрий Дмитриевич классный руководитель 11 «б» класса Опытный, 2009 г пояснительная, 106.02kb.

Министерство экономического развития и торговли
Российской Федерации

Федеральная целевая программа

"ЭЛЕКТРОННАЯ РОССИЯ (2002 - 2010 годы)"

______________________________________________________________

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

Общество с ограниченной ответственностью
«Управление системных проектов Компьюлинк»


№ регистр.

Инв.№

УТВЕРЖДАЮ Директор по федеральным и региональным программам _______________ А.А. Лучин «___» ________________ 2003 г. М.П.

Описание архитектуры

программно-технических средств

первой очереди ЕИС СЭТГН


Пояснительная записка


Руководитель работ ______________ Потемкин М.И.


Москва

2003


СПИСОК ИСПОЛНИТЕЛЕЙ


Исполнитель ______________ Родионов И.В.


Реферат

Отчет с., рис.

ОГЛАВЛЕНИЕ

Введение

Целью построения Единой информационной системы первой очереди СЭТГН (далее – ЕИС СЭТГН) является создание среды взаимодействия для прикладных систем СЭТГН и смежных систем, включая:

• Ведомственные системы госзакупок (созданные как на основе СЭТГН, так и самостоятельно);
  
• Региональные системы госзакупок (созданные как на основе СЭТРМ, так и самостоятельно);
  
• Смежные системы: АИС Минфина России (казначейство), АИС Госстандарта России, АИС Госкомстата России, АИС налоговых органов и т.п.
  

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

• Хранение формальных описаний форматов данных и регламентов взаимодействия (репозитарий метаданных);
  
• Аутентификация и авторизация участников взаимодействия, пользователей и подсистем;
  
• Формальный контроль входящих и исходящих данных, соблюдения регламентов взаимодействия;
  
• Средства обеспечения гарантированной доставки сообщений (запросов и ответов на них);
  
• Средства маршрутизации сообщений;
  
• Обеспечение транзакционности взаимодействий подсистем;
  
• Аудит и протоколирование взаимодействий подсистем.
  

Основы взаимодействия

Таким образом, для решения задач взаимодействия разных информационных систем ЕИС СЭТГН должна представлять собой систему класса, аналогичного Enterprise Application Integration (EAI) и B2B (или G2G). ЕИС СЭТГН должна предоставлять единую схему взаимодействия, поддерживаемую всеми участниками обмена путём использования соответствующих адаптеров. Сценарии взаимодействия, должны быть согласованы между всеми участниками, и описывать пошаговый обмен информацией необходимый для выполнения конкретных задач. Сценарии и задачи взаимодействия могут быть как простыми, так и комплексными. Сложные сценарии могут состоять из одного или нескольких более простых сценариев.

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

В рамках работ по созданию систем первой очереди СЭТГН проведена научно-исследовательская работа по созданию предварительного описания форматов, протоколов и регламентов взаимодействия («Описание пакета форматов, протоколов и регламентов взаимодействия для передачи данных между ведомственными, региональными, муниципальными системами электронной торговли в рамках ЕИС СЭТГН»). Результаты данной работы должны быть использованы в дальнейшей разработке ЕИС СЭТГН.

Архитектура программно-технических средств

Архитектура программных средств ЕИС СЭТГН должна строится на принципах централизованного управления взаимодействием, осуществляемого ядром ЕИС и наборах сервисов, предоставляемых системами-участницами взаимодействия путём использования адаптеров или других средств. Данная архитектура, в конечном счете, должна позволить определять и выполнять бизнес-процессы, объединяющие несколько разных систем, каждая из которых отвечает за определенный фрагмент процесса.

Набор процессов взаимодействия

Набор формализованных процессов представляет собой данные, необходимые ядру ЕИС СЭТГН для координации и распределенного выполнения этих процессов. Процессы взаимодействия, так же как и форматы документов должны храниться в репозитарии метаданных ЕИС СЭТГН. Для каждого процесса должны быть определены:

• Название процесса;
  
• Код процесса;
  
• Последовательность действий (задач);
  
• Форматы данных, передаваемых в рамках этого процесса;
  
• Метаинформация о сервисах систем-участниц процесса;
  

Общая схема процесса взаимодействия

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

• Клиент (отправитель) – система, формирующая и передающая документ;
  
• Сервер – система, принимающая документ, обрабатывающее его и возвращающее ответ клиенту.
  

Общая схема взаимодействия ЕИС показана на рисунке 1.

Клиент посылает сообщение с указанием кода процесса и другими данными диспетчеру сообщений. Ядро ЕИС проверяет, что все необходимые данные предоставлены, проверяет, что предоставленные данные допустимы. В случае успешной проверки диспетчер направляет запрос обслуживающему узлу (серверу), в случае ошибки посылает сообщение клиенту. Ошибочный запрос серверу не передается.

Сервер получает запрос, разбирает его и обрабатывает, формирует ответ и отсылает его диспетчеру. Ядро получает ответ на сообщение, проверяет, что все необходимые данные предоставлены и их значения допустимы. В случае успешной проверки полученный ответ направляется клиенту. В случае ошибки при проверке формата сообщения серверу отправляется уведомления о нарушении формата передаваемых сообщений, а клиенту отправляется сообщение об ошибке, содержащее ответ сервера.

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



Рисунок 1. Общая схема процесса взаимодействия

Требования к протоколу передачи сообщений

Протокол передачи сообщений должен соответствовать следующим требованиям:

• Поддержка XML в качестве языком представления сообщений, поддержка передачи документов и фрагментов XML.
  
• Поддержка передачи двоичных данных. Передача различных видов информации, представляемых в двоичной форме, между объектами взаимодействия должна также поддерживаться протоколом передачи сообщений.
  
• Транспортировка посредством HTTP, т.к. применение HTTP в качестве транспортного уровня протокола передачи сообщений позволит существенно облегчить задачу построения ЕИС соответствующую требованиям архитектуры.
  
• Асинхронное взаимодействие.
  
• Поддержка защищенных соединений. Протокол передачи должен допускать применение криптографических алгоритмов как к передаваемому сообщению, так и к каналу взаимодействия.
  

Перечисленным требованиям соответствуют спецификации W3C SOAP (Simple Object Access Protocol) with Attachments [SOAP, SOAP-attach].

Требования к описанию сервисов

Описание сервиса подразумевается полный набор сведений о сервисе, необходимый для взаимодействия с сервисом.

• Поддержка XML Schema. Поскольку формат передаваемых сообщений описывается средствами XML Schema, описание сервисов также должно поддерживать и использовать эти описания.
  
• Поддержка SOAP. Поскольку для передачи сообщений применяется протокол SOAP, необходима возможность описания способа взаимодействия с сервисом посредством SOAP.
  
• Адресация по URI. Для идентификации адреса взаимодействия протокол должен поддерживать применение URI (Uniform Resource Identifier) [URI] – единственного универсального метода идентификации ресурсов сети Интернет.
  
• Асинхронное взаимодействие. Описание сервиса должно поддерживать асинхронную модель взаимодействия с сервисом.
  
• Типизация сервиса. Описание сервиса должно поддерживать возможность многократного использования программного интерфейса сервиса.
  
• Наличие инструментальная поддержка для разработки сервисов.
  

Данным требованиям соответствует спецификация W3C WSDL (Web Services Description Language) [WSDL], которая также является совместимой с спецификациями W3C – XML, XML Schema, SOAP, используемыми в качестве стандарта для сообщений и сервисов ЕИС СЭТГН.

Описание основных видов взаимодействий

В данном разделе приведен обзор областей, требующих построения распределенного взаимодействия систем СЭТГН и внешних смежных систем.

Между системами СЭТГН:

• Публикация извещений о проведении и результатах конкурсов, проводимых на ЭТП СЭТГН на Портале ЭГЗ;
  
• Публикация на Портале конкурсной документации и разъяснений КД;
  

Со смежными системами:

• АИС Минфина России
  
  • получения СЭТГН сведений о бюджетных ассигнованиях;
    
  • получения СЭТГН лимитов для контроля над проведением закупок;
    
  • получение СЭТГН от АИС Минфина России данных по исполнению контракта;
    
• АИС Госкомстата России
  
  • доступ к статистической информации;
    
  • предоставление отчётных данных для обработки;
    
• АИС Госстандарта России
  
  • Обновление каталогов;
    
• АИС МНС России
  
  • Получение информации о налогоплательщиках и их задолженностях;
    
• АИС лицензирующих органов
  
  • Получение информации о выданных лицензиях и сроках их действия
    
• Региональные, ведомственные и коммерческие системы электронной торговли
  
  • Перекрестная публикация извещений о проведении открытых конкурсов и их результатов на портале госзакупок СЭТГН
    
  • Агрегирование статистических сведений о закупках
    
  • Формирование общего реестра поставщиков с учетом профилей поставщиков
    
  • Формирование единой базы данных по товарам и ценам
    
  • Распространение нормативно-методических материалов и типовых форм документов.