Техническое задание на выполнение работ по теме

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

Техническое задание

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

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

• Техническое задание на выполнение консалтинговых работ (pr-услуг) по проекту «Стоматологическая, 30.03kb.
• Техническое задание на выполнение работы «Разработка Стратегии развития города Харькова, 138.14kb.
• Техническое задание предмет государственного контракта, 228.39kb.
• Техническое задание на выполнение работ по созданию продукции производственно-технического, 155.05kb.
• Техническое задание по лотам №№1-3 Санкт-Петербург, 7409.78kb.
• Техническое задание по лотам №№1-4 Санкт-Петербург, 4258.07kb.
• Техническое задание на съемку Разрешение на выполнение работ, 341.46kb.
• Г. С. Иванов 2011 г. Техническое задание, 198.02kb.
• Техническое задание к аукционной документации Наименование выполняемых работ, 243.15kb.
• Техническое задание на выполнение работ по разработке Стандарта организации «Устройство, 70.39kb.

Требования к функциям (задачам), выполняемым системой

1. Требования к архитектурным принципам технической реализации ЕСД Кадастр

Все решения и их техническая реализация должны соответствовать следующим архитектурным принципам:

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

2.  Журналирование и нотаризация операций, позволяющие передавать во внешнюю систему аудита информацию: о совершаемых в системе операциях (времени, пользователя, и сути операции), о состояниях системы для удостоверения времени совершения операций и фактов нахождения системы в определённых состояниях в определённый момент времени.. При этом разрабатываемые интерфейсы должны удовлетворять требованиям, предъявляемым к системам аудита, и определенных в соответствующих технических решениях НИОКР.

2. Требования к реализации процедур электронного взаимодействия в ЕСД Кадастр

ЕСД Кадастр функционирует путем реализации процедур электронного взаимодействия.

Функционирование ЕСД Кадастр обеспечивается:

• Поддержкой внешнего интерфейса пользователей, обеспечивающего интерактивное общение с системой внешних пользователей;
  
• Администрированием узла ЕСД Кадастр.
  

1. Процедуры электронного взаимодействия (ПЭВ) ЕСД Кадастр предназначены для автоматизации процессов взаимодействия пользователей ЕСД Кадастр.

ПЭВ представляет собой сценарий вызова электронных административных регламентов (ЭАР) субъектов взаимодействия.

Электронный административный регламент автоматизирует посредством реализации Web-сервиса логически обособленную операцию, выполняемую субъектом на основании собственной нормативно-правовой базы при взаимодействии с другими субъектами (примером такой операции является процедура выдачи другому субъекту некоторой выписки или справки).

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

2. Описание процедур электронного взаимодействия (бизнес-процессов системы) должно выполняться на языке BPEL4WS (Business Process Execution Language for Web Services) в соответствии с версией спецификации 1.1.

Язык выполнения бизнес-процессов для Web-сервисов BPEL4WS позволяет определять бизнес-процессы, которые охватывают несколько Web-сервисов и стандартизируют обмен сообщениями между участниками взаимодействия. Он обеспечивает переносимость и совместимость бизнес-процессов в различных средах разработки и на различных платформах, определяя правила выполнения и обмена сообщениями.

Разработанная ПЭВ должна быть опубликована в качестве Web-сервиса в реестре сервисов узла ЕСД Кадастр.

Перед публикацией разработанная ПЭВ должна быть отлажена и протестирована средствами подсистемы исполнения ПЭВ узла ЕСД Кадастр.

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

Для определения текущего состояния выполняемой ПЭВ должны применяются два типа метрик. Первый тип характеризует стадию, на которой ПЭВ может находиться, второй тип – макросостояние.

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

1. Процедура электронного взаимодействия ЕСД Кадастр должна содержать в своем описании следующие параметры:

• Название;
  
• Описание;
  
• Точка входа в соответствующий ПЭВ (URL, телефон, факс и т.п.) или ссылка на другую процедуру взаимодействия.
  
• Идентификатор ПЭВ;
  
• Ссылка на WSDL- и BPEL-документы, содержащие описания соответствующего Web-сервиса или сценария;
  
• Метрики ПЭВ.
  

Технические спецификации ПЭВ должны храниться и исполняться в специальной подсистеме исполнения ЕСД Кадастр.

Web-сервисы должны разрабатываться на основе следующих Web-стандартов:

• SOAP (Simple Object Access Protocol) —протокол для посылки сообщений по протоколу HTTP и другим Internet-протоколам;
  
• WSDL (Web Services Description Language) — язык для описания программных интерфейсов Web-сервисов;
  
• UDDI (Universal Description, Discovery and Integration) — стандарт для индексации Web-сервисов.
  

SOAP — это стандарт для отсылки и получения сообщений по Internet. Спецификация SOAP определяет XML-«конверт» для передачи сообщений, метод для кодирования программных структур данных в формате XML, а также средства связи по протоколу HTTP.

Для того чтобы приложения могли использовать Web-сервисы, программные интерфейсы последних должны быть детально описаны. Описание должно включать такую информацию, как протокол, адрес сервера, номер используемого порта, список доступных операций, формат запроса и ответа. Web-сервисы должны быть описаны в WSDL-документах, которые размещаются в системе. WSDL-документ может ссылаться на другие WSDL-документы и документы XSD (XML Schema), в которых описаны типы данных, используемые Web-сервисами.

Задача UDDI — предоставить механизм для публикации информации о Web-сервисах, а также обеспечить поддержку поиска доступных Web-сервисов. В целом UDDI — это регистрационная система, куда входят набор XML-файлов и ассоциированные схемы, которые содержат описания предоставляемых Web-сервисами услуг.

