Web Services Resource Framework ( WSRF ) es una familia de especificaciones publicadas por OASIS para servicios web . Entre los principales colaboradores se 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 manejar interacciones con estado con recursos remotos. Esto no significa que los servicios web no pudieran tener estado. Cuando fuera necesario, un servicio web podía leer desde una base de datos o usar 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 la interacción con estado; los clientes de servicios web se comunican con los servicios de recursos que permiten almacenar y recuperar datos. Cuando los clientes se comunican con el servicio web, incluyen el identificador del recurso específico que se debe utilizar 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 un contenido XML complejo que ayude a identificar o incluso describir por completo el recurso específico en cuestión.
Junto con la noción de una referencia explícita a un recurso, se incluye un conjunto estandarizado de operaciones de servicios web para obtener o establecer propiedades de recursos. Estas operaciones se pueden utilizar para leer y quizás escribir el estado de un recurso, de una manera similar a tener variables miembro de un objeto junto con sus métodos. El principal beneficiario de este modelo son las herramientas de administración, que pueden enumerar y visualizar recursos, incluso si no tienen ningún otro conocimiento sobre ellos. Esta es la base de WSDM .
WSRF no está exento de controversias. La más fundamental es arquitectónica: ¿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 que 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 se ocupa de cuestiones como el aislamiento y la disponibilidad, y se remite a la naturaleza componible de las especificaciones de servicios web para ocuparse de ellas. Muchas pilas 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 normalmente no es en absoluto persistente (con la excepción de aquellos vinculados a una base de datos a través de algún mecanismo de persistencia). Sin embargo, existen implementaciones de WSRF que admiten la persistencia, la agrupación en clústeres y la alta disponibilidad de recursos (por ejemplo, en WebSphere Application Server ).
Con una visión 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 algunos sentidos, los dos modelos son más cercanos que SOAP puro y REST , porque ambos tienen recursos con estado en el extremo lejano. 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 administrar la vida útil del contenido remoto a través de alquiler renovable recibe críticas particulares. 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 los firewalls. Es por eso que los diseños REST prefieren el sondeo, como en los feeds RSS y Atom (estándar) . WSRF no ha hecho nada para que SOAP sea más aceptable para la comunidad REST.
La introducción de WSRF también causó divisiones en el mundo WS-*. Se anunció por primera vez al mundo en un evento del Global Grid Forum en febrero de 2004, como sucesor de Open Grid Services Infrastructure . Su compatibilidad limitada con la arquitectura WS-I principal creó disenso en la comunidad de redes del Reino Unido. [1] El Global Grid Forum finalmente aisló sus dependencias en WSRF en un perfil WSRF para su Open Grid Services Architecture . Los protocolos WSRF también fueron utilizados por WSDM como el 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 con Microsoft, Sun y otros eligiendo seguir con WS-Management , con su dependencia de WS-Transfer como el medio para describir los 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 básica de obtención/configuración de propiedades de los recursos WSRF es relativamente simple. El problema más difícil probablemente sea devolver fallas como fallas base WSRF cuando la especificación lo requiere, porque las propias pilas SOAP prefieren generar fallas SOAPFault. Administrar la duración de los recursos es más difícil, pero esto es opcional, al igual que WS-Notification, que es el más difícil de probar.