En el campo de las ciencias de la computación y, en especial, en lo que respecta al desarrollo de sistemas de información, cada vez es más común la combinación de diversas tecnologías haciendo uso de múltiples marcos de trabajo y librerías, o conectando elementos que pertenecen a distintos desarrolladores. Este tipo de ensamblaje es bien conocido desde los comienzos de la Ingeniería del Software (SE, Software Engineering), con el diseño y construcción de sistemas software a partir de un conjunto de componentes reutilizables formando una arquitectura, dentro del campo de la Ingeniería del Software Basada en Componentes (CBSE, Component-Based Software Engineering). Estos sistemas basados en componentes pueden ser modificados y adaptados sin tener que ensamblar de nuevo cada una de las partes que los constituyen. Si se tiene acceso a la implementación, es posible realizar un proceso de actualización de su lógica interna (p.e., modificando el código) o, por el contrario, si se trata de un componente de “caja negra”, existen técnicas para la creación de un código envoltorio (wrapper) que puede ser automatizado para realizar dicha actualización. Dichos mecanismos, por lo tanto, se encargan de realizar algún cambio en la arquitectura del sistema. Esta flexibilidad permite modificar los componentes una vez que han sido desarrollados, tanto en tareas destinadas al mantenimiento y evolución del software, como en tareas de adaptación en tiempo de ejecución. Algunas de las estrategias de adaptación en tiempo de ejecución pueden ser diseñadas e implementadas durante el desarrollo del sistema, sin embargo, pueden existir otras estrategias que, por no haber sido identificadas en fase de desarrollo o por no disponer de la información necesaria, no hayan sido incluidas en el mecanismo encargado de “adaptar” el sistema. Por lo tanto, en el caso de que se quiera conseguir un sistema software basado en componentes que se adapte de forma dinámica y flexible, tanto a situaciones contempladas previamente como a las nuevas circunstancias que surjan, se pone de manifiesto la necesidad de poder aplicar nuevas opciones de “reconfiguración” que sean adicionales a la lógica de adaptación implementada. En cualquier caso, la infraestructura que de soporte a cualquiera de estas alternativas debe proporcionar las operaciones de reconfiguración necesarias, así como aquellas acciones que permitan gestionar las arquitecturas de dichos sistemas.
Una infraestructura que proporcione un soporte a la adaptación de software basado en componentes debe tener en cuenta aspectos de interoperabilidad e integración de las diferentes piezas que lo constituyen. De manera ligada a dichos aspectos y como parte de una nueva tendencia en la que los diferentes componentes que constituyen un sistema software son considerados como servicios que deben ser conectados entre sí, surge el concepto de aplicaciones mashup. En esta nueva corriente, el término mashup no se refiere únicamente a servicios web ni su ámbito de aplicación está limitado al dominio Web sino que, por el contrario, pretende agrupar a aquellas aplicaciones software desarrolladas y desplegadas como resultado de la composición de elementos software heterogéneos. A modo de ejemplo, aplicaciones mashup de interfaz de usuario son ofrecidas en forma de paneles de mandos (dashboard) para que los usuarios de dichas aplicaciones puedan configurarse una interfaz con los componentes que deseen o que más utilicen. Casos específicos de este tipo de aplicaciones puede verse en productos actuales ofrecidos por Netvibes, Geckoboard o MyYahoo. En cualquier caso, todavía existe un vacío en lo que respecta a propuestas de infraestructuras que ofrezcan un soporte global a toda la funcionalidad relacionada con la gestión de aplicaciones mashup y con su despliegue, incluyendo operaciones de alta/baja/modificación de nuevos servicios, reconfiguración de las arquitecturas que definen las aplicaciones o gestión de la comunicación entre los servicios desplegados.
El trabajo de investigación desarrollado en la presente tesis doctoral tiene como objetivo principal el desarrollo de una infraestructura que dé solución al despliegue y gestión de aplicaciones mashup. La infraestructura da soporte a aplicaciones mashup pertenecientes a distintos dominios e, incluso, que se desplieguen en dispositivos de plataformas diferentes. Con esta finalidad, la infraestructura se basa en un proceso de abstracción que nos permite definir las aplicaciones mashup como arquitecturas software en las que se representan cada uno de los componentes que forman parte de ellas, así como sus relaciones. De esta manera, las distintas piezas de las aplicaciones se gestionan de forma similar, independientemente del dominio y de la plataforma, y únicamente se ejecutan operaciones específicas de una plataforma cuando hay que generar el código necesario para el despliegue de las aplicaciones. Cada una de estas piezas ha sido nombrada como componente COTSget, de la combinación del concepto de componente COTS (Commercial Off-The-Shelf) para hacer referencia a componentes que pueden haber sido desarrollados por terceras partes, y del término gadget, que se refiere a un artefacto software que encapsula cierta funcionalidad y que permite llevar a cabo una tarea. Estos componentes son de granularidad gruesa, es decir, no se trata de componentes simples, sino que pueden tener cierta complejidad. Las aplicaciones mashup que se construyan con esta infraestructura, deben estar descritas en forma de arquitecturas software en las que cada una de sus piezas es un componente COTSget.
El modelo de infraestructura utilizado incluye tres capas. La capa que se encuentra en el nivel inferior es la capa independiente de la plataforma y contiene toda la funcionalidad que es común a todos los dispositivos para los que se pueden construir aplicaciones mashup. La capa superior está formada por las propias aplicaciones mashup que se ejecutan en navegadores (en el caso de aplicaciones de tipo web) o en contenedores de aplicaciones (en el caso de aplicaciones de tipo Java). Entre ambas capas aparece la capa dependiente de la plataforma, encargada de conectar la capa cliente con la capa independiente. El objetivo de esta capa intermedia es permitir la comunicación entre ambas capas, de manera que las aplicaciones que se encuentran desplegadas en la capa cliente puedan ser gestionadas por la lógica de las operaciones de la capa independiente (teniendo en cuenta la información que proporciona la primera) y que las decisiones tomadas en la capa independiente puedan modificar las aplicaciones en tiempo de ejecución y de forma dinámica. Esta flexibilidad se consigue sin llevar a cabo una recarga de toda la aplicación y actualizando únicamente aquellas partes de la arquitectura que han sido modificadas. La capa dependiente también contiene los distintos repositorios de componentes que pueden formar parte de las aplicaciones mashup y, dependiendo del tipo de plataforma utilizada en cada momento, se hará uso de una colección u otra. Las capas dependiente e independiente de la plataforma constituyen el núcleo de la propuesta de esta tesis doctoral y juntas reciben el nombre de COScore (COTSget-based architecture Operating Support core). Uno de los aspectos que caracterizan este núcleo de la infraestructura es que está desarrollado como un conjunto de servicios. De esta forma, el desarrollo de la infraestructura ha generado una API que ofrece toda la funcionalidad necesaria para poder llevar a cabo el despliegue de aplicaciones mashup y que, además, permite realizar todas las acciones de gestión relacionadas con el uso de dichas aplicaciones.
© 2008-2024 Fundación Dialnet · Todos los derechos reservados