2.4 Ресурсно-ориентированная архитектура
В настоящее время для RESTful-веб-сервисов не существует однозначной «официальной» спецификации. Л. Ричардсон и С. Руби проводят одну из первых попыток стандартизации RESTful-веб-сервисов путем введения концепции ресурсно-ориентированной архитектуры (Resource-Oriented Architecture, ROA) [2-12]. Авторы книги подчеркивают тот факт, что по сути не существует четких стандартов, описывающих RESTful-веб-сервисы, есть общие подходы и принципы для создания таких сервисов. Они рассматривают вопросы понимания сущности ресурсов, методы использования структуры идентификаторов ресурсов, как средств адресации ресурсов, обсуждается применение HTTP-методов и использование кодов состояния HTTP.
Другая книга, изданная недавно, «REST на практике» [2-13], фокусируется в основном на практических аспектах разработки веб-сервисов, не приводя достаточно формальных определений.
В рамках данной НИР на основе методов, предложенных в [2-12], [2-14], [2-15], [2-16] формулируется ряд определений, характеризующих принципы построения RESTful-веб-сервисов. Кроме того, вводятся дополнительные требования и рекомендации, необходимые для реализации RESTful-веб-сервисов как сервисов специализированных проблемно-ориентированных распределенных инфраструктур в области нанонаук и наук о Земле.
В контексте архитектурного стиля REST, ресурс — это сущность, обладающая достаточной информационной ценностью для того, чтобы ссылка на нее имела практический смысл.
Обычно ресурсом является документ, строка в базе данных, результат выполнения какого-либо алгоритма. Ресурсом также может являться и абстрактная концепция: например, список программ, установленных на вычислительном кластере.
Унифицированный идентификатор ресурса (Uniform Resource Identifier, URI) — это строка, определяющая имя и адрес ресурса или его представления.
Каждому ресурсу соответствует по крайней мере один идентификатор ресурса. Формальная структура идентификаторов ресурсов определяется в [2-24]. Иногда вместо термина идентификатор ресурса употребляется термин адрес ресурса, который в контексте RESTful-веб-сервисов и грид-сервисов имеет то же значение [2-17].
Существует также важная частная форма URI, называемая унифицированное имя ресурса (Uniform Resource Name, URN). Унифицированное имя ресурса используется для адресации ресурсов, для которых не предполагается обязательной доступности по сети, поэтому оно хорошо подходит для использования в качестве адресов более абстрактных концепций. Например, существует стандартная категория имен URN для книг, имеющих ISBN, и адрес urn:isbn:0596529260 соответствует книге [2-12]. Более подробно синтаксис URN определяется в [2-25].
Разрабатывая сервисы, следует выбирать унифицированные идентификаторы, обладающие описательными свойствами, то есть обеспечивающие интуитивное соответствие идентификатора адресуемому ресурсу.
Кроме того, URI грид-ресурсов должны иметь предсказуемую структуру, правила формирования которой описываются в спецификации интерфейса прикладного программирования соответствующего грид-сервиса. В частности, можно использовать элементы пути в URI для разделения уровней иерархии ресурсов сервиса, например: ресурс, соответствующий вычислительному кластеру, имеет адрес http://site.com/hpc/ , тогда хорошим выбором адреса для коллекции очередей является http://site.com/hpc/queues/, а для адресов самих очередей — http://site.com/hpc/queues/some_queue/ (для очереди с названием some_queue).
Представление ресурса — это последовательность битов в каком-либо формате, отражающая сущность ресурса.
Поскольку в общем случае ресурс является абстрактной концепцией, представление ресурса может характеризовать лишь часть его свойств. Ресурс может иметь множество представлений. Например, тот же список программ, установленных на вычислительном кластере может быть представлен в виде XML-документа, предназначенного для компьютерного анализа, либо в виде HTML-страницы для прочтения человеком. Для тех ресурсов, которые представляют собой реальные физические объекты или сущности, которые не могут быть редуцированы до чистой информации, невозможно выбрать идеального представления. В этом случае подходящим представлением будет что-либо, содержащее полезную для потребителя сервиса информацию о состоянии ресурса. Например, подходящим представлением для ресурса, соответствующего двери в комнате, может быть XML-объект, описывающий закрыта ли дверь, и заперта ли она на замок.
Связи между ресурсами — это информация о каких-либо отношениях между ресурсами, возможно доступными через разные сервисы [2-18]. Эта информация содержит полные или частичные URI ресурсов, имеющих отношение к данному, а так же указания на суть отношения. Например, представление ресурса «информация о кластере» может содержать ссылки на ресурсы «информация об очереди X данного кластера», доступ к которым возможен через этот же сервис; а так же ссылку на ресурс «правила использования кластера», доступ к которому осуществляется через другой сервис. Обычно информация о связях между ресурсами является частью представления ресурса, однако она может помещаться и в метаданные представления [2-19].
Сервис, разрабатываемый в рамках ресурсно-ориентированной архитектуры должен обладать следующими четырьмя ключевыми свойствами [2-12], [2-20]:
– адресуемостью,
– отсутствием состояния сервиса,
– связностью,
– однородностью интерфейса.
Cервис обладает свойством адресуемости, если любые (все возможные) аспекты набора данных, доступных сервису, являются ресурсами. Поскольку каждому ресурсу соответствует по крайней мере один URI, это означает,что грид-сервис предоставляет URI для любого элементарного фрагмента информации, доступ к которому он может обеспечить.
Отсутствие состояния сервиса означает, что каждый запрос к грид-сервису рассматривается в полной изоляции от других запросов. Вся информация, необходимая для интерпретации и понимания запроса, содержится в самом запросе; информация, следующая из контекста предыдущих запросов к сервису, никогда не используется [2-21]. Это не означает, что ресурс, доступ к которому обеспечивается сервисом, не имеет состояния. Это означает, что сервис «не помнит», к какому из ресурсов направляется данный запрос клиента, эта информация должна передаваться явно в самом запросе. Однако сам ресурс при этом имеет вполне определенное состояние, которое может изменяться в результате выполнения запросов, посылаемых клиентом или внешних факторов.
Сервис обладает свойством связности, если все представления ресурсов сервиса, кроме, возможно, представлений, идентификаторы которых генерируются по алгоритмическим правилам, описанным в спецификации интерфейса прикладного программирования, образуют односвязный направленный граф. Свойство связности является очень важным для REST-ful-веб-сервисов, так как информация о связях между ресурсами может использоваться клиентами для обнаружения идентификаторов интересующих ресурсов [2-22].
Однородность интерфейса означает, что для выполнения любых операций с ресурсами используются стандартные методы протокола HTTP (более подробная информация о них содержится в спецификации [2-8]). При этом выполняемая операция должна концептуально совпадать с используемым методом [2-23]. Соответствие HTTP-методов логическим операциям над ресурсами приведено в таблице 2.1.
Концептуально между архитектурами WSRF и REST много общего [2-48]: обе спецификации описывают взаимодействие с ресурсами, к которым возможен доступ через их представления (зафиксированное для WSRF- и произвольное для RESTful-сервисов).
|
