Тестирование софта - статьи

       

Регламентирующие документы и требования к реализациям ИПО Грид


Как упоминалось во введении, в настоящее время при разработке ИПО Грид используются два семейства стандартов: OGSA и WSRF. Рассмотрим особенности формализации требований указанных стандартов.

При изучении стандарта OGSA оказалось, что:

  1. стандарт носит описательный характер, требования нечётко выражены;
  2. стандарт практически не содержит функциональных требований;
  3. в стандарте не приводятся описания форматов сообщений и протоколов удаленного обращения к сервисам;
  4. стандарт признан устаревшим по сравнению с новыми подходами к организации удаленных вызовов, основанных на Web-сервисах.

По этим причинам стандарт OGSA не подходит в качестве основы для разработки формальных спецификации и основанного на них тестового набора.

Стандарт WSRF больше подходит для формализации. Стандарт содержит 5 спецификаций:

  1. WS-BaseFaults ? определяет формат сообщений об ошибках и механизм их обработки;
  2. WS-Resource ? определяет само понятие WS-Resource, форматы сообщений и семантику сервисов управления ресурсом;
  3. WS-ResourceLifetime ? определяет механизмы прекращения существования WS-Resource;
  4. WS-ResourceProperties - определяет, как WS-Resource связан с интерфейсом, описывающим Web-сервис, а также позволяет извлекать, изменять и уничтожать свойства WS-ресурса;
  5. WS-ServiceGroup ? определяет интерфейс к набору гетерогенных Web-сервисов.

Рассмотрим понятие ресурса (Resource) и WS-ресурса (WS-Resource), введенных в WS-Resource. Ресурс ? это логическая сущность, обладающая следующими характеристиками:

  1. идентифицируемость;
  2. наличие “времени жизни”;
  3. наличие множества (быть может пустого) свойств, представимых в XML InfoSet .

Теперь перейдем к понятию WS-ресурса. WS-ресурс представляет собой композицию ресурса и Web-сервиса, посредством вызова методов или полей которого осуществляется доступ к ресурсу. WS-ресурс также должен быть идентифицируемым (роль идентификатора должен играть XML элемент типа EndpointReference, описание которого содержится в стандарте WS-Addressing), а множество свойств ресурса, ассоциированного с сервисом, ? представимым в XML InfoSet.

Стандарт WSRF весьма удобен для анализа по причине его структурированности.
Так, например, большая их часть функциональных требований снабжена ключевыми словами стандарта RFC 2119 ? MUST, SHOULD, MAY. Кроме того, большинство требований снабжено блоками объяснений и примерами, написанными на псевдокоде, имеющем много общего с языком WSDL 2.0 описания Web-сервисов. Отдельные части стандарта имеют различные уровни обязательности в градации RFC 2119. А именно: WS-ресурс обязан (MUST) реализовывать требования спецификаций WS-Resource и WS-ResourceProperties, ему следует (SHOULD) руководствоваться требованиями WS-BaseFaults и он может (MAY) удовлетворять требованиям WS-ResourceLifetime. Следовательно, при создании тестового набора наиболее пристальное внимание нужно уделить именно первым двум обязательным спецификациям. Действительно, такой подход существенно упрощает как структуру тестового набора, так и его размер, при этом сохраняя корректность тестов как решения задачи соответствия. Итак, спецификация WS-Resource содержит определения ресурса и WS-ресурса. Также она содержит описания двух сообщений об ошибках, которые WS-ресурс может (MAY) возвращать в ответ на запросы. Что же касается спецификации WS-ResourceProperties, то в ней описан следующий способ хранения свойств WS-ресурса. Каждое свойство WS-ресурса представляет собой XML-элемент, полями которого являются уникальное имя свойства (в терминах спецификации WS-ResourceProperties ? QName), значение свойства и, возможно, служебные параметры. Все свойства ресурса объединены в некоторую композицию, называемую Resource Property Document (далее RPD), имеющую собственный идентификатор. Иными словами, свойства ресурса являются дочерними элементами по отношению к некоторому корневому элементу ? фактически, идентификатору RPD. Вместе с тем не указывается, каким именно образом сервис должен реализовывать свой RPD. В спецификации WS-ResourceProperties описаны следующие обмены сообщениями:

  1. GetResourcePropertyDocument ? получение всех свойств WS-ресурса;
  2. GetResourceProperty ? получение определенного свойства WS-ресурса;
  3. GetMultipleResourceProperties ? получение нескольких свойств WS-ресурса;
  4. QueryResourceProperties ? выяснение структуры свойств WS-Resource и выполнение запросов к RPD  и вычислений над его элементами (отдельно указывается диалект, на котором записано вычисляемое выражение, примером такого диалекта может служить язык XPath);
  5. PutResourcePropertyDocument ? замена всего RPD WS-ресурса “новым” RPD;
  6. SetResourceProperties ? изменение нескольких свойств WS-ресурса (фактически, некоторая композиция следующих трех обменов сообщениями);
  7. InsertResourceProperties ? добавление новых свойств WS-ресурса;
  8. UpdateResourceProperties ? изменение значений свойств WS-ресурса;
  9. DeleteResourceProperties ? удаление свойств WS-ресурса.
В ходе анализа стандартов были выделены 325 функциональных требований, из них 29 относятся к спецификации WS-BaseFaults, 12 ? к WS-Resource, 51 ? к WS-ResourceLifetime, 159 ? к WS-ResourceProperties, 73 ? к WS-ServiceGroup.

Содержание раздела