Регламентирующие документы и требования к реализациям ИПО Грид
Как упоминалось во введении, в настоящее время при разработке ИПО Грид используются два семейства стандартов: OGSA и WSRF. Рассмотрим особенности формализации требований указанных стандартов.
При изучении стандарта OGSA оказалось, что:
- стандарт носит описательный характер, требования нечётко выражены;
- стандарт практически не содержит функциональных требований;
- в стандарте не приводятся описания форматов сообщений и протоколов удаленного обращения к сервисам;
- стандарт признан устаревшим по сравнению с новыми подходами к организации удаленных вызовов, основанных на Web-сервисах.
По этим причинам стандарт OGSA не подходит в качестве основы для разработки формальных спецификации и основанного на них тестового набора.
Стандарт WSRF больше подходит для формализации. Стандарт содержит 5 спецификаций:
- WS-BaseFaults ? определяет формат сообщений об ошибках и механизм их обработки;
- WS-Resource ? определяет само понятие WS-Resource, форматы сообщений и семантику сервисов управления ресурсом;
- WS-ResourceLifetime ? определяет механизмы прекращения существования WS-Resource;
- WS-ResourceProperties - определяет, как WS-Resource связан с интерфейсом, описывающим Web-сервис, а также позволяет извлекать, изменять и уничтожать свойства WS-ресурса;
- WS-ServiceGroup ? определяет интерфейс к набору гетерогенных Web-сервисов.
Рассмотрим понятие ресурса (Resource) и WS-ресурса (WS-Resource), введенных в WS-Resource. Ресурс ? это логическая сущность, обладающая следующими характеристиками:
- идентифицируемость;
- наличие “времени жизни”;
- наличие множества (быть может пустого) свойств, представимых в 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 описаны следующие обмены сообщениями:
- GetResourcePropertyDocument ? получение всех свойств WS-ресурса;
- GetResourceProperty ? получение определенного свойства WS-ресурса;
- GetMultipleResourceProperties ? получение нескольких свойств WS-ресурса;
- QueryResourceProperties ? выяснение структуры свойств WS-Resource и выполнение запросов к RPD и вычислений над его элементами (отдельно указывается диалект, на котором записано вычисляемое выражение, примером такого диалекта может служить язык XPath);
- PutResourcePropertyDocument ? замена всего RPD WS-ресурса “новым” RPD;
- SetResourceProperties ? изменение нескольких свойств WS-ресурса (фактически, некоторая композиция следующих трех обменов сообщениями);
- InsertResourceProperties ? добавление новых свойств WS-ресурса;
- UpdateResourceProperties ? изменение значений свойств WS-ресурса;
- DeleteResourceProperties ? удаление свойств WS-ресурса.
