CC BY
58
ПРИНЦИПЫ ПОСТРОЕНИЯ ГРИД С ИСПОЛЬЗОВАНИЕМ НЕБТ/п 1-ВЕБ-СЕРВИСОВ
(Работа проводилась при финансовой поддержке Федерального агентства по науке и инновациям,
г/к 01.647.11.2004, г/к 02.740.11.0388)
А.П. Демичев, кф.-м.н.; А.П. Крюков, кф.-м.н.; Шамардин Л.В.
(Научно-исследовательский институт ядерной физики им.. Д.В. Скобельцына Московского государственного университета им. М.В. Ломоносова, demichev@theory.sinp.msu.ru, kryukov@theory.sinp.msu.т, shamardin@theory.sinp.msu.ru)
В статье рассматривается возможность использования архитектурного стиля REST для создания грид-сервисов как альтернатива традиционным методам. Описываются методы создания грид-ресурсов, управления циклом их существования, способы индикации ошибок и контроля целостности передаваемой информации, предлагаемые для RESTful грид-сервисов. Показываются преимущества и ограничения такого подхода по сравнению с традиционной реализацией, основанной на спецификации WSRF.
Ключевые слова: веб-сервисы, грид, грид-сервисы, спецификация wsrf, restful-сервисы.
В настоящее время традиционная реализация для грид-сервиса - это WSRF-сервис, который является веб-сервисом, позволяющим получать доступ к ресурсам с определенным набором свойств и управляющим циклом их существования, а именно: созданием новых экземпляров ресурсов, временем их жизни и уничтожением (возможно, автоматическим) [1]. Такие веб-сервисы используют протокол HTTP в качестве средства доставки сообщений других вложенных протоколов - SOAP и семейства WS-*. Однако, несмотря на распространенность, WSRF-сервисы имеют существенный недостаток - большую сложность реализации и излишние объемы информации, участвующей в обмене сообщениями между сервисами. Эта сложность часто бывает скрыта сторонними инструментами, позволяющими автоматически генерировать программный код для реализации WSRF-сервисов. Тем не менее, подобная внутренняя реализация усложняет широкое использование таких сервисов третьими лицами, а также из сред программирования, не имеющих соответствующих инструментов автоматической генерации кода. Даже одна из наиболее полных реализаций WSRF, разработанная в Globus Toolkit версии 4, не всегда полностью следует требованиям спецификации.
Существуют альтернативные подходы к реализации веб-сервисов. В настоящей работе выбран один из них, известный как веб-сервисы, построенные с использованием архитектуры Representational State Transfer (REST), или RESTful-веб-сер-висы. Реализация клиентов такими веб-сервисами является практически тривиальной, поскольку подобные веб-сервисы используют сам протокол HTTP как основу для взаимодействия и не используют дополнительных надстроенных протоколов. На данный момент нет единых стандартов на RESTful-сервисы, есть только распространенные практики. В настоящей работе рассматривается возможность расширения стандартных методов построения RESTful-веб-сервисов с целью обеспе-
чения взаимодействия с ресурсами, имеющими цикл существования, в частности, управления временем жизни таких ресурсов. Это необходимо для реализации полноценных грид-сервисов, так как одной из характерных особенностей грид-ресурсов является ограниченный цикл существования ресурса.
Традиционные WSRF-грид-сервисы
Традиционным подходом к построению грид-сервисов является использование спецификации WSRF для реализации архитектуры OGSA [2]. Эта спецификация описывает протоколы, позволяющие производить манипуляции с ресурсами, посредством обмена сообщениями по протоколу SOAP.
Основной концепцией в архитектуре WSRF является Web Service Resource (WS-Resource) [3]. В понимании WSRF ресурсом является логическая сущность, обладающая следующими свойствами: ее можно идентифицировать, она может иметь не пустое множество свойств, которые могут быть выражены в виде XML infoset, а также цикл существования. В свою очередь, WS-Resource - это композиция из ресурса и веб-сервиса, через который можно получить доступ к ресурсу. Для каждого WS-Resource указывается End-Point Reference (EPR), содержащий адрес ресурса согласно спецификации WS-Addressing. При этом под веб-сервисом понимается сервис, имеющий интерфейс с доступом по протоколу SOAP, с транспортом по протоколу HTTP [4] или HTTPS (RFC 2818). Такой сервис имеет фиксированный URI, через который производится обращение к самому сервису независимо от выбранного ресурса. Информация о том, с каким именно ресурсом производится операция, содержится в EPR.
Спецификации WSRF также предусматривают стандартные механизмы для управления циклом существования ресурса (создание WS-Resource, присвоение ему идентификатора EPR, уничтоже-
ние WS-Resource), получения множества свойств и взаимодействия со свойствами ресурса (с представлением свойств в виде XML infoset).
Абстракция REST и RESTful-веб-сервисы
Архитектура REST, или передача состояния представлениями, является абстракцией архитектурных элементов в распределенной системе гиперданных [5]. Ключевой абстракцией информации в REST является ресурс. Ресурс R - это изменяющаяся во времени функция членства MR(t), которая ставит в соответствие времени t множество эквивалентных сущностей или значений в этот момент. Значения в данном множестве могут быть представлениями ресурса и/или идентификаторами ресурсов. В определенные моменты ресурс может соответствовать пустому множеству, что позволяет делать ссылки на ресурс до его воплощения. Для адресации ресурсов в рамках архитектуры REST используется идентификатор ресурса.
Компоненты архитектуры REST выполняют манипуляции с ресурсами между собой путем передачи представлений ресурсов, полученных в определенные моменты. Представление ресурса -это последовательность байтов плюс представление метаданных, описывающих данную последовательность. Существуют более распространенные, но менее точные термины, соответствующие представлению ресурса, например, «документ», «файл».
Взаимодействие компонентов внутри архитектуры REST происходит путем отправки запросов и получения ответов. При этом все взаимодействия не имеют собственного состояния, то есть каждый запрос содержит в себе всю информацию, необходимую для его понимания, независимо от того, какие запросы поступали до него. Запрос состоит из управляющих данных запроса, идентификатора ресурса, являющегося целью запроса, и опционального представления ресурса. Ответ состоит из управляющих данных ответа, опциональных метаданных ресурса и опционального представления ресурса.
Архитектура REST может быть применена для построения сервисов, работающих по протоколу HTTP [6], такие сервисы называют RESTful-веб-сервисами. RESTful-веб-сервис представляет собой коллекцию ресурсов, взаимодействие с которыми происходит посредством HTTP-методов GET, PUT, POST и DELETE и допустимых представлений ресурсов, согласованных между потребителем сервиса и самим сервисом. При этом важным является соответствие логической операции с ресурсом используемому HTTP-методу. Однородные по типу ресурсы объединяются в коллекции. Соответствие HTTP-методов логическим операциям над ресурсами приведено в таблице.
Использование методов HTTP в RESTful-веб-сервисах
HTTP-метод Логические операции
URI коллекции, например: http://example.com/ resources/ URI ресурса, например: http://example. com/re-sources/123
GET Получение списка всех членов коллекции, включая их полные URI Получение представления ресурса в соответствующем формате
PUT Значение, определяемое как «замена всей коллекции целиком новой коллекцией» Обновление ресурса либо создание нового ресурса в коллекции с заранее определенным идентификатором ресурса
POST Создание нового ресурса в коллекции с автоматическим присвоением идентификатора новому ресурсу. Обычно URI нового ресурса присутствует в ответе на данную операцию Адресуемый ресурс рассматривается как самостоятельная коллекция, операция соответствует операции POST над коллекцией
DELETE Значение, определяемое как «удаление всей коллекции» Удаление ресурса
В настоящее время для RESTful-веб-сервисов не существует однозначной спецификации. В [6] делается одна из первых попыток стандартизации RESTful-веб-сервисов путем введения понятия ресурсно-ориентированной архитектуры (Resource Oriented Architecture, ROA). В частности, даются более точные определения ресурса (в понимании RESTful-веб-сервиса), использования структуры Ш/-ресурсов как средства адресации ресурсов, обсуждается применение прочих HTTP-методов и использование кодов состояния HTTP. Подход к реализация грид-сервисов, предлагаемый в настоящей работе, основан на методах, рассмотренных в [6], с определенными уточнениями и расширениями их с учетом специфики грид-сервисов.
Построение грид-сервисов с использованием архитектуры REST
Концептуально между архитектурами WSRF и REST много общего: обе спецификации описывают взаимодействие с ресурсами, к которым возможен доступ через их представления (зафиксированное для WSRF- и произвольное для RESTful-сервисов).
Создание ресурсов и их свойства. Рассмотрим возможность построения грид-сервисов как RESTful-веб-сервисов на примере Simple Shopping Service из WSRF Primer [3]. Этот пример был выбран потому, что он используется для иллюстрации использования WSRF в официальной документации стандарта. Сервис представляет собой
простой сервис магазина, позволяющий пользователю создавать, получать и обновлять содержимое корзины покупок через операции «забрать» и «положить». Сервис магазина также предоставляет доступ к каталогу продуктов с возможностью поиска. Описание реализации этого сервиса выходит за рамки настоящей публикации. Код продукта из каталога и количество используются для формирования первоначальной корзины покупок, в которую затем могут быть добавлены новые продукты. Кроме того, определяется операция оформления покупки, которая взаимодействует с сервисом оплаты и переводит содержимое корзины в содержимое нового ресурса - заказа, а корзина покупок уничтожается.
Для документов будем использовать представление в виде XML по той же схеме, что и в [3].
Для создания корзины покупок клиент посылает HTTP--запрос, используя метод POST по URI коллекции корзин, https://example.com/v1/shopping-carts/:
POST /v1/shopping-carts/ HTTP/1.1 Content-Type: application/xml
<ws-ssc:Cart>
<ws-ssc:ProductCode>Cat-A2004-87968556</ws-ssc:ProductCode> <ws-ssc:Quantity>1</ws-ssc:Quantity> </ws-ssc:Cart>
Ответ сервиса содержит информацию об URI созданной корзины:
HTTP/1.1 201 Created
Location: https://example.com/v1/shopping-carts/1234
Клиент получает информацию о текущем содержимом корзины, для этого он посылает HTTP-запрос, используя метод GET по URI корзины, полученному при создании. При этом клиент использует заголовок Accept для указания формата, в котором ожидает получить содержимое корзины:
GET /v1/shopping-carts/1234 HTTP/1.1 Accept: application/xml
Клиент мог бы указать в заголовке Accept другой тип, например, application/json или text/html; в последнем случае сервер мог бы вернуть представление ресурса-корзины в виде HTML-документа. Ответ сервера с содержимым корзины: HTTP/1.1 200 OK
Content-Type: application/xml
<ssc:SimpleShoppingCart>
<ssc:Item href=''https://example.com/v1/shopping-carts/1234/5 67,,>
<ssc:ProductCode>Cat-A2 004-87968556</ssc:ProductCode> <ssc:Description>Garden String - 15 0m</ssc:Description> <ssc:Quantity>1</ssc:Quantity> <ssc:ProductPrice>1.5 9</ssc:ProductPrice> </ssc:Item> </ssc:SimpleShoppingCart>
Тело данного ответа имеет важное отличие от [3]: элемент корзины содержит атрибут href, указывающий URI ресурса, соответствующего определенному объекту, находящемуся в корзине. Это позволяет рассматривать корзину как самостоятельную коллекцию ресурсов - экземпляров объектов, находящихся в корзине. Такой подход дает возможность манипулировать составными частями ресурса без использования сложных ResourceProperty документов. Например, для из-
менения количества предметов данного типа клиенту достаточно послать запрос
PUT /v1/shopping-carts/1234/567 HTTP/1.1 Content-Type: application/xml
<ssc:Quantity>2</ssc:Quantity>
в противоположность более сложной операции изменения ResourceProperty документа с последующим анализом изменений сервисом, как это происходит при использовании WSRF. Ответ сервиса на запрос об изменениях содержит только статус-код успешного завершения операции: HTTP/1.1 204 No Content
Спецификация WSRF предусматривает возможность выбора части свойств ресурса, удовлетворяющих определенным критериям, путем запроса QueryResourceProperties. Для получения аналогичной функциональности в RESTful-грид-сервисах рекомендуется использовать запросы с HTTP--методом GET по адресу соответствующих ресурсов, содержащие дополнительную строку запроса в компоненте query URI ресурса (RFC 3986). Используемый язык запроса может быть указан в компоненте fragment URI ресурса.
Индикация ошибок. Спецификация WSRF предусматривает также универсальный подход к передаче и обработке ошибочных состояний. RESTful-грид-сервис использует для этой цели стандартные коды статусов HTTP с документами, поясняющими детали произошедшей ошибки. Согласно WS-BaseFaults [3], каждая информация об ошибке является производной от общего класса ошибок. Кроме того, для распространенных ошибок предусмотрен набор стандартных классов ошибок. RESTful-грид-сервисы должны использовать вместо соответствующих классов ошибок коды состояния HTTP со значениями 4xx и 5xx. Ошибки, не попадающие ни в один из стандартных классов, должны иметь код состояния 400 Bad Request, при этом тело ответа обязательно должно содержать представление ресурса, описывающего произошедшую ошибку. Вместо стандартной ошибки ResourceUnknownFault спецификации WS-BaseFaults следует использовать код состояния 404 Not Found, а вместо стандартной ошибки ResourceUnavailableFault той же спецификации - код состояния 403 Forbidden или 401 Unauthorized в зависимости от причины недоступности ресурса.
Для RESTful-грид-сервисов предлагается следующая интерпретация прочих стандартных кодов состояния HTTP в качестве стандартных ошибок.
• 405 Method Not Allowed. Используется в том случае, если запрашиваемая операция над ресурсом не предусматривается данным сервисом. Например, сервис должен возвращать данный код при попытке изменения методом PUT ресурса, доступного только для чтения.
• 406 Not Acceptable. Применяется для согласования представления ресурса с клиентом в случае, если клиент запросил представление ресурса
в формате, который не может быть предоставлен данным сервисом.
• 409 Conflict. Используется, когда выполнение запрошенной операции может привести сервис в невозможное или несовместимое состояние, например, при попытке создать ресурс с идентификатором, который уже присвоен другому ресурсу.
• 410 Gone. Ресурс более недоступен через данный сервис. Новый способ доступа к ресурсу неизвестен.
• 415 Unsupported Media Туре. Запрос к сервису содержал представление ресурса в формате, который не может быть обработан данным сервисом.
• 503 Service Unavailable. Данный запрос не может быть обслужен сервисом в настоящее время. Ответ с таким кодом состояния может содержать заголовок Retry-After, при наличии этого заголовка клиент может повторить попытку такого же запроса в указанное время.
Для детализации причины, вызвавшей ошибку, ответ может содержать заголовок Location с URI, указывающим на ресурс, являющийся причиной ошибки. В тех случаях, когда причиной ошибки является ресурс, к которому производилось обращение, в качестве причины ошибок можно использовать URI в формате URN (RFC 2141). В частности, далее определяются URI для некоторых стандартных причин ошибок в формате URN в пространстве имен X-RESTful-Grid.
Цикл существования ресурсов. Рассмотрим методы контроля времени жизни ресурса, а также способы уничтожения ресурсов.
Для контроля времени жизни ресурсов и управления им предлагается использовать заголовки протокола HTTP. Параметру CurrentTime спецификации WSRF соответствует стандартный заголовок Date. Для обозначения времени жизни ресурса предлагается использовать нестандартный заголовок Termination-Time, спецификация которого в нотации Augmented BNF следующая:
Termination-Time="Termination-Time" ":" rfc1123-date,
где rfc1123-date определяется согласно [4].
Данный заголовок является опциональным и может присутствовать как в запросе, так и в ответе.
Наличие заголовка Termination-Time в запросе используется для изменения времени жизни ресурса. В этом случае грид-сервис должен выполнить действия, соответствующие запросу, и изменить время жизни ресурса. В ответе на запрос должен присутствовать заголовок Termination-Time, содержащий новое время жизни ресурса. В случае, если указанное изменение времени жизни невозможно или не поддерживается для данного ресурса, грид-сервис не выполнит действие, соответствующее запросу, и вернет ответ с кодом со-
стояния 409, содержащий заголовок Location: urn:X-RESTful-Grid:invalid-termination-time.
Наличие заголовка Termination-Time в ответе грид-сервиса указывает, что данный ресурс может быть автоматически уничтожен сервисом в указанный момент, однако не гарантирует уничтожения ресурса. Отсутствие заголовка Termination-Time в ответе грид-сервиса означает, что время жизни ресурса не определено явно и клиент не должен делать предположения о времени жизни ресурса.
Для изменения времени жизни ресурса без совершения каких-либо операций с ресурсом предлагается следующий протокол. Клиент отправляет серверу запрос методом PUT, в котором присутствуют заголовок Content-Length: 0 и желаемый заголовок Termination-Time, но при этом отсутствует заголовок Content-Type. Сервис должен интерпретировать запросы, содержащие заголовок Content-Length, но без заголовка Content-Type, как запросы, не имеющие представления ресурса и, следовательно, предназначенные только для модификации метаданных ресурса. Такой протокол также не нарушает требований идемпотентности запросов PUT.
Безопасность и идемпотентность методов. Однократное создание ресурсов. Для традиционных ^SRF-веб-сервисов протокол HTTP выполняет только транспортные функции, при их реализации применяются исключительно запросы с методом POST, не являющиеся идемпотентными или безопасными. Для REST/ul-грид-сервисов используются многие другие методы протокола HTTP, поэтому особое внимание необходимо уделять требованиям безопасности и идемпотентности методов [4], а именно.
• Действия, выполняемые методами GET и HEAD, должны заключаться только в собственно возвращении представления ресурсов и не должны иметь побочных эффектов.
• Действия, выполняемые методами PUT и DELETE, должны быть идемпотентными, то есть побочные эффекты, вызываемые запросом с таким методом, должны быть одинаковыми для любого количества повторений одного и того же запроса.
Выполнение требований идемпотентности позволяет повысить надежность работы клиентских приложений через плохие каналы связи, так как в случае отсутствия ответа сервера клиент может просто повторить идемпотентный запрос еще раз.
Метод POST протокола HTTP, используемый для создания новых ресурсов, не имеет требования идемпотентности, так как она не может быть обеспечена в рамках спецификации HTTP 1.1 , однако при реализации REST/ul-грид-сервисов необходима идемпотентность всех методов, включая и те, что используются для создания новых ресурсов.
Одна из попыток обеспечения идемпотентности метода POST осуществляется в проекте спецификации Post Once Exactly (POE) [7], однако данная черновая спецификация не предусматривает способа получения клиентом ответа сервиса, содержащего результаты выполнения операции, а данные результаты в случае RESTful-грид-сервиса содержат URI созданного ресурса. Поэтому предлагается расширить спецификацию [7] следующим образом: в том случае, если сервис получает повторный запрос клиента с методом POST, соответствующий спецификации POE, ответ сервиса должен быть идентичным ответу на первый запрос, за исключением кода ответа 405 и дополнительного заголовка Allow, необходимого в ответах с кодом 405. Такая реализация позволяет обеспечить идемпотентность запросов с методом POST без потери первоначального ответа сервиса.
Для реализаций грид-сервисов, в которых использование расширений POE нежелательно, рекомендуется отказаться от использования метода POST для создания новых ресурсов и применять для этих целей исключительно метод PUT, возложив ответственность за создание уникальных идентификаторов ресурсов на клиента.
Контроль целостности передачи информации. Еще одним важным аспектом при реализации грид-сервисов является контроль за целостностью информации при обмене данными между сервисом и клиентом. Для этого предлагается использовать следующие дополнительные требования к реализациям грид-сервисов и клиентов.
• Все ответы грид-сервисов, содержащие представления ресурсов, должны иметь заголовок Content-Length.
Все ответы грид-сервисов, содержащие заголовок Content-Length, отличный от 0, должны также иметь заголовок Content-MD5.
Клиент должен проверять соответствие заголовков Content-Length и Content-MD5 при их наличии полученному представлению ресурса. Отсутствие необходимых заголовков должно быть интерпретировано как ошибка.
• В запросах клиентов рекомендуется использовать заголовки Content-Length и Content-Type, правила использования этих заголовков и интерпретации их сервисом аналогичны правилам для заголовков ответов сервиса.
Приведенные в настоящей работе подходы к реализации грид-сервисов с использованием архитектуры REST позволяют получить большую часть функциональности, доступной при традиционной реализации грид-сервисов как WSRF-сервисов. Описаны процедуры получения представления ресурсов, управления циклом существования ресурсов, способы индикации ошибок.
Тем не менее, RESTful-грид-сервисы не имеют четкой стандартизации части функциональности, аналогичной утвержденной для WSRF-сервисов: нет единого подхода к запросам части свойств ресурсов, а также не определен стандартный протокол для организации сервисных групп. Это ограничение является платой за полную свободу формата представления ресурсов, так как произвольное представление ресурсов может иметь любую структуру, в том числе отличную от стандартного подхода к представлению ресурса в виде набора его свойств.
Например, для RESTful-грид-сервиса представлением ресурса может быть изображение или какой-либо другой объект, который не имеет эффективного представления в текстовом виде, пригодного для использования внутри XML infoset. Помимо этого, построение грид-сервисов с использованием архитектуры REST имеет ряд других преимуществ: простота реализации как клиента к такому сервису, так и самого сервиса, отсутствие зависимости от средств автоматической генерации программного кода, возможность использования произвольных представлений ресурсов, а также большая устойчивость к плохим каналам связи за счет идемпотентности всех операций, которую не может обеспечить спецификация WSRF в силу своего устройства.
Авторы выражают благодарность д.ф.-м.н. В.А. Ильину (НИИ ядерной физики МГУ, г. Москва) и к.ф.-м.н. В.Н. Коваленко (ИПМ им. Келдыша, г. Москва) за плодотворные обсуждения и конструктивную критику работы.
Литература
1. Foster J., Frey S., Graham S., Tuecke K., Czajkowski D., Ferguson F., Leymann M., Nally T., Storey W., Vambenepe et al., Modeling stateful resources with web services, Globus Alliance (2004), http://www.ibm.com/developerworks/library/ws-resource/ ws-modelingresources.pdf.
2. Foster I., Kishimoto H., Savva A., Berry D., Djaoui A., Grimshaw A., Horn B., Maciel F., Siebenlist F., Subramaniam R. et al. The Open Grid Services Architecture, Version 1.0, Global Grid Forum, OGSA Working Group, 2005, http://www.gridfo-rum.org/documents/GFD.30.pdf.
3. Web Services Resource Framework (WSRF). OASIS Open (April 2006), URL: http://www.oasis-open.org/commit-tees/tc_home.php?wg_abbrev=wsrf (дата обращения: 20.07.2009)
4. Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., Berners-Lee T. Hypertext transfer protocol HTTP/1.1, RFC 2616, IETF Network Working Group (June 1999).
5. Fielding R. Architectural styles and the design of network-based software architectures, doctoral dissertation, University of California, Irvine (2000).
6. Richardson L., Ruby S. RESTful Web Services, O'Reilly Media, Inc., 2007.
7. Nottingham M. POST once exactly (POE), IETF Network Working Group Internet-Draft, http://www.mnot.net/drafts/draft-nottingham-http-poe-00.txt (March 2005).
