Web-сервисы: Фреймворк ресурсов WSRF и управление состоянием

Введение

Семейство спецификаций для веб-сервисов – это семейство спецификаций для веб-сервисов, опубликованных организацией OASIS. Основными участниками разработки являются Globus Alliance и IBM. Веб-сервис по своей сути является безсостоятельным, то есть не сохраняет данные между вызовами. Это ограничивает возможности использования веб-сервисов.

До появления WSRF ни один стандарт в семействе спецификаций веб-сервисов явно не определял, как обрабатывать состоятельные взаимодействия с удалёнными ресурсами. Это не означает, что веб-сервисы не могли быть состоятельными. При необходимости веб-сервис мог читать данные из базы данных или использовать состояние сессии посредством cookie-файлов или WS Session. WSRF предоставляет набор операций, которые веб-сервисы могут использовать для реализации состоятельного взаимодействия: клиенты веб-сервисов взаимодействуют с ресурсными службами, позволяющими хранить и извлекать данные. При обращении к веб-сервису клиенты включают в запрос идентификатор конкретного ресурса, который необходимо использовать, заключённый в ссылку на конечную точку адресации WS. Это может быть простой URI-адрес или сложный XML-контент, помогающий идентифицировать или даже полностью описать конкретный ресурс. Наряду с понятием явной ссылки на ресурс появляется стандартизированный набор операций веб-сервиса для получения и установки свойств ресурса. Их можно использовать для чтения и, возможно, записи состояния ресурса, что в некоторой степени напоминает переменные-члены объекта вместе с его методами. Основными выгодоприобретателями такой модели являются инструменты управления, которые могут перечислять и просматривать ресурсы, даже не имея о них других сведений. Это лежит в основе WSDM.

Вопросы с WSRF

WSRF не лишен противоречий. Наиболее фундаментальный вопрос – архитектурный: являются ли распределенные объекты с состоянием и операциями наилучшим способом представления удаленных ресурсов? Это, по сути, перенос паттерна распределенных объектов в XML, примерами которого служат CORBA и DCOM. Ресурс WSRF может представлять собой объект с состоянием, к которому несколько клиентов имеют ссылки, и сама спецификация WSRF не решает вопросы изоляции и доступности, полагаясь на компонуемость спецификаций веб-сервисов для их решения. Многие реализации WSRF, по-видимому, избегают этих проблем, обеспечивая низкую доступность и устанавливая однозначное соответствие между ссылкой на ресурс WSRF и локальным объектом, который в C++ и Java обычно не является постоянным (за исключением тех, что связаны с базой данных через механизм постоянного хранения). Однако существуют реализации WSRF, поддерживающие постоянство, кластеризацию и высокую доступность ресурсов (например, в WebSphere Application Server). Рассматривая сеть как совокупность распределенных объектов, WSRF вступает в противоречие с REST-моделью, в которой все является ресурсом, а все действия выполняются посредством ограниченного и стандартизированного набора операций. В некотором смысле, эти две модели ближе, чем чистые SOAP и REST, поскольку обе оперируют ресурсами с состоянием на удаленном конце. Однако REST, реализованный на HTTP, предполагает, что URL-адреса достаточно для идентификации ресурса – нет необходимости в сложности параметров адресации WS Addressing. Особенно критикуется идея управления жизненным циклом удаленного контента посредством возобновляемой аренды. Еще одна проблема архитектуры с точки зрения сообщества REST заключается в том, что обратные вызовы и уведомления, описанные в WS Notification, не проходят через брандмауэры. Поэтому в REST-проектах предпочтение отдается опросу, как, например, в стандартных RSS и Atom-лентах. WSRF не сделала SOAP более приемлемым для сообщества REST. Введение WSRF также вызвало разногласия в мире WS*. Он был впервые представлен миру на мероприятии Global Grid Forum в феврале 2004 года как преемник Open Grid Services Infrastructure. Его ограниченная совместимость с основной архитектурой WS I вызвала несогласие со стороны британского сообщества, занимающегося сетями. Global Grid Forum в конечном итоге изолировал свои зависимости от WSRF в профиле WSRF для своей архитектуры Open Grid Services. Протоколы WSRF также использовались WSDM для взаимодействия с управляемыми ресурсами, описанными в WSDM. Однако сообщество WS* не пришло к единому стандарту управления веб-сервисами, Microsoft, Sun и другие предпочли WS Management, который использует WS Transfer для описания управляемых ресурсов.

