Разработка формальной спецификации
Каждый обмен сообщениями в 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 |
Синтаксические требования налагают ограничения на структуру сообщений и связи между полями одного сообщения. Функциональные требования представляют собой ограничения на функциональность обработки запросов и связь между содержимым запроса и ответом на запрос.
WS-BaseFaults | WS-Resource | WS-Resource Properties | WS-Resource Lifetime | WS-ServiceGroup | |
Синтаксис | 27 | 1 | 50 | 12 | 5 |
Семантика | 2 | 11 | 109 | 39 | 68 |