Структура ресурсов веб-служб
![]() | Эта статья может содержать чрезмерные или неуместные ссылки на самостоятельно опубликованные источники . ( сентябрь 2011 г. ) |
Web Services Resource Framework ( WSRF ) — это семейство опубликованных OASIS спецификаций для веб-сервисов . Основными участниками являются Globus Alliance и IBM .
сам Веб-сервис по себе номинально не сохраняет состояние , т. е. не сохраняет никаких данных между вызовами. Это ограничивает возможности веб-сервисов.
До появления WSRF ни один стандарт в семействе спецификаций веб-служб не определял явно, как обрабатывать взаимодействия с удаленными ресурсами с отслеживанием состояния. Это не означает, что веб-сервисы не могут иметь состояние. При необходимости веб-сервис может читать данные из базы данных или использовать состояние сеанса с помощью файлов cookie или WS-сеанса.
WSRF предоставляет набор операций, которые веб-службы могут использовать для реализации взаимодействия с отслеживанием состояния; Клиенты веб-сервисов взаимодействуют со службами ресурсов , которые позволяют хранить и извлекать данные. Когда клиенты обращаются к веб-службе, они включают идентификатор конкретного ресурса, который должен использоваться внутри запроса, инкапсулированный в ссылку на конечную точку WS-Addressing . Это может быть простой адрес URI или сложный XML-контент, который помогает идентифицировать или даже полностью описать конкретный ресурс.
Наряду с понятием явной ссылки на ресурс существует стандартизированный набор операций веб-сервиса для получения/установки свойств ресурса. Их можно использовать для чтения и, возможно, записи состояния ресурса, аналогично использованию переменных-членов объекта рядом с его методами. Основной выгодой от такой модели являются инструменты управления, которые могут перечислять и просматривать ресурсы, даже если у них нет других знаний о них. Это основа WSDM .
Проблемы с WSRF
[ редактировать ]WSRF не лишен противоречий. Самым фундаментальным является архитектурный вопрос: являются ли распределенные объекты с состоянием и операциями лучшим способом представления удаленных ресурсов? Это почти порт в XML шаблона распределенных объектов , примерами которого являются CORBA и DCOM . Ресурс WSRF может быть объектом с отслеживанием состояния, на который несколько клиентов имеют ссылки на ресурсы, а сама спецификация WSRF не решает таких проблем, как изоляция и доступность, полагаясь на компонуемый характер спецификаций веб-сервисов для решения этих проблем. Многие стеки WSRF, по-видимому, позволяют избежать этих проблем за счет низкой доступности, сопоставляя 1:1 ссылку на ресурс WSRF с экземпляром локального объекта, который в C++ и Java обычно вообще не является постоянным (за исключением тех, которые привязаны к базе данных). через некоторый механизм сохранения). Однако существуют реализации WSRF, поддерживающие постоянство, кластеризацию и высокую доступность ресурсов (например, в WebSphere Application Server ).
При представлении сети с распределенными объектами WSRF также находится в противоречии с REST моделью сети , в которой все является ресурсом, но в которой все действия выполняются посредством ограниченного и стандартизированного набора операций. В некотором смысле эти две модели ближе, чем чистые SOAP и REST , поскольку обе они имеют ресурсы с отслеживанием состояния на дальнем конце. Однако REST, реализованный на HTTP , предполагает, что URL — это все, что необходимо для обращения к ресурсу — нет необходимости в сложности WS-Addressing ReferenceParameters. Идея управления сроком службы удаленного контента посредством возобновляемой аренды вызывает особую критику. Другая проблема с архитектурой сообщества REST заключается в том, что обратные вызовы/уведомления, как описано в WS-Notification , не проходят через брандмауэры. Вот почему конструкции REST предпочитают опросы, например, в RSS и Atom (стандартных) каналах . WSRF не сделал ничего, чтобы сделать SOAP более приемлемым для сообщества REST.
Внедрение WSRF также вызвало раскол в мире WS-*. Впервые о ней было объявлено миру на мероприятии Global Grid Forum в феврале 2004 года как о преемнике Open Grid Services Infrastructure . Его ограниченная совместимость с основной архитектурой WS-I вызвала несогласие со стороны сетевого сообщества Великобритании. [1] В конечном итоге Global Grid Forum изолировал свои зависимости от WSRF в профиле WSRF для своей архитектуры Open Grid Services . Протоколы WSRF также использовались WSDM как средство взаимодействия с управляемыми ресурсами, описанными в WSDM. Однако мир WS-* не был объединен единым стандартом управления веб-сервисами: Microsoft, Sun и другие решили использовать WS-Management с его зависимостью от WS-Transfer как средства описания управляемых ресурсов.
Характеристики компонентов
[ редактировать ]- WS-Resource определяет WS-ресурс как совокупность ресурса и веб-службы, через которую к ресурсу можно получить доступ.
- WS-ResourceProperties описывает интерфейс для связывания набора типизированных значений с WS-ресурсом, который можно читать и манипулировать стандартным способом.
- WS-ResourceLifetime описывает интерфейс для управления временем жизни WS-ресурса.
- WS-BaseFaults описывает расширяемый механизм для расширенных SOAPFaults .
- WS-ServiceGroup описывает интерфейс для работы с коллекциями WS-ресурсов.
Также имеет значение WS-Notification , в котором говорится, как передавать другим веб-сервисам информацию о том, что происходит.
Реализации
[ редактировать ]Реализация базовой семантики получения/установки свойств ресурсов WSRF относительно проста. Самой сложной проблемой, вероятно, является возврат ошибок в виде базовых ошибок WSRF, если этого требует спецификация, поскольку сами стеки SOAP предпочитают выдавать SOAPFault ошибки . Управлять временем жизни ресурсов сложнее, но это необязательно, как и WS-Notification , который труднее всего тестировать.
- Globus Toolkit версии 4 содержит реализации WSRF на Java и C; многие другие инструменты Globus были перестроены на основе WSRF.
- WebSphere Application Server версии 6.1 предоставляет среду WSRF, которая поддерживает как простые, так и кластерные конечные точки WSRF с высоким уровнем доступности.
- У Apache Foundation есть Muse 2.0, заархивированный 13 октября 2006 г. в проекте Wayback Machine , который представляет собой реализацию спецификаций WSRF, WS-Notification и WSDM на основе Java .
- WSRF::Lite. Архивировано 12 ноября 2007 г. на Wayback Machine. Это реализация на основе Perl, которая эксклюзивно использует элемент Address ссылки на конечную точку, что делает WS-ресурсы идентифицируемыми через URI . Кроме того, WSRF::Lite обеспечивает сопоставление команд HTTP с операциями WSRF, что позволяет использовать WS-ресурсы в архитектурном стиле REST .
- WSRF.NET — это проект на основе .NET, посвященный спецификациям WSRF, разработанный исследовательской группой Университета Вирджинии.
- Последняя версия UNICORE 6.0 построена на Java-реализации стандарта WSRF 1.2, включая WS-ResourceLifetime и частичную реализацию WS-Notification.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ Малкольм Аткинсон; Дэвид ДеРур; Алистер Данлоп; Джеффри Фокс; Питер Хендерсон; Тони Эй; Норман Пэтон; Стивен Ньюхаус; Савас Парастатидис; Энн Трефетен; Пол Уотсон; Джим Уэббер (31 июля 2004 г.). «Сетки веб-сервисов: эволюционный подход» (PDF) . Серия технических отчетов по электронной науке Великобритании. Архивировано из оригинала (PDF) 11 октября 2006 г.