WSRF is not without controversy. Most fundamental is architectural: are distributed objects with state and operations the best way to represent remote resources? It is almost a port into XML of the distributed objects pattern, of which CORBA and DCOM are examples. A WSRF resource may be a stateful entity to which multiple clients have resource references and the WSRF specification itself does not deal with concerns such as isolation and availability, deferring to the composable nature of web service specifications to deal with these. Many WSRF stacks appear to avoid these concerns by being low availability, mapping 1:1 from a WSRF resource reference to a local object instance, which in C++ and Java is usually not at all persistent (with the exception of those bound to a database through some persistence mechanism). There are, however, implementations of WSRF that support persistence, clustering and high availability of resources (for example, in WebSphere Application Server). With a distributed objects view of the network, WSRF is also at loggerheads with the REST model of the network, in which everything is a resource, but in which all actions are enabled through a limited and standardized set of operations. In some ways, the two models are closer than pure SOAP and REST, because they both have stateful resources at the far end. However, REST, as implemented on HTTP, assumes that the URL is all that is needed to address the resource – there is no need for the complexity of the WS Addressing ReferenceParameters. The idea of managing the lifetime of remote content through renewable leasing comes in for particular criticism. The other issue with the architecture from the REST community is that callbacks/notifications, as described in WS Notification, do not go through firewalls. This is why REST designs prefer polling, such as in RSS and Atom (standard) feeds. WSRF has done nothing to make SOAP more acceptable to the REST community. The introduction of WSRF also caused splits in the WS * world. It was first announced to the World at a Global Grid Forum event in February 2004, as a successor to the Open Grid Services Infrastructure. Its limited compatibility with the mainstream WS I architecture created dissent from the UK grid community. The Global Grid Forum ultimately isolated their dependencies on WSRF in a WSRF profile for their Open Grid Services Architecture. WSRF protocols were also used by WSDM as the means to interacts with manageable resources described in WSDM. The WS * world, however, was not united on a single standard for Web services management with Microsoft, Sun and others choosing to pursue WS Management, with its dependency on WS Transfer as the means to describe manageable resources.

Спецификации компонентов

WS Resource определяет ресурс WS как комбинацию ресурса и веб-сервиса, посредством которого осуществляется доступ к этому ресурсу. WS ResourceProperties описывает интерфейс для связывания набора типизированных значений с ресурсом WS, которые могут быть прочитаны и изменены стандартным образом. WS ResourceLifetime описывает интерфейс для управления жизненным циклом ресурса WS. WS BaseFaults описывает расширяемый механизм для создания информативных SOAP-ошибок. WS ServiceGroup описывает интерфейс для операций с коллекциями ресурсов WS. Также важен WS Notification, определяющий способ отправки информации другим веб-сервисам о происходящих событиях.

Реализация

Реализация базовой семантики get/set свойств ресурсов WSRF относительно проста. Самая сложная задача, вероятно, заключается в возврате ошибок в виде базовых ошибок WSRF, когда это требуется спецификацией, поскольку сами SOAP-стеки предпочитают генерировать ошибки SOAPFault. Управление жизненным циклом ресурсов сложнее, но это необязательно, как и WS-уведомления, которые труднее всего тестировать. Globus Toolkit версии 4 содержит реализации WSRF на Java и C; многие другие инструменты Globus были переработаны с использованием WSRF. WebSphere Application Server версии 6.1 предоставляет среду WSRF, поддерживающую как простые, так и кластеризованные, высокодоступные конечные точки WSRF. Apache Foundation разрабатывает проект Muse 2.0 – реализацию спецификаций WSRF, WS-Notification и WSDM на основе Java. WSRF::Lite – это реализация на Perl, которая исключительно использует элемент Address ссылки на конечную точку, что позволяет идентифицировать ресурсы WS с помощью URI. Кроме того, WSRF::Lite обеспечивает сопоставление HTTP-методов операциям WSRF, что позволяет использовать ресурсы WS в архитектурном стиле REST. WSRF.NET – это проект на платформе .NET, посвященный спецификациям WSRF, разработанный исследовательской группой Университета Вирджинии. Последняя версия 6.0 UNICORE построена на Java-реализации стандарта WSRF 1.2, включая WS ResourceLifetime и частичную реализацию WS-Notification.