D 3.2 Documento de definición de modelos avanzados de comunicación y composición de recursos
De MorfeoWiki
PROFIT
Morfeo-EzWeb
Área Temática: 350405 Strategic Action on Open Source Software
FIT-340503-2007-02 EzWeb
Entregable:
D 3.2 Documento de definición de modelos avanzados de comunicación y composición de recursos
| Versión: | 1.0 |
| Fecha de preparación: | 19/11/07 |
| Editores: | Yaco |
| Revisores: | ITI, UPM |
Planteamiento
- En la plataforma EzWeb, los usuarios pueden acceder a un universo de Recursos (contenido, servicios, gadgets). Pueden también componer e interconectar sus propios entornos operativos y procesos de forma simple y flexible. Los recursos de Servicio permiten acceder y transformar recursos de Contenido.
- Se necesita investigar la definición e implementación de la tecnología que permita combinar estos recursos.
- Se dirigirá la investigación en tecnologías de interacción e interoperabilidad para permitir una integración perfecta entre recursos pertenecientes a distintos proveedores.
- La compatibilidad y posibilidades de interconexión entre recursos será descubierta gracias a un procesamiento automatizado que empleará mecanismos de creación de planes y consecución de metas, como el modelo pre-post.
- Las soluciones para la composición de recursos y la comunicación deben ser lo suficientemente flexibles para manejar recursos y servicios (SOAP) legacy presentes en el del back-end.
Revisión: Creo que este apartado de planteamiento aqui sobra. Quizá habría que incluir una introducción basada en estos puntos. Mi propuesta:
La plataforma EzWeb pretende ofrecer a los usuarios un universo de recursos (entendiendo como recursos contenidos, servicios y gadgets). Dichos recursos podrán ser compuestos por los usuarios desde sus propios entornos operativos, de una forma simple y flexible. La clave es proporcionar al usuario las herramientas adecuadas para componer (y comunicar) dichos recursos.
Hay que considerar que la composición y comunicación ha de ser lo suficientemente flexible para manejar recursos y servicios (como SOAP) legacy presentes en el back-end.
Las soluciones propuestas han de considerar la noción de interconexión automática de recursos mediante procesamiento automatizado que emplee mecanismos de creación de planes y consecución de metas (como el modelo pre-post).
El presente documento pretende analizar las distintas posibilidades en lo que se refiere a comunicación y composición avanzada de recursos, estudiando el estado del arte en dicho campo, y proponiendo las posibles soluciones que más se adapten al proyecto EzWeb y a los requisitos detectados. De entre estas soluciones, se analizarán las tecnologías más adecuadas para implementar los modelos de comunicación y composición propuestos propuestos. — Javier Lopez
D 3.2.1 Modelos avanzados de composición de recursos
Arquitectura orientada a servicios (SOA)
Objetivos y elementos de SOA
Una arquitectura SOA se basa en la creación de un conjunto flexible de servicios, de diferente granularidad, entre los procesos de negocio y las aplicaciones, con un objetivo:
- Modelar la lógica de negocio como servicios para poder expresar la capa de negocio mediante la facilidad que ofrece la orquestación de los mismos.
- Crear una capa de servicios que ofrezca la funcionalidad de la capa de aplicación olvidándonos de la tecnología que la soporta.
- Minimizar las dependencias entre la capa de negocio y la de aplicación para desacoplar el negocio de la tecnología, y de este modo permitir los cambios en cualquiera de ellas. El objetivo sería favorecer la Agilidad para el Negocio.
- Reutilizar los servicios de negocio creados en la organización, por medio de su publicación en el Bus de Servicios Corporativos (ESB-Enterprise Service Bus).
FIXME: Poner una referencia para explicar ESB
Objetivos de SOA
Una arquitectura SOA se basa en la creación de un conjunto flexible de servicios entre los procesos de negocio y las aplicaciones con un objetivo:
- Modelar la lógica de negocio como servicios para poder expresar la capa de negocio mediante la facilidad que ofrece la orquestación de los mismos.
- Crear una capa de servicios que ofrezca la funcionalidad de la capa de aplicación olvidándonos de la tecnología que la soporta.
- Minimizar las dependencias entre la capa de negocio y la de aplicación para desacoplar el negocio de la tecnología. De este modo se permiten los cambios en cualquiera de ellas. El objetivo sería favorecer la Agilidad para el Negocio.
- Reutilizar los servicios de negocio creados en la organización, por medio de su publicación en el Bus de Servicios Corporativos (ESB-Enterprise Service Bus).
Elementos de SOA
Existen diferentes elementos SOA agrupados en dos bloques, uno que abarca los aspectos funcionales de la arquitectura y otro que abarca aspectos de calidad de servicio.
Aspectos funcionales de la arquitectura
- Transporte: es el mecanismo utilizado para llevar las demandas de servicio de un consumidor a un proveedor de servicio y devolver las respuestas.
- Protocolo de comunicación de servicios: es el mecanismo por el que proveedor y consumidor comunican cuando se solicita o responde, respectivamente
- Descripción de servicio: es un esquema acordado para describir el servicio, cómo debe invocarse, y qué datos requiere para invocarse correctamente.
- Servicios: describe un servicio actual que está disponible para utilizar.
- Procesos de Negocio: es una colección de servicios para satisfacer un requerimiento de negocio. Son invocados en una secuencia particular con un conjunto particular de reglas
- Registro de Servicios: es un repositorio de descripciones de servicios y datos que pueden utilizar proveedores de servicios para publicar sus servicios, así como consumidores de servicios para descubrir o hallar servicios disponibles.
Aspectos de la calidad de Servicio
- Política: es un conjunto de reglas bajo las que un proveedor pone un servicio a disposición de los consumidores.
- Seguridad: es un conjunto de reglas aplicables a la identificación, autorización y control de acceso de consumidores .
- Transacciones: es el conjunto de atributos aplicables a un grupo de servicios para que el resultado entregado sea consistente.
- Administración: es el conjunto de atributos aplicables para manejar los servicios proporcionados o consumidos
Orquestación. Definición y descripción de BPEL
Orquestación
Es un control total de los servicios por una única entidad. Este proceso define las interacciones entre los servicios componentes y la lógica que deben seguir estas interacciones. La entidad que está orquestando el proceso es la única que conoce el flujo de control y la información que sigue el proceso. Se puede decir que es privado y ejecutable. De esta manera se crea un proceso que utiliza diferentes servicios manipulando la información que fluye entre ellos. Cada entidad que participa implementa y controla su propio proceso.
Definición y descripción de BPEL
Business Process Execution Language (BPEL o Lenguaje para la Ejecución de Procesos de Negocio) es un lenguaje basado en XML y diseñado para permitir la compartimentación de tareas mediante computación distribudia. Puede trabajar a través de múltiples organizaciones usando una combinación de servicios web. Trabaja con XML serializado y permite programación a lo largo (ejecución de largos programas con procesos asíncronos que pueden verse típicamente en procesos de negocio). Desarrollada por personal de BEA, IBM y Microsoft, combina y reemplaza las especificaciones WSFL (lenguaje de flujo de Servicios Web) de IBM y XLANG de Microsoft.
Coreografía (Coordinación). Definición y descripción de WS-CDL
Coreografía
Define las colaboraciones entre cualquier tipo de aplicaciones componentes, independientemente del lenguaje o plataforma en el que están implementadas. Un proceso de coreografía no es controlado por uno solo de los participantes. A diferencia de la orquestación, la coreografía puede verse como un proceso público y no ejecutable. Púlico porque define un comportamiento conocido por todas las entidades participantes, y no ejecutable por ser un protocolo de negocio que dicta las reglas sobre las que interactuan las entidades.
Definición y descripción de WS-CDL
El lenguaje WS-CDL o Web Services Choreography Description Language es un lenguaje basado en XML que describe colaboraciones punto a punto entre participantes, definiendo su comportamiento común y complementario y en donde los mensajes intercambiados en un determinado orden desembocan en la consecución de un objetivo de negocio común.
Arquitectura orientada a recursos (REST)
Origen y objetivos de Rest
La Transferencia de Estado Representacional (Representational State Transfer o REST) es una técnica de arquitectura software para sistemas distribuidos como la World Wide Web. La motivación de desarrollar REST era crear un modelo de arquitectura que describiese como debería funcionar la Web, así como que pudiese servir como marco de trabajo para los estándares de protocolos Web. REST se aplica para describir la arquitectura Web deseada, ayudar a identificar problemas existentes, comparar soluciones alternativas y asegurar que el protocolo no viole las restricciones que hacen que la Web funcione correctamente. Fue desarrollado por el World Wide Web Consortium (W3C) y el Internet Engineering Taskforce (IETF), para definir un estándar de arquitectura para la Web: HTTP, URI y HTML.
El término fue acuñado por Roy Thomas Fielding en el año 2000. Fielding, actualmente investigador jefe en Day Software, Irving (California), ha estado muy involucrado en el desarrollo de las especificaciones HTTP, HTML y URI. Fue cofundador del proyecto Apache HTTP y es miembro de la comunidad OpenSolaris.
El término REST ha ido evolucionando con el tiempo. Cuando Fielding lo concibió se refería a un conjunto de principios de arquitectura. Actualmente se usa en un sentido más amplio, describiendo cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de otros protocolos como SOAP. Se pueden crear servicios web basados en REST sin usar SOAP, así como interfaces XMLHTTP.
Se definen una serie de restricciones que se deben cumplir para que una arquitectura de servicios pueda ser considerada REST:
- Cliente Servidor
- Sin estado
- Caché
- Sistema de capas
- Interfaz Uniforme
- Código bajo demanda
Cliente Servidor
La primera restricción mencionada que tiene REST está relacionada con el estilo Cliente-Servidor tradicional de la Web. Hay que distinguir lo que concierne al interfaz del usuario del almacenamiento de datos. De esta manera se mejora la portabilidad de la interfaz de usuario. También se mejora la escalabilidad porque se simplifican las componentes del servidor al no tener que implementar las funcionalidades que van asociadas a la interfaz del usuario. Otro factor importante es la separación, que permite a los componentes desarrollarse independientemente.
Sin estado
Cada petición del cliente debe contener toda la información necesaria para que el servidor la comprenda y no necesite mirar ningún dato almacenado previamente sobre el contexto de la comunicación. El estado de la sesión por lo tanto se guarda íntegramente en el cliente.
Esta restricción mejora la visibilidad, eficiencia y escalabilidad. La visibilidad mejora porque el servidor no tiene que ocuparse de mirar en otros sitios ni realizar más operaciones para comprender la naturaleza de una simple petición. La eficiencia mejora porque es más fácil recuperarse de errores parciales
La ventaja es que la eficiencia aumenta porque se hace más fácil recuperarse de errores parciales. La escalabilidad se ve también afectada porque al no hacer falta almacenar los estados entre las peticiones, los componentes pueden liberar recursos más rápidamente. Existe una simplificación de la implementación de aplicaciones al no existir gestión de recursos entre las peticiones.
La desventaja de esta restricción es que puede empeorar el funcionamiento de la red porque incrementa el tráfico de datos repetidos al enviar una serie de peticiones. Esto ocurre porque los datos no pueden quedarse almacenados en el servidor identificando un contexto determinado de comunicación. Además poniendo el estado de la aplicación en el lado del cliente, se reduce el control para obtener un comportamiento consistente en la aplicación. La aplicación se hace muy dependiente de una correcta implementación de la semántica en las distintas versiones del cliente.
Caché
Las respuestas a una petición deben poder ser etiquetadas como cacheable o no-cacheable. Si una respuesta es cacheable, entonces al cliente cache se le da permiso para reutilizar la respuesta más tarde si se hace una petición equivalente.
La ventaja de añadir esta restricción es que se evitarán determinadas peticiones al servidor, mejorando así la eficiencia y escalabilidad. Se va a reducir el tiempo medio de espera de una serie de interacciones.
La desventaja de esta restricción es que puede inducir a un mal funcionamiento de una aplicación si los datos obtenidos del caché difieren de los que se hubiesen obtenido realizando la petición directamente al servidor.
Sistema de capas
Para poder mejorar el comportamiento de la escalabilidad en Internet, se añade la restricción del sistema de capas. Este sistema permite tener una arquitectura compuesta por capas jerárquicas, limitando el comportamiento de los componentes porque no pueden “ver” mas allá de la capa con la que está interactuando.
Usando el sistema de capas se pueden simplificar los componentes moviendo las funcionalidades de uso infrecuente hacia sistemas intermedios compartidos. Estos sistemas pueden usarse para mejorar la escalabilidad permitiendo un balanceo de la carga de los servicios a través de múltiples redes y procesadores.
La principal desventaja de los sistemas de capas es que añaden cabeceras y retrasos al procesamiento de datos. Para un sistema de red que soporta la restricción de caché, este efecto puede verse reducido por los beneficios de usar un caché compartido en los sistemas intermedios.
Colocando caches compartidos en los límites de un dominio organizativo, puede conseguirse una mejora significativa. Las capas además permiten directivas de seguridad para los datos que cruzan los límites organizativos, algo que necesitan los firewalls.
Interfaz Uniforme
Las siguientes restricciones que se van a comentar a partir de ahora son realmente las novedades que pretende aportar REST a las nuevas arquitecturas Web.
La principal característica que distingue a REST del resto de estilos de arquitecturas de red es el énfasis de usar una interfaz uniforme entre los componentes. Aplicando los principios de generalidad de la ingeniera del software a los componentes de la interfaz, se simplifica la arquitectura del sistema global y la visibilidad de interacciones se mejora. Las implementaciones se separan de los servicios que proporcionan, lo que anima al desarrollo independiente.
La desventaja de usar una interfaz uniforme es que degrada la eficiencia porque la información transferida está en una forma estandarizada y no según las necesidades que tenga la aplicación. El interfaz de REST está diseñado para ser eficiente con transferencias de datos de hipermedios (suelen ser datos voluminosos). Con esta decisión, está optimizado para la mayor parte de la Web pero no siendo así para otras formas de arquitectura de interacción. Para obtener una interfaz uniforme, REST define cuatro restricciones de interfaz:
- Identificación de recursos.
- Manipulación de recursos a través de sus representaciones.
- Mensajes auto-descriptivos.
- Hipermedios como el motor del estado de la aplicación.
Código bajo demanda
La última restricción es opcional, consiste en permitir a los clientes tener la funcionalidad de descargar y ejecutar código en forma de applets y scripts. Esto simplifica el lado del cliente porque reduce el número de funcionalidades que tiene que tener implementadas al crearse. Las funcionalidades se pueden descargar posteriormente aumentando así la extensibilidad del sistema.
La principal desventaja de esta restricción es que reduce la visibilidad y puede influir en la seguridad del sistema. Sin embargo, tiene un propósito en el diseño arquitectónico de un sistema que abarque límites de organización múltiples. Con esta restricción, la arquitectura gana solamente una ventaja y sufre el resto de desventajas, por ello al ser una restricción opcional, en los contextos en los que el código bajo demanda no sea útil ni necesario, lo mejor será no incluirlo porque puede acarrear más problemas que beneficios.
Arquitectura Rest (Datos, conectores y componentes)
Datos en REST
El estado de los datos es un aspecto clave para REST.
Cuando se selecciona un link, la información debe trasladarse desde la localización donde se encuentra hasta donde será usado. A diferencia de los procesos distribuidos donde se mueve el “proceso agente” hasta los datos, en REST se mueven los datos hasta el proceso.
Los componentes de REST se comunican trasfiriendo representaciones de un recurso en un formato que se ajusta a un conjunto de tipos de datos estándares. Estos tipos serán seleccionados dinámicamente basándose en las capacidades o deseos del receptor y en la naturaleza del recurso.
REST gana en la separación de las funcionalidades del estilo cliente-servidor, pero permitiendo ocultar la información a través de un interfaz genérico que permite encapsular, evolucionar los servicios y proporciona un juego de funcionalidades amplio que podrá ser descargado.
Conectores
REST usa varios tipos de conectores para encapsular el acceso a los recursos y transferir las representaciones de los recursos. Los conectores principales de REST son Cliente, Servidor y Caché. Tambien existen otros conectores que quedan en segundo plano, que son Resolver y Túnel.
Componentes
Los componentes principales de REST son Agente Usuario, Servidor, Gateway (puerta de acceso) y Proxy.
Un Agente Usuario usa un conector cliente para iniciar una petición y recibir la respuesta.
El Servidor gobierna el espacio de nombres cuando se le solicita un recurso.
Los componentes de un Gateway forman un sistema intermedio impuesto por la red o el servidor que proporciona una encapsulación del interfaz de otros servicios, transmisión de datos, perfeccionamiento del funcionamiento o seguridad.
Un componente Proxy es un sistema intermedio seleccionado por el cliente que proporciona la encapsulación de la interfaz de otros servicios, transporte de datos, perfeccionamiento del funcionamiento o seguridad.
Análisis de la solución para EzWeb
En la arquitectura y desarrollo de software se considera mas apropiado usar un diseño basado en REST cuando:
- Sea necesario tener representación distinta a XML.
- Los servicios web no tienen estados.
- El servicio productor y el servicio consumidor tienen un entendimiento mutuo cuando se pasa tanto contenido como contexto. debido a que no hay una manera formal de describir las interfaces de servicios web, ambas partes deben ponerse de acuerdo en cuanto a los esquemas que describen la manera en que se intercambian los datos, así como la manera de procesarlos de modo que sean comprensibles. En el mundo real, la mayoría de las aplicaciones comerciales que utilizan implementaciones RESTful también distribuyen herramientas que describen interfaces para los desarrolladores implementadas en lenguajes de programación populares.
- REST es particularmente util para dispositivos con perfil limitado como PDAs o telefonos mobiles, para los que las extensas cabeceras y capas adicionales de elementos SOAP son excesivas.
- Los serviciones pueden ser expuestos con XML y consumidos mediante HTML sin realizar una refactorización significativa sobre la arquitectura del sitio web existente.
D 3.2.2 Modelos avanzados de comunicación de recursos
Estilo de flujo de datos
Este tipo de estilo es ideal para realizar transformaciones de datos dividiéndolos en pasos sucesivos. En este tipo de arquitectura nos encontramos con dos tipos de componentes. El primer tipo de componente son los elementos que realizan las transformaciones de los datos cuando pasan por ellos, los datos pasan de forma secuencial de uno a otro componente, realizando el procesamiento de los datos de forma secuencial. Estos elementos son independientes unos de otros. Todos tienen una o varias puertas de entrada-salida que sirven para mandar los datos modificados de un módulo a otro. El otro tipo de elemento es el que se encarga de enviar el flujo de los datos desde la salida de un módulo transformador a la entrada de otro, es decir, realiza el rol de comunicador. En este estilo arquitectónico se va a estudiar el patrón tubería/filtro (piping/filtering)
Tubería/filtro (Piping/filtering)
Conceptos previos
Tubería (Pipe): Solamente es una forma de conectar la salida estándar de un programa con la entrada estándar de otro programa automáticamente. Es un concepto muy importante,ya que permite que varios programas puedan encadenarse y hacer que los resultados de un comando puedan tratarse como datos a procesar del siguiente.
Filtro: Es un programa que recibe unos datos por la entrada y devuelve, tras ejecutar una condición, parte de ellos por su salida. Por parte de ellos se entiende tanto su totalidad, tanto nada, como tanto una porción de ellos.
Definición de la arquitectura
Esta arquitectura es muy simple pero a su vez es muy potente y robusta. Consiste en una serie de componentes, filtros, que están conectados a través de tuberías. Normalmente la estructura es una secuencia Filtro/Tubería/Filtro/Tubería/etc pero puede presentarse en estructuras más complejas.
El filtro (o filtros) transforman los datos que les llegan a través de las tuberías. Cabe aclarar, que un filtro puede tener cualquier número de tuberías de entrada y salida.
Una tubería conecta dos filtros pasandoles los datos. Esta es un flujo unidireccional, que suele ser implementado con un buffer.
Además de los dos componentes comentados, existirá un programa productor, el cual es el que ha creado los datos, este puede ser un proceso que lea de teclado, que lea de un archivo, que consulte a una BD, etc.
Y el otro será un proceso que consuma dichos datos, la salida estándar ( el monitor), un archivo, una BD, cualquier dispositivo externo, etc. Además estos datos no solo pueden ser volcados sino también pueden ser tratados.
Funcionamiento
Antes de explicar su funcionamiento, se debe detallar cuando es conveniente utilizarla. La popularidad de la arquitectura se debe principalmente al sistema operativo tipo Unix. Y debe de utilizarse siempre y cuando haya una gran cantidad de transformaciones a realizar, es decir un gran número de filtros.
El funcionamiento es el siguiente: todos los filtros son procesos que corren al mismo tiempo, es decir forman diferentes hilos. Cada tubería que llega al filtro tiene un papel diferente, así que en la tubería debe estar expresado este concepto.
Los filtros deberán de leer los datos de entrada, aplicarle la condición y devolverlos por la salida. Sino hay datos en la entrada, el filtro no hace nada, espera.
Esta estructura puede llegar a ser todavía mas compleja y llegar a ser incluso recursiva.
Ventajas e Inconvenientes
La ventajas más destacables son las siguientes:
- Conseguimos ir separando conceptos, lo que nos permite ir entendiendo el sistema poco a poco, lo que sin duda mucho más sencillo.
- La reutilización es muy alta en estos sistemas. Ya que el sistema está dividido.
- De igual manera, el mantenimiento es verdaderamente sencillo. Ya que encontrar los errores es una tarea muy ligera.
- Soporta ejecución concurrente.
Los inconvenientes principales son:
- El tiempo de espera. Si un filtro tiene tres tuberías de entradas, tiene que esperar hasta que las tres tuberías no le aporten los datos para poder ejecutarse totalmente.
- Es normal que las tuberías solo suelen aceptar un tipo de datos, lo que las restringe enormemente.
Estilo centrado en datos
El estilo centrado en datos resulta apropiado para sistemas que se centran en el acceso y actualización de datos en estructuras de almacenamiento que son compartidos por un número indefinido de componentes consumidores. Una de las propiedades más destacable de este estilo arquitectónico es la necesidad de crear persistencia de los datos almacenados. Existen dos tipos de componentes, un componente que realiza el almacenaje y persistencia de los datos y otros componentes que interactúan con dichos datos. En estos sistemas hay que tener encuenta que se pueden producir problemas en la interacción de los componentes que manejan los datos con el componente que almacena los datos (creación, lectura y actualización simultáneas a un mismo dato) y la coherencia (hay que evitar que un componente pueda tener un dato con un valor desactualizado). Pueden existir módulos de almacenamiento activos o pasivos según quien se encargue de la notificación de la actualización de los datos (si el componente encargado del almacenamiento es el notificador, entonces este es un modelo activo). Patrones característicos de este estilo son la pizarra y el repositorio.
Arquitectura de Pizarra ( Estilo Repositorio)
Definición
En la arquitectura de pizarra, podemos encontrar dos componentes principales. Una estructura de datos que representa el estado actual, y un número independiente de componentes, los cuales realizan sus operaciones sobre él. Esta arquitectura se puede subdividir en dos:
- Si las transacciones en su flujo de entrada, definen los procesos que van a ejecutarse, entonces el repositorio puede ser algo como una BD tradicional.
- Sin embargo, si el estado de dicha estructura es la que va a disparar los procesos que se ejecuten, el repositorio se llamará pizarra pura.
Esta arquitectura, se ha usado y se usa (no son solamente una curiosidad histórica), en aplicaciones que necesitan interpretación de proceso de señales bastante complejo. También es usado en implementaciones de estilos de procesos en lotes de BD. Y por último en programación organizada como colecciones de servicios al rededor de un repositorio común.
¿ De donde vienen y a donde van ?
En general, se tiende a pensar que no hay sistemas organizados como repositorios, con la arquitectura de pizarra. Pero en realidad hay muchos más sistemas de lo que se cree. Esta arquitectura es muy conocida en sistemas de Inteligencia artificial (I.A.), como hemos dicho no es una curiosidad histórica, y todavía se usa en gran medida en IA distribuida y cooperativa, robótica, multi-agentes, programación evolutiva, grmáticas complejas, etc
Algunos compiladores están arquitecturados con el estilo tubería-filtro, pero se podrían representar mejor como estilo de pizarra. Ya que un gran número de compiladores contemporáneos operan con inforación compartida: tablas de símbolos, arboles abstractos sintácticos,etc.
Del mismo modo que acabamos de decir que los estilos de tubería-filtro evolucionan hacia pizarras. Los estilos de pizarra suelen evolucionar hacia el de máquinas virtuales.
Ventajas e Inconvenientes
Las principales ventajas son las siguientes:
- Hace posible la interacción de agentes contra el sistema.
- Funciona muy bien con los problemas no determinista (especial para I.A.)
- Sabemos el conocimiento que llevamos en cada momento del proceso.
Pero hay que resaltar los inconvenientes que se encuentan:
- Problemas de seguridad ya que la pizarra es accesible por todos.
- Problemas de sincronización al chequear/vigilar la pizarra.
Estilo de Llamada y retorno
Este estilo es interesante en los sistemas que se centran en la interacción de un usuario con el propio sistema. Podemos dividir la arquitectura en dos partes, la primera representa la interfaz del usuario con el que este realiza la llamada al sistema, la segunda contiene la lógica de negocio que se realiza tras la correspondiente llamada del usuario. Esta familia de estilos enfatiza la modificabilidad, la escalabilidad, la reusabilidad y la usabilidad del sistema. Al diseñar una arquitectura de este tipo es importante saber que datos son los que servirán para interactuar con el usuario y cuales servirán solo como lógica de aplicación. En esta familia de arquitecturas se destacan los patrones modelo-vista-controlador y arquitectura en tres capas.
Arquitectura en tres capas
Cuando se desarrolla una aplicación cliente, la tendencia habitual es mezclar lógica con presentación. Es normal (sino tenemos una técnica programando) que en los formularios implementemos el acceso a la lógica de negocio de nuestra aplicación y la navegación a nuevos formularios. Pero esto trae consigo algunos inconvenientes que veremos en el epígrafe de inconvenientes. Para solucionarlos se utiliza la arquitectura en tres capas.
Definición de Capas
- Capa de presentación: esta es la que el usuario puede ver en su ordenador, es donde se tratan los datos que se van a mostrar. Se intenta que en esta capa haya el mínimo de procesamiento. Esta capa se comunicará solamente con la capa de negocio.
- Capa de negocios: en esta capa esta la lógica, se recibe las peticiones del usuario, y tras ejecutar una acción se le envía las respuestas del proceso. Esta capa se cominuca como se ha dicho con la de presentación, la cual le envia peticiones y esta le responde con los resultados. Y también se comunica con la capa de datos, para pedirle datos.
- Capa de datos: es donde se accede a los datos. Se hace referencia a uno o mas gestores de BD que realizan el almacenamiento, modificación y consulta de los datos. Recibe peticines desde la capa de negocios.
Es destacable hablar del concepto de nivel. Estas capas pueden estar en uno o varios ordenadores. Si todas se encuentran en el mismo ordenador, se dice que es arquitectura en tres capas y un nivel. Si por el contrario se encuentran en dos, se dice que es arquitectura en tres capas y dos niveles. Y si se encuentran en tres, pues tres capas y tres niveles.
Ventajas e Inconvenientes del Modelo en tres capas
En primer lugar decir, que en este caso son muchas más las ventajas que los inconvenientes, pero como en anteriores patrones comentaremos los puntos a favor como en contra, pero habiendo resaltado antes que son más los beneficios que los perjuicios. Las ventajas son las siguientes:
- Facilita que se pueda descomponer la aplicación en varios niveles de abstracción.
- Facilita la evolución del sistema, ya que los cambios solo deben de afectar a la capa donde se encuentre la modificación.
- Si la interfaz accede a la misma función (p.ej. varios lugares para identificarse), no se repetirá código. Lo que conlleva la ventaja de una mayor facilidad de mantenimiento de la aplicación, entre otros.
- Si se añade un nuevo formulario no ocasionará verdaderos quebraderos de cabeza, ya que los formularios ya no dependen unos de otros, con lo que el cambiar el workflow es algo trivial.
- Los formulario ya no accede de forma independiente a los datos, ya que no se accede a través de ellos, al modificar los datos. Esto implica que no se nos mostrará diferencia alguna.
Y como inconvenientes se encuentran:
- No todo sistema podrá ser estructura en capas.
- Y aún pudiendo ser estructurado en capas, la separación entre una y otra no es trivial. Ya no solo por que para un desarrollador no lo es, sino también por que muchos lenguajes y/o frameworks no están preparados para ello.
Frameworks que implementan la arquitectura en tres capas
| Lenguaje | Licencia | Nombre |
| Ruby | MIT | Ruby on Rails |
| Java / J2ee | Apache | JSP Struts |
| Java / J2ee | Apache | Spring Framework |
| Java / J2ee | Apache | Tapestry |
| Java / J2ee | Apache | Aurora |
| Java / J2ee | Apache | JavaServerFaces |
| Perl | GPL | Catalyst |
| PHP | BSD | Zend Framework |
| PHP | MIT | CakePHP |
| PHP | GNU/GPL | Kumbia |
| PHP | MIT | Symfony |
| PHP | MIT | QCodo |
| PHP | GNU/GPL | CodeIgniter |
| Python | ZPL | Zope3 |
| Python | Varias | Turbogears |
| Python | BSD | Django |
| .NET | Castle Project | MonoRail |
| .NET | Apache | Spring .NET |
| .NET | Apache | Maverick .NET |
| .NET | Microsoft Patterns & Practices | User Interface Process (UIP) Application Block |
Sacado de wikipedia
Arquitectura Modelo-Vista-Controlador
La arquitectura Modelo-Vista-Controlador, es la implementación de la arquitectura en tres capas más extendida. Todo lo que se diga en este epígrafe es extensible a la arquitectura en tres capas, con algunas pequeñas diferencias.
Definición del Patrón
- Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es independiente de cualquier representación de salida y/o comportamiento de entrada. El modelo debe de preservar la inegridad de los datos.
- Vista (View): Muestra la información al usuario. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador. Interactúa con la interfaz de usuario.
- Controlador (Controller): Reciben las entradas, usualmente como eventos, e interpreta las operaciones del usuario; codificando los movimientos, pulsación de botones del ratón, pulsaciones de teclas, etc. Los eventos son traducidos a solicitudes de servicio ("service requests") para el modelo o la vista. Es el que debe de controlar los eventos.
Responsabilidades de cada parte
Después de definir los conceptos de Modelo, Vista y Controlador, se definirán las responsabilidades de cada uno de ellos.
- El modelo deberá:
- Acceder a los datos persistentes, a la capa de almacenamiento de datos. Algo ideal es que este sea independiente de la Base de datos utilizada.
- Llevar las estadísticas de sistema (en caso de haberlas).
- Definir las reglas de negocio.
- Notificar los cambios que se hayan hecho.
- El controlador deberá:
- Recibir los eventos de entrada.
- Realizar la acción correspondiente al evento que se ha disparado.
- Las vistas deberán:
- Conseguir los datos que aporta el modelo y mostrárselos al usuario.
- Saber cual es su controlador asociado, el cual puede pedirle algunos servicios típicos como el de actualizar.
Flujo de trabajo (WorkFlow)
- El usuario realiza una acción que generará un evento.
- El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista).
- El modelo (si es necesario) llama a la vista para su actualización.
- Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
- El Controlador recibe el control.
Ventajas e Inconvenientes
Ya hemos ido comentando las ventajas de este patrón, pero de todas maneras las vamos a recopilar en este punto:
- Conseguimos múltiples vistas del modelo.
- Todas las vistas estan sincronizadas.
- No acoplamiento, y facilidad de evolución, para cambiar las vistas y los controladores.
- La aplicación puede soportar un tipo de interfaz para cada usuario (rol).
Pero también posee algunos inconvenientes:
- La complejidad va creciendo más rápido que el tamaño de la aplicación.
- Problemas al conectar las distintas capas.
- Acceso ineficiente, pues es necesario varias llamadas al modelo para actualizar los datos.
- La vista y el controlador son específicos para una plataforma.
Estilo basado en eventos
Al igual que la familia de arquitecturas de llamada y retorno, las arquitecturas basadas en evento centran su funcionamiento en la interacción tras la llegada de un evento. La diferencia radica en que en el estilo basado en eventos la interacción se realizan entre dos componentes contenidos en el sistema, mientras que la interacción de las arquitecturas llamada-retorno se producen entre un usuario, no incluido en el sistema, y un componente del sistema. Una característica que tiene que cumplir los elementos incluidos en la arquitectura es que deben ser independientes entre sí, para poder lograr la interacción deseada entre los mismos. Estas comunicaciones son dos a dos, por lo que una de las preocupaciones que hay que tener en cuenta a la hora de diseñar una arquitectura de este tipo es lograr la independencia en la interacción entre dos componentes con otra interacción. Dentro de este estilo los patrones se diferencian según sea el tipo de comunicación de la interacción, que puede ser síncrona o aśıncrona y por paso de mensajes o llamada directa. Entre los patrones de este estilo se destacan el publicador/subscriptor y el cliente/servidor
Patrón Publicador/Subscriptor
Definición del Patrón
El objetivo de este patrón es desconectar al publicador del mensaje del consumidor del mismo. El destino de un mensaje es un tópico, no un consumidor en particular. Se utiliza cuando un sistema quiere mandar un mensaje a todos los sistemas que están interesado en que les llegue, dicho mensaje. Pero el problema reside en que el sistema (fuente) desconoce que sistemas son los que están interesados en el.
Los mensajes generados por el publicador no están asociados a un destino en particular sino a un tópico. Los subscriptores están subscritos a uno o más tópicos. Una aplicación intermedia llamada broker (Ver último patrón) se encarga de mantener la lista de subscriptores por tópico y de despachar los mensajes a los subscriptores asociados.
Este patrón tiene sentido, cuando se den de alta y se borren dinámicamente miembros del grupo de distribución. De forma que el publicador desconozca a los subscriptores. Para ello, como ya se ha dicho, se utilizará un proceso intermedio que conocer los destinatarios del mensajes, según un tópico. Con ello conseguimos un desacople dentre el publicador y el subscriptor.
Indicaciones sobre la implementación
El broker en definitiva será una cola (exclusiva o compartida), en la que permitirá el balance de cargas entre los proveedores. A su vez, los consumidores, tienen una cola exclusiva. En el caso de que un mensaje sea colocado en la cola del broker, este lo servirá a las colas de los consumidores que están subscritos al tópico del mensaje. Para conseguir esto el broker deberá de tener una lista de distribución.
Es necesario contar con una estructura de tópicos (pueden estar organizados de manera jerárquica) a los cuales se subscriben los consumidores. El broker mantiene una lista de distribución por cada tópico, esta lista contiene los consumidores subscritos a cada tópico. Las colas de los consumidores y del broker pueden ser persistentes si se quiere garantizar que no se pierdan mensajes ante una falla del broker o los consumidores. Un broker puede estar subscrito a otro, esto permite crear una red de brokers. Este hecho permite que el mecanismo de publicación - suscripción sea altamente escalable. Se puede manejar un esquema similar en el cual los consumidores envíen acuses de recibo al broker y este a su vez al publicador (ya sea de manera sincrónica o asíncrona) para certificar que todos los consumidores recibieron el mensaje.
Ventajas e Inconvenientes
Las principales ventajas a la hora de utilizar el patrón publicador-suscriptor son las siguientes:
- Mayor facilidad al añadir/eliminar componentes al sistema.
- Mayor facilidad al añadir/eliminar nuevos tipos de mensajes.
- Mayor facilidad a la hora de añadir y eliminar publicadores y subscriptores (Objetivo principal).
En los inconvenientes podemos encontrar los siguientes:
- En muchos sistema baja el rendimiento.
- También es habitual una reducción de la escalabilidad.
- Crece la complejidad en el intercambio de mensajes de forma proporcional al número de encaminadores intermedios en el sistema.
Estilo basado en código móvil
Este estilo se caracteriza por su enorme portabilidad. Las arquitecturas que siguen este estilo tienen una parte del sistema que pertenece al propio entorno nativo de la máquina que lo incluye, la otra parte no. Para realizar una comunicación entre ambas partes se necesita de un intérprete que permita la traducción. Este intérprete es un conector con datos que contiene las instrucciones en el lenguaje no nativo de la máquina y una información de estado de esta parte no nativa. Por tanto, la principal preocupación que hay que tener en cuenta a la hora de diseñar una arquitectura perteneciente a esta familia es como llevar a cabo esta traducción y realizar la integración de la parte del sistema no incluida en la máquina física. El principal ejemplo de esta familia de arquitecturas es la arquitectura de máquinas virtuales.
Arquitectura de máquinas virtuales
Introducción
Cuando una persona desarrolla una aplicación en un lenguaje compilado clasico (C,C++,etc), el archivo binario que genera el compilador y que contiene el código que implementa dicha aplicación, se puede ejecutar únicamente sobre la plataforma sobre la cual fue desarrollada, debido a que dicho código es especifico a esa plataforma.
Una máquina virtual se encuentra por encima de otras plataformas. El código que generan sus compiladores no es específico de una maquina física en particular, sino de una máquina virtual. Evidentemente deben de existir múltiples implementaciones de dicha máquina, una por cada versión de la plataforma.
Consiguiendo, de esta manera, que el programador solo deba de compilar su aplicación una vez, y después puede ejecutarla donde el desee. Como se ha comentado, aún existiendo múltiples versiones de la implementación cada una de ellas especifica exactamente lo mismo.
Lenguajes Compilados, lenguajes Interpretados y lenguajes intermedios
En primer lugar se hará una breve descripción de las ventajas de unos frente a otros. Aunque parezca que no tienen nada que ver estos lenguajes con los utilizados al usar una MV, descubriremos rápidamente que estos últimos pueden clasificarse como una mezcla de los dos primeros.
En los lenguajes compilados, la ejecución es mucho más rápida que en los interpretados, ya que la conversión de la instrucción se realiza en un paso previo (compilación) y en los segundos se realiza cada vez que se ejecuta. A cambio los lenguajes compilados pierden, por esta razón (tener el programa compilado), claridad, que a su vez perjudica en posteriormente localizar los errores de una aplicación.
Estos son los dos extremos. Al utilizar una MV se realiza una compilación parcial, que es una mezcla de los dos enfoques. El códigp fuente se compila a un lenguaje intermedio, y este se interpreta.
Este lenguaje intermedio es el que le sirve a la MV de entrada. Con el que después de interpretarlo procederá a su ejecución. Este tipo de lenguajes tienen las ventajas y desventajas de los dos tipos de lenguajes comentados anteriormente.
Ventajas de usar MV
- Como ya se ha comentado, la principal ventaja (además del objetivos principal) es la portabilidad del código. Solo hará falta tener la MV en la máquina que se quiera volver a ejecutar.
- La generación de una aplicación requiere el conocimiento concreto de la plataforma en la que vamos a ejecutar el código. Pero sin embargo al utilizar una MV este problema desaparece.
- Normalmente con el aplicación compilada" (en lenguaje intermedio), podemos descompilar y obtener (no en código ensamblador, como ocurre con C p.ej.) el código fuente del lenguaje, con lo que podremos modificar de una manera muy sencilla, cualquier programa.
Inconvenientes de usar MV
Como ya dijimos tienen los inconvenientes de los lenguajes interpretados y compilados pero en menor medida:
- No son tan rápidos como los lenguajes compilados, pero si son bastante más rápidos que los interpretados. Ya que aún teniendo que codificar las instrucciones, esta es mucho más sencilla.
- Se pierde claridad, ya que no tenemos el código fuente, pero podemos conseguirlo cuando queramos descompilandolo. Del mismo modo, para encontrar un error es más complejo, pero también más sencillo que en un lenguaje compilado.
Estilo basado en sistemas distribuidos
Este estilo se da en sistemas en los que la arquitectura se distribuye, físicamente, por una red de trabajo, es decir, que los componentes del sistema no tienen por qué cobijarse en la misma máquina. Cada componente tiene sus propios datos y si necesita algún dato más, se comunica con otro componente que pertenezca a la red de trabajo que contenga la información complementaria. Se diferencia del estilo de código móvil en que, en este caso, no hay un soporte virtual incluido en la propia máquina, sino que se debe pedir información a otra máquina real. En el estilo centrado en los datos, existe un módulo que se encarga de mantener el contenido de la información, en el modelo distribuido no existe tal módulo ya que la responsabilidad de mantener los datos está distribuida por todas las máquinas pertenecientes a la red de trabajo. El ejemplo más claro de este tipo de sistemas es al arquitectura grid (o de emparrillado). En este proyecto se va a estudiar el patrón broker.
Broker
Objetivos del Patrón
Este patrón se utilizará cuando sea necesaria la interacción remota de componentes altamente desacoplados. Esto se consigue introduciendo un nuevo componente (Broker) cuya función principal es conseguir el desacomplamiento de los clientes y de los servidores.
Además de esta función principal, el Broker, registra los servidores. Con lo que conseguimos que los servicios que ofrece cada uno de los servidores estén disponibles para los posibles clientes.
Al utilizar el patrón broker estamos consiguiendo lo siguiente:
- Que los componentes sean capaces de acceder a los servicios proveídos por otros a través de invocaciones de servicios remotos transparentes en ubicación.
- Intercambiar, añadir y quitar componentes en tiempo de ejecución.
- Esconder los detalles específicos de implementación del sistema de los usuarios de componentes y servicios.
Otros componentes
Además del componente broker, los clientes y servidores. Esta está constituido, además, por los componentes Proxies y Bridges. Los primeros se pueden dividir en dos grupos:
- Client-Side-Proxy: Como su nombre indica estos se encuentran en una capa entre los clientes y el broker. Con el que se consigue que un servidor aparezca ante un componente cliente como local.
- Server-Side-Proxy: Estos tienen el mismo objetivos que los primeros y para ello, se encargan de recibir peticiones y desempaquetarlas con el fin de llamar al servicio correcto. Además se encargan de recibir resultados y excepciones del servidor, empaquetarlos y enviarlos al Broker.
En segundo lugar tenemos los Bridges que su principal objetivo es ocultar los detalles de implementación de los mecanismos de interoperatividad entre dos Brokers; así, si estos corren en redes distintas, pueden, no obstante, comunicarse entre si independientemente de los sistemas operativos sobre los cuales ellos corren.
Ventajas e Inconvenientes
En este patrón podemos encontrar las siguientes ventajas:
- Transparencia en la ubicación de los servidores.
- Facilidad de evolución ya que podemos modificar solamente un componente, sin tener que modificar el resto.
- Reusabilidad.
- Portabilidad.
Y los inconvenientes son los siguientes:
- Eficiencia no muy alta.
- Dependencia, acoplamiento, máximo al broker. Si este cae el sistema entero cae.
- Pruebas difíciles y costosas por existir tantos componentes.
Análisis de la solución para EzWeb
Se ha llegado a la conclusión que el mejor modelo de comunicación será una pizarra con publish/subscribe. En este subapartado se hará una reflexión de por que se ha llegado a esta conclusión. Para ello iremos haciendo una comparativa de por que hemos ido descartando una u otra arquitectura.
En primer lugar eliminamos la arquitectura de máquina virtual. Por que las ventajas de esta arquitecturas se dan cuando la aplicación se va a ejecutar en una o en otra máquina. Y visto que es una aplicación cliente-servidor siempre se ejecutarán en el servidor. Con lo que la portabilidad no es tan necesaria, ya que solo haría falta en el caso de mover el servidor de una máquina a otra. En el caso de que se necesitara dentro del gadgets una máquina virtual, este se ejecuta en el cliente; tendría que estar embebida en el propio gadget.
En el caso del modelo en tres capas y MVC, es directamente un error de concepto. Claro que un gadgets se puede diseñar por capas, es más es recomendable hacerlo así es una buena praxis programar de forma estructurada. Pero aquí estamos intentando comunicar unos gadgets con otros. Es decir, una aplicación con otra, no una parte de una aplicación con otra parte.
En el caso de la arquitectura Broker, textualmente la definición dice: "Este patrón se utilizará cuando sea necesaria la interacción remota de componentes altamente desacoplados". Y los gadgets se ejecutan en el cliente, por tanto no hay ninguna interacción remota. No tiene sentido los proxies para una mash-up típico de gadgets.
En el caso de tubería-filtro, también en la documentación que fue recogida dice textualmente:"debe de utilizarse siempre y cuando haya una gran cantidad de transformaciones a realizar, es decir un gran número de filtros." En nuestro caso lo normal es que exista un productor y un consumidor unidos por una tubería, pero el concepto de filtro no entra mucho en esta definición.
Hasta este momento llevamos discutidos por que no pueden ser ninguna de las otras arquitecturas que se han estudiado. Ahora se hara un pequeño estudio del problema que tiene la pizarra y el que tiene la arquitectura publish/subscrite.
La arquitectura publish/subscribe el problema que se detecta es que tiene un "embudo". Existe un "broker, una cola en la que se pondrán los mensajes, y de esta cola pasará a una cola de subscriptores. Como vemos en los inconvenientes de la arquitectura, esto hace que el rendimiento baje a la vez que crece la complejidad de intercambio de mensajes cuantos más encaminadores haya.
En cambio en el patrón pizarra este problema desaparece, ya que directamente los mensajes se dejan en la pizarra. Pero tiene el problema de seguridad, al no poseer dueños los mensajes ni ningún tipo de restricción de quien puede leer los mensajes.
Así combinando estas dos últimas tecnologías llegamos a la mejor solución encontrada hasta el momento. Por tanto llegamos a la conclusión que la comunicación será una pizarra con publish-subscribe.
D 3.2.3 Asistentes de conocimiento para la Composición y Comunicación avanzada de Recursos
Definición de asistente
Función del asistente
El asistente deberá de ser capaz de realizar la comunicación local entre las instancias de los gadgets. Para ello dispondremos de una interfaz de usuario la cual comunicará los gadgets, ya sea de manera manual o automática.
Existe un módulo de wiring, que es el encargado de ofrecer los mecanismos necesarios para proporcionar comunicación local (sin intercambio de datos con el servidor), entre las instancias de gadgets incluidas en el entorno operacional de un usuario. Ha de ofrecer un modelo de comunicación, un modo de definir que puede enviar un gadget a otros, una API que posibilite esta comunicación y una interfaz de usuario que le permita configurar las comunicaciones deseadas. Todo ello como parte del núcleo de la plataforma. Se entiende comunicación entre gadgets como el envío de información desde un gadget hacia otros, de forma que estos conozcan instantaneamente dicha información.
Las características principales son:
- Ofrecerá una interfaz para “atar” (comunicar) gadgets, de manera tanto automática como manual.
- El modelo de comunicación será una pizarra con publish/subscribe.
- La conexión es por medio del dato, abstrayendo que gadget ofrece un determinado dato (se consigue bajo acoplamiento entre gadgets).
- El template incorporará la información necesaria acerca de entradas y salidas de datos.
- Las conexiones establecidas y el valor de los datos compartidos persistirá entre sesiones.
- El módulo ofrecerá una API para los desarrolladores de gadgets (para que puedan indicar la actualización un dato).
- El módulo ha de permitir definir filtros de datos (pasar a mayusculas, reordenar nombre-apellidos)(para el futuro).
Aplicación
El proceso de comunicación entre gadgets se hará de manera transparente al usuario, en el caso de hacerlo manual también es transparente pero algo menos. En dicha interfaz habrá una pestaña dedicada al asistente, actualmente llamado "My Pipes". En este deberá de ser posible comunicar unos gadgets con otros.
En esta vista, se mostrará el wiring (la estructura interna) de los gadgets. Este es el momento en que tendremos que especificar si queremos realizar la comunicación nosotros o dejarle esta tarea al asistente. En el caso de elegir la manera automática, el wizard tras analizar los campos de cada gadget, los cuales están marcados semánticamente, hará las uniones que crea oportunas. Si existe algún conflicto hará una consulta al usuario. Y al terminar el proceso, de todas maneras, siempre dejará que el usuario lo edite como crea más conveniente, pasando a modo manual.
En el caso de haber elegido el modo manual, se nos mostrarán los gadgets previamente añadidos. Estos se muestran con la vista wiring, la cual nos enseña las entradas y salidas de cada gadget. Para comunicarlos solo tendremos que pinchar en una salida y arrastrar el ratón hasta una entrada.
Tras este proceso, manual o automático, para probar nuestro mash-up solo tendremos que acceder a la pestaña "My Instances", donde se encontrará una aplicación que será la suma de todos los gadgets que hemos utilizado con sus correspondientes enlaces.
Asistencia de composición
Ver Análisis de la solución para EzWeb
