Web Services Resource Framework ( WSRF ) es una familia de especificaciones publicadas por OASIS para servicios web . Los principales contribuyentes incluyen Globus Alliance e IBM .
Un servicio web en sí mismo es nominalmente sin estado , es decir, no retiene datos entre invocaciones. Esto limita las cosas que se pueden hacer con los servicios web,
Antes de WSRF, ningún estándar en la familia de especificaciones de servicios web definía explícitamente cómo tratar las interacciones con estado con recursos remotos. Esto no significa que los servicios web no puedan tener estado. Cuando sea necesario, un servicio web podría leer desde una base de datos o utilizar el estado de la sesión mediante cookies o WS-Session.
WSRF proporciona un conjunto de operaciones que los servicios web pueden utilizar para implementar interacción con estado; Los clientes de servicios web se comunican con servicios de recursos que permiten almacenar y recuperar datos. Cuando los clientes hablan con el servicio web, incluyen el identificador del recurso específico que debe usarse dentro de la solicitud, encapsulado dentro de la referencia del punto final de WS-Addressing . Puede ser una dirección URI simple o puede ser contenido XML complejo que ayuda a identificar o incluso describir completamente el recurso específico en cuestión.
Junto con la noción de una referencia explícita a un recurso, viene un conjunto estandarizado de operaciones de servicios web para obtener/establecer propiedades de recursos. Estos se pueden usar para leer y quizás escribir el estado de los recursos, de una manera algo similar a tener variables miembro de un objeto junto con sus métodos. El principal beneficiario de este modelo son las herramientas de gestión, que pueden enumerar y ver los recursos, incluso si no tienen ningún otro conocimiento sobre ellos. Esta es la base de WSDM .
El WSRF no está exento de controversia. Lo más fundamental es arquitectónico: ¿son los objetos distribuidos con estado y operaciones la mejor manera de representar recursos remotos? Es casi una adaptación a XML del patrón de objetos distribuidos , del cual CORBA y DCOM son ejemplos. Un recurso WSRF puede ser una entidad con estado a la que varios clientes tienen referencias de recursos y la especificación WSRF en sí no aborda cuestiones como el aislamiento y la disponibilidad, remitiéndose a la naturaleza componible de las especificaciones de servicios web para abordarlas. Muchas pilas de WSRF parecen evitar estas preocupaciones al ser de baja disponibilidad, asignando 1:1 desde una referencia de recurso WSRF a una instancia de objeto local, que en C++ y Java generalmente no es persistente en absoluto (con la excepción de aquellas vinculadas a una base de datos). mediante algún mecanismo de persistencia). Sin embargo, existen implementaciones de WSRF que admiten persistencia, agrupación en clústeres y alta disponibilidad de recursos (por ejemplo, en WebSphere Application Server ).
Con una vista de objetos distribuidos de la red, WSRF también está en desacuerdo con el modelo REST de la red, en el que todo es un recurso, pero en el que todas las acciones se habilitan a través de un conjunto limitado y estandarizado de operaciones. En cierto modo, los dos modelos están más cerca que SOAP y REST puros , porque ambos tienen recursos con estado en el otro extremo. Sin embargo, REST, tal como se implementa en HTTP , supone que la URL es todo lo que se necesita para direccionar el recurso; no hay necesidad de la complejidad de los parámetros de referencia de WS-Addressing . La idea de gestionar la vida útil del contenido remoto mediante arrendamiento renovable es objeto de críticas especiales. El otro problema con la arquitectura de la comunidad REST es que las devoluciones de llamadas/notificaciones, como se describe en WS-Notification, no pasan por firewalls. Es por eso que los diseños REST prefieren el sondeo, como en los canales RSS y Atom (estándar) . WSRF no ha hecho nada para que SOAP sea más aceptable para la comunidad REST.
La introducción del WSRF también provocó divisiones en el mundo WS-*. Se anunció por primera vez al mundo en un evento del Foro Global Grid en febrero de 2004, como sucesor de la Infraestructura de Servicios Open Grid . Su compatibilidad limitada con la arquitectura convencional WS-I generó la disconformidad de la comunidad de redes del Reino Unido. [1] El Foro Global Grid finalmente aisló sus dependencias de WSRF en un perfil WSRF para su Arquitectura de Servicios Open Grid . WSDM también utilizó los protocolos WSRF como medio para interactuar con los recursos manejables descritos en WSDM. El mundo WS-*, sin embargo, no estaba unido en un estándar único para la gestión de servicios web, ya que Microsoft, Sun y otros optaron por implementar WS-Management , con su dependencia de WS-Transfer como medio para describir recursos manejables.
También es relevante WS-Notification, que indica cómo enviar información a otros servicios web sobre lo que está sucediendo.
Implementar la semántica de propiedad básica get/set de los recursos WSRF es relativamente simple. El problema más difícil probablemente sea devolver fallas como fallas base de WSRF cuando la especificación lo requiere, porque las pilas SOAP prefieren generar fallas SOAPFault. Administrar la vida útil de los recursos es más difícil, pero es opcional, al igual que WS-Notification, que es el más difícil de probar.