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 por 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 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 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 . Esta puede ser una dirección URI simple o puede ser un contenido XML complejo que ayuda a identificar o incluso describir completamente el recurso específico en cuestión.
Junto a la noción de una referencia explícita de recursos, 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 dicho modelo son las herramientas de gestión, que pueden enumerar y ver recursos, incluso si no tienen otro conocimiento de ellos. Esta es la base de WSDM .
Problemas con WSRF
WSRF no está exento de controversias. Lo más fundamental es la arquitectura: ¿los objetos distribuidos con estado y operaciones son la mejor manera de representar recursos remotos? Es casi un puerto en 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í misma no se ocupa de cuestiones como el aislamiento y la disponibilidad, y se somete a la naturaleza componible de las especificaciones del servicio web para tratarlas. Muchas pilas de WSRF parecen evitar estas preocupaciones al ser de baja disponibilidad, mapeando 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 aquellos vinculados a una base de datos a través de algún mecanismo de persistencia). Sin embargo, existen implementaciones de WSRF que dan soporte a la persistencia, la agrupación en clústeres y la 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 de operaciones limitado y estandarizado. De alguna manera, los dos modelos están más cerca que SOAP y REST puros , porque ambos tienen recursos con estado en el extremo lejano. Sin embargo, REST, tal como se implementa en HTTP , asume 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 direccionamiento WS . La idea de gestionar la vida útil del contenido remoto a través del arrendamiento renovable es objeto de críticas especiales. El otro problema con la arquitectura de la comunidad REST es que las devoluciones de llamada / notificaciones, como se describe en WS-Notification , no atraviesan los firewalls. Esta es la razón por la que los diseños REST prefieren el sondeo, como en las fuentes 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 provocó 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 convencional generó disconformidad con la comunidad de redes del Reino Unido. [1] El Foro Global Grid finalmente aisló sus dependencias en WSRF en un perfil WSRF para su Arquitectura de Servicios Open Grid . Los protocolos WSRF también fueron utilizados por WSDM como medio para interactuar con los recursos manejables descritos en WSDM. El mundo WS- *, sin embargo, no estaba unido en un solo estándar para la administración de servicios web con Microsoft, Sun y otros eligiendo seguir WS-Management , con su dependencia de WS-Transfer como el medio para describir los recursos manejables.
Especificaciones de los componentes
- WS-Resource define un WS-Resource como la composición de un recurso y un servicio web a través del cual se puede acceder al recurso.
- WS-ResourceProperties describe una interfaz para asociar un conjunto de valores escritos con un WS-Resource que se puede leer y manipular de forma estándar.
- WS-ResourceLifetime describe una interfaz para gestionar la vida útil de un WS-Resource.
- WS-BaseFaults describe un mecanismo extensible para SOAPFaults enriquecidos .
- WS-ServiceGroup describe una interfaz para operar en colecciones de WS-Resources.
También es relevante WS-Notification, que dice cómo enviar información a otros servicios web sobre lo que está sucediendo.
Implementaciones
La implementación de la semántica get / set de la propiedad básica de los recursos WSRF es relativamente simple. El problema más difícil es probablemente devolver fallas como WSRF Base Faults donde la especificación lo requiere, porque las propias pilas SOAP prefieren generar fallas SOAPFault . Administrar la vida útil 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.
- La versión 4 de Globus Toolkit contiene implementaciones Java y C de WSRF; muchas otras herramientas Globus se han reconstruido en torno a WSRF.
- WebSphere Application Server versión 6.1 proporciona un entorno WSRF que da soporte a puntos finales WSRF simples y agrupados, de alta disponibilidad.
- La Fundación Apache tiene un proyecto Muse 2.0 que es una implementación basada en Java de las especificaciones WSRF, WS-Notification y WSDM .
- WSRF :: Lite es una implementación basada en perl que hace uso exclusivo del elemento Dirección de la referencia del punto final, lo que hace que WS-Resources sea identificable a través de URI . Además, WSRF :: Lite proporciona un mapeo de verbos HTTP a operaciones WSRF, lo que hace posible utilizar WS-Resources en un estilo arquitectónico REST .
- WSRF.NET es un proyecto basado en .NET sobre las especificaciones de WSRF de un equipo de investigación de la Universidad de Virginia.
- La última versión 6.0 de UNICORE se basa en una implementación Java del estándar WSRF 1.2 que incluye WS-ResourceLifetime y una implementación parcial de WS-Notification.
Ver también
Referencias
- ^ Malcolm Atkinson, David DeRoure, Alistair Dunlop, Geoffrey Fox, Peter Henderson, Tony Hey, Norman Paton, Steven Newhouse, Savas Parastatidis, Anne Trefethen, Paul Watson y Jim Webber (31 de julio de 2004). "Redes de servicios web: un enfoque evolutivo" ( PDF ) . Serie de informes técnicos sobre ciencia electrónica del Reino Unido. Cite journal requiere
|journal=
( ayuda )Mantenimiento de CS1: utiliza el parámetro de autores ( enlace )