Помимо трёх основных стандартов Web-сервисов, к Web-сервисам ЕСД Кадастр предъявляются требования дополнительных стандартов Basic Profile 1.0 и WS-Addressing.

Примечание. WS-I Basic Profile (ссылка скрыта) - это набор руководств, в которых содержатся рекомендации по использованию основных спецификаций Web-сервисов (SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0 и XML Schema) для реализации взаимодействия Web-сервисов. Данный документ охватывает следующие технологии Web-сервисов:

• передача сообщений: обмен элементами протокола Web-сервисов, происходящий, как правило, через сеть;
  
• описание: перечисление сообщений, связанных с Web-сервисом;
  
• обнаружение: метаданные, которые позволяют объявить о функциональных возможностях Web-сервиса;
  
• безопасность: механизм, обеспечивающий целостность, конфиденциальность, аутентификацию и авторизацию.
  

Спецификация WS-Addressing определяет правила обмена и расшифровки сообщений различных Web-сервисов. WS-Addressing, устанавливает не зависящие от транспорта механизмы, предназначенные для адресации Web-сервисов и сообщений.

Web-сервисы должны быть зарегистрированы в реестре узла ЕСД Кадастр, на котором размещены ПЭВ, использующие эти Web-сервисы.

Используемые при взаимодействии Web-сервисов типы данных должны быть зарегистрированы в репозитариях узлов ЕСД Кадастр.

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

В случае, когда обращение к функции Web-сервиса происходит синхронно, должен использоваться единственный метод, возврат из которого означает завершение выполнения функции. Использование синхронного механизма требуется только в том случае, когда выполнение операции длится относительно небольшое время (не более 10 сек).

В случае, когда обращение происходит асинхронно, взаимодействие должно осуществляется согласно спецификации WS-Addressing [WSA]. Асинхронное взаимодействие должно осуществляться с помощью двух синхронных операций – одной на стороне Web-сервиса, другой – на стороне сервиса ПЭВ. При этом предполагается, что ПЭВ отправляет сообщение Web-сервису с необходимой корреляционной информацией. После получения сообщения Web-сервис должен синхронно уведомлять ПЭВ об успешности вызова и инициирровать обработку запроса. После завершения обработки Web-сервис должен синхронно вызывать специальный метод сервиса ПЭВ (информация о параметрах вызова берется из WSA-заголовков) и передавать результат обработки. Результатом работы метода сервиса ПЭВ должен являться синхронный ответ сервиса об успешности приема данных. Не допускается эмуляция асинхронной работы с помощью периодического вызова синхронных методов с целью получения статуса инициированной операции.

При необходимости Web-сервис должен иметь возможность получать авторизационную информацию о пользователе и экземпляре ПЭВ с помощью подсистемы безопасности узла ЕСД Кадастр.

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

Любой внешний Web-сервис должен обладать двумя синхронными методами: startWork (вызывается в начале ПЭВ для выделения необходимых ресурсов) и endWork (вызывается в конце ПЭВ для освобождения ресурсов). Метод startWork должен обладать специальным параметром, который определяет режим работы сервиса – рабочий или тестовый (
, возможные значения – work или test). В случае рабочего режима сервис должен работать по стандартному алгоритму, который определен спецификацией сервиса. В тестовом режиме сервис не должен использовать реальных ресурсов и отвечать на все запросы ПЭВ в реальном времени фиксированными тестовыми значениями, которые должны быть определены в спецификации. Отсутствие взаимодействия с реальными ресурсами означает, что в тестовом режиме сервис должен работать независимо от состояния используемых баз данных, интегрированных систем и т.д. В тестовом режиме должна работать первичная (та, которая не зависит от ресурсов) валидация входных параметров методов.

Для возможности выполнения транзакций каждый Web-сервис должен обладать следующими синхронными методами: startTransaction, commitTransaction, rollbackTransaction. Метод startTransaction должен определять начало транзакции и возвращать ее идентификатор, который используется в остальных методах. Метод commitTransaction должен использоваться для успешного завершения транзакции, rollbackTransaction – для отката в случае возникновения ошибок.

1. В 2005 году подлежат реализации следующие процедуры электронного взаимодействия:

• «Выполнение учетно-регистрационных действий»;
  
• «предоставление сведений о результатах формирования земельных участков и объектов недвижимости»;
  
• «Реализация схем взаимного предоставления графической информации»;
  
• «предоставление сведений о земельных участках, правах, объектах недвижимости и кадастровой стоимости»
  

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

1. Требования к поддержке внешнего интерфейса пользователей, обеспечивающего интерактивное общение с системой

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

Внешний интерфейс ЕСД Кадастр реализуется на пользовательском портале системы и должен обеспечивать:

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

4. Требования к администрированию узла ЕСД Кадастр

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

Функция администрирования обеспечивается Порталом администрирования СЭВ, который обеспечивает возможность настройки динамической части СЭВ сообразно потребностям пользователей и включает:

• интерфейс администратора реестра;
  
• интерфейс администратора репозитария;
  
• интерфейс администратора подсистемы ССК;
  
• интерфейс администратора модуля конструирования ПЭВ;
  
• интерфейс администратора модуля авторизации;
  
• интерфейс администратора модуля протоколирования;
  
• интерфейс администратора подсистемы оповещений;
  
• интерфейс администратора транспортной подсистемы;
  
• интерфейс администратора подсистемы управления запросами.