Разработка формальной спецификации

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

Благодаря этому в рассматриваемом методе формализации требований к ИПО Грид Web-сервис моделируется как объект некоторого класса, а обмены сообщениями между клиентом ИПО и реализацией представляются как вызовы методов объекта. Модельное состояние сервиса формализуется как набор полей объекта.

Такой способ моделирования неявно подразумевает синхронный сценарий взаимодействия между клиентом и сервисом: после отправки запроса клиент ожидает ответа. Не допускаются сценарии, в которых клиент может послать серию запросов, не дожидаясь ответов. Однако, анализ сценариев использования Грид-систем показал, что большинство современных клиентских приложений разрабатываются в синхронной парадигме. Более того, сам стандарт WSRF описывает семантику поведения сервиса в синхронном стиле. По этим причинам в рассматриваемом методе к формализации требований мы моделируем обмены сообщениями между клиентом и ИПО Грид как процедурные вызовы.

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

EndpointReference ? модель идентификатора WS-ресурса, т.н. ссылка на конечную точку, удовлетворяющая требованиям стандарта WS-Addressing адресации Web-сервисов;
ResourcePropertyDocument ? модель RPD WS-ресурса как множества элементов, моделирующие отдельные свойства (properties) ресурса;
набор параметров модели, учитывающих отсутствие поддержки ряда необязательных обменов сообщениями в реализации;
CurrentTime ? переменная, определяющая текущее системное время;
TerminationTime ? переменная, определяющая время прекращения существования WS-ресурса.

Наличие первого поля определяется требованием спецификации WS-Resource об идентифицируемости.
Что же касается второго и третьего пунктов, то на них стоит остановиться поподробнее. Свойство ресурса как элемента RPD в спецификации моделируется классом со следующими полями: идентификатор-имя свойства (QName), значение свойства и минимальное количество его включений в RPD. Наличие последнего поля продиктовано рядом требований стандарта, касающихся тех свойств WS-ресурса, у которых оно является нулевым, т.е. наличие этого свойства, вообще говоря, необязательно. Что касается третьего пункта, то его наличие связано со спецификой организации стандарта WSRF 1.2. Дело в том, что требования стандарта, находящиеся даже в одной и той же его части, совершенно необязательно имеют один и тот же “ранг” в градации RFC 2119, т.е. ключевые слова в них различные. В Таблице 1 изображено распределение требований по частям стандарта в зависимости от их “ранга”:

	WS-BaseFaults	WS-Resource	WS-Resource Properties	WS-Resource Lifetime	WS-ServiceGroup
MUST	17	6	115	30	41
SHOULD	1	0	12	8	15
MAY	11	6	32	13	17

Таблица 1. Распределение требований по отдельным частям стандарта WS-RF. Таким образом, в спецификации было формализовано около половины всех требований стандарта WSRF (порядка 160 требований), и порядка 60% содержащихся в частях WS-Resource, WS-ResourceLifetime и WS-ResourceProperties стандарта WSRF требований. Реализация остальных требований осуществлялась в медиаторе. Стоит также упомянуть о полях CurrentTime и TerminationTime класса WSResourceSpecification. Они используются для формализации требований “времени жизни” из спецификации WS-Resource, а также с требований спецификации WS-ResourceLifetime. Сигнатура метода, моделирующего отдельный обмен сообщений стандарта WSRF, определяется структурой сообщений запросов и ответов. Запросы представляются в виде набора параметров спецификационного метода, ответы представляются как возвращаемые значения метода, а сообщения об ошибках моделируются исключениями. Всё множество требований можно разделить на две основные группы: синтаксические и функциональные.

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

	WS-BaseFaults	WS-Resource	WS-Resource Properties	WS-Resource Lifetime	WS-ServiceGroup
Синтаксис	27	1	50	12	5
Семантика	2	11	109	39	68

Таблица 2. Соотношение между синтаксическими и семантическими требованиями стандарта WS-RF. Функциональные требования к реализациям WSRF представляют собой описания простых операций, таких как изменение значения поля ресурса, добавление или удаление свойств (операции с множеством), детерминированных и полностью определенных. Такие требования в рамках предлагаемого метода моделируются в явном виде с использованием блоков update, поддерживаемых в реализации UniTESK ? инструменте JavaTESK. update-блок содержит инструкции, которые явным образом изменяют значения полей модельного состояния в соответствии с текстом требования стандарта. Синтаксические требования мы предлагаем проверять в медиаторах на этапе разбора сообщений, полученных от целевой системы.