Desarrollo de un sistema que soporte la arquitectura de recursos (Capa Web del Motor)
De MorfeoWiki
Tabla de contenidos |
Introducción
Con el objetivo de facilitar la integración de Smartflow-Engine con las nuevas herramientas y tecnologías Web 2.0, se ha definido una arquitectura RESTful que permita el acceso a las funcionalidades del componente a partir del protocolo HTTP. Para esto se han definido una serie de Recursos que modelan la arquitectura y funcionalidad del componente, y que serán gestionados por un contendor de recursos llamado ResourceContainer, eje sobre el que se desarrollará toda interacción.
Surge de este modo la necesidad de conseguir un sistema que pueda ser gestionado por ResourceContainer y que se encargue del acceso, definición y desarrollo de estos recursos, resolviendo la comunicación con SmartFlow-Engine y actuando como un sistema proxy entre el SmartFlow-Engine y las interfaces/herramientas orientadas a Recursos que manejen los usuarios durante la interacción con los modelos de proceso.
Este componente surge a partir del ya desaparecido RestHTTPProxy que pertenecia al motor Smartflow-Engine. Forma parte de la plataforma SMARTFlow y se encuentra disponible en la forja de Morfeo bajo el nombre de SMARTFlow-RESTLayer.
Estado actual de SMARTFlow-RESTLayer
Actualmente se dispone ya de una versión estable del componente SMARTFlow-RESTLayer. Ha sido desarrollado a partir de RestHTTPProxy teniendo en cuenta las mejoras propuestas para dicho componente de cara a conseguir una herramienta flexible y escalable, en la cual se puede incorporar el tratamiento de nuevos recursos de manera sencilla y con un bajo impacto.
El funcionamiento del componente se basa en los siguientes conceptos:
- Existe una aplicación Web (a partir de ahora "manejador") por cada uno de los recursos existentes en el motor SMARTFlow-Engine encargada de recibir las peticiones HTTP y gestionar el recurso que encapsula.
- El contenedor de recursos recibe todas las peticiones y se encarga de analizar la URI y enviar la petición al correspondiente manejador que gestiona el recurso.
- Una vez recibida una petición por el manejador, éste la resuelve comunicándose si fuese necesario con el motor SMARTFlow-State a través de su interfaz CORBA, y exportando el recurso solicitado en formato XML.
Mejoras incorporadas en SMARTFlow-RESTLayer
El componente SMARTFlow-RESTLayer presenta una serie de mejoras con respecto a su antecesor RestHTTPProxy:
- El manejador de un recurso se encarga de recibir y tratar todas las peticiones HTTP (GET, POST, PUT y DELETE) que pueda recibir. Es decisión del desarrollador dar soporte o no a un tipo concreto de petición.
- La gestión y análisis de las URIs se lleva a cabo por otro sistema (el contenedor de recursos), liberando al manejador de dicha tarea aunque no se obliga a que sea así, de hecho en el manejador se puede volver a analizar la URI y a redirigir a otro manejador si fuera necesario, siendo el sistema mucho más flexible.
- Cada manejador se encarga de un sólo recuros (identificado como un nodo de la URI) aunque no se obliga a ello y es responsabilidad del desarrollador utilizar un único manejador para varios recursos.
- La incorporación de nuevos recursos se ha mejorado considerablemente, simplificando tanto el desarrollo como el despliegue del mismo en la plataforma. El proceso se lleva a cabo de la siguiente manera:
- Se desarrolla un manejador por cada recurso como una aplicación Web que se conecte con el motor vía su API CORBA y exporte el recurso deseado en formato XML. Si el lenguaje de programación elegido es Java el contenedor de recursos ofrece una serie de manejadores por defecto (DefaultPersistentHandler y DefaultHandler) que pueden utilizarse como base para el desarrollo del nuevo manejador.
- Los manejadores (como cualquier otra apliación Web) deben desplegarse en un contenedor web (TOMCAT, etc) y además registrarse en el contenedor de recursos (ResourceContainer).
Ventajas de SMARTFlow-RESTLayer
Tras la incorporación de las citadas mejoras, el funcionamiento de SMARTFlow-RESTLayer se ha mejorado considerablemente obteniendo ciertas ventajas:
- La arquitectura es modular, altamente escalable, y muy independiente. Incluir nuevos recursos implica pocos, o ningún cambio en los ya presentes. Además, dado que el tratamiento de todos los recursos es estándar, la arquitectura es homogénea.
- Los manejadores, al ser independientes unos de otros, podrán evolucionar en complejidad y prestaciones cuando sea necesario.
- El desarrollo de los manejadores es independiente de la tecnología utilizada, el único requisito es que el manejador sea una aplicación Web.
- La búsqueda del manejador correspondiente se lleva a cabo por otro sistema, liberando al componente de esta tarea. De esta forma se asegura además, que la petición llega al manejador correcto.
