Paper - Arquitectura Cloud en Capas PDF

Preview

Summary

papers...

Description

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/284673069

Un Modelo para la Representación de Arquitecturas Cloud basadas en Capas por medio de la Utilización de Patrones de Diseño: Especificación de la Capa de Aplicación Conference Paper · November 2015 CITATIONS

READS

4

1,151

3 authors: María Julia Blas

Silvio Gonnet

National Scientific and Technical Research Council

National Scientific and Technical Research Council

44 PUBLICATIONS45 CITATIONS

86 PUBLICATIONS264 CITATIONS

SEE PROFILE

Horacio Leone Universidad Tecnologica Nacional - CONICET 141 PUBLICATIONS686 CITATIONS SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Requirements Traceability View project

Software Architectural Decisions Documentation View project

All content following this page was uploaded by María Julia Blas on 09 December 2015.

The user has requested enhancement of the downloaded file.

SEE PROFILE

Un Modelo para la Representación de Arquitecturas Cloud basadas en Capas por medio de la Utilización de Patrones de Diseño: Especificación de la Capa de Aplicación María Julia Blas, Silvio Gonnet, Horacio Leone INGAR Instituto de Desarrollo y Diseño Universidad Tecnológica Nacional, CONICET Avellaneda 3657, 3000 Santa Fe, Argentina { mariajuliablas, sgonnet, hleone }@santafe-conicet.gov.ar Abstract En este trabajo se presenta un metamodelo que permite especificar arquitecturas de software orientadas a entornos de cloud computing. La propuesta parte del estudio de diferentes patrones de diseño, dando lugar a un modelo que incluye los principales componentes de estos esquemas y un conjunto de relaciones producto de su análisis. Como complemento del modelo UML se propone un conjunto de restricciones OCL que ayudan a validar las representaciones generadas. Además se presenta una herramienta de soporte para el arquitecto que ayuda en la instanciación del metamodelo, permitiendo componer arquitecturas de forma gráfica que, posteriormente, pueden ser validadas según los patrones de diseño incorporados. En este sentido, el aporte del trabajo a la ingeniería de software (más específicamente al diseño de arquitecturas), se basa en la formulación de una estrategia de representación que ayuda a definir diseños arquitectónicos específicos para aplicaciones que se ejecutan en ambientes cloud. De esta manera, se sientan las bases que permitirán, a futuro, analizar las características de diseño y los aspectos de calidad asociados a este tipo de arquitecturas.

1. Introducción En la última década, la arquitectura de software (AS) se ha convertido en una de las áreas de investigación más difundidas de la ingeniería de software [1]. La representación del conocimiento arquitectónico [2] –[4], la validación y evaluación de los diseños [5, 6] , su documentación [7, 8] y su relación con la calidad [9, 10] son algunas de las temáticas recurrentes en este área. Bass define AS como el diseño que “comprende a los componentes del software, las propiedades visibles de dichos componentes y las relaciones existentes entre los mismos” [11]. La tarea de desarrollar AS se caracteriza

por su complejidad. Debido a que el conjunto de requerimientos se obtiene y perfecciona a medida que se lleva a cabo el proceso de solución [12, 13], resulta difícil diseñar AS adaptables a estos cambios. Aunque se han desarrollado técnicas y modelos para reducir la ambigüedad al elicitar requerimientos [11, 14], la determinación de la adecuación de las decisiones tomadas respecto a una AS resulta a menudo complicada y proclive a errores. De esta manera, el diseño arquitectónico es una de las actividades del proceso de desarrollo de software que requiere mayor nivel de pericia en lo referente a técnicas y herramientas aplicables a situaciones específicas. Es difícil disponer de arquitectos que posean el “know-how” necesario para afrontar múltiples casos de diseño, por lo que es necesario brindar a los diseñadores existentes un soporte adecuado que los ayude a aumentar su productividad. Numerosos esfuerzos de investigación se han realizado en torno a este problema. En este sentido, algunos autores plantean que las decisiones arquitectónicas (DA) son el núcleo de las AS [15]–[18]. Bajo este punto de vista, las AS han evolucionado de simples representaciones estructurales a esquemas centrados en decisiones [19]. De acuerdo con Jansen [16], una DA es una descripción del conjunto de agregados, eliminaciones y modificaciones realizadas sobre una AS, el motivo de que estos cambios tengan lugar y las reglas de diseño junto con las respectivas restricciones y especificaciones adicionales que (posiblemente de forma parcial) logran cubrir uno o más de los requerimientos de la arquitectura. En términos generales, una DA es la salida que se genera en el proceso de diseño durante la construcción inicial o la evolución de un sistema de software. Específicamente, las DA de diseño refieren al dominio de aplicación del sistema, los patrones utilizados, los componentes definidos, la infraestructura seleccionada y todos los aspectos restantes necesarios para satisfacer los requerimientos del sistema. La determinación de los

patrones y componentes forma parte de las decisiones estructurales. Un patrón arquitectónico define una familia de sistemas en base a un esquema de organización estructural [20]. Es decir, determina un vocabulario de componentes y conectores junto con un gr upo de restricciones que indican la forma en la cual estos elementos pueden ser utilizados y combinados. De esta manera, los patrones describen pares de elementos {problema; solución} que brindan soluciones abstractas a problemas recurrentes en un dominio específico. En la actualidad, existe una amplia variedad de patrones arquitectónicos aplicables a productos tradicionales [20]– [23]. Sin embargo, suelen darse problemas al intentar trasladar estos patrones a sistemas de software asociados a plataformas más novedosas y/o basadas en modelos de ejecución más modernos; como por ejemplo, el esquema de computación en la nube (cloud computing, CC). CC es un modelo computacional que posibilita el acceso a internet bajo demanda de forma beneficiosa y generalizada a fin de compartir un conjunto de recursos de computación configurables que son asignados y adjudicados rápidamente con un bajo esfuerzo de administración o interacción con el proveedor del servicio [24]. Los objetivos de este paradigma involucran un aumento en la capacidad y productividad en tiempo de ejecución, sin invertir en nueva infraestructura, nuevas licencias de software ni en capacitación para empleados [25]. Para esto, el modelo propone entregar tecnología de información como servicio; por lo que, el poder de cómputo, el software, los servicios de almacenamiento y las plataformas se entregan según la demanda de consumidores externos conectados vía internet. En este contexto (al igual que ocurre en el contexto tradicional), el uso de patrones se transforma en un constructor factible de ser aplicado por los arquitectos durante el diseño. Sin embargo, a diferencia del caso tradicional, existen dos problemas derivados de la falta de madurez del área. En primer lugar, los patrones orientados a CC aún no se encuentran claramente establecidos. Dada la variedad de enfoques que pueden utilizarse en esta rama, la mayoría de los patrones existentes apuntan a la resolución de problemas asociados a la infraestructura (subyacente al diseño funcional de la aplicación). Por otro lado, no existe una técnica de representación que facilite la comprensión de las AS asociadas al cloud. Frecuentemente las estrategias de representación mezclan elementos de la infraestructura con componentes de aplicación, generando confusión y ambigüedad al lector. En este trabajo se presenta una propuesta que busca solucionar los problemas precedentes por medio de la utilización de un metamodelo que permite instanciar patrones de diseño como parte de una estrategia de representación. Teniendo en cuenta que un ambiente cloud puede diseñarse en base a diferentes esquemas y, dado que la descomposición modular es la estrategia por

excelencia utilizada como primera aproximación al diseñar una AS, el metamodelo propuesto se basa en la especificación de componentes. El estilo arquitectónico propuesto corresponde a un modelo de capas en el cual los componentes residen sobre capas funcionales separadas y el acceso es permitido únicamente entre elementos de la misma capa o de su inmediata inferior. Dada la cantidad de elementos que pueden definirse como parte de estas arquitecturas, el modelo trata únicamente con aquellos elementos que se asocian al diseño de la capa de aplicación. La incorporación de los elementos relacionados a las capas restantes forma parte de los trabajos futuros a realizar. El resto del trabajo se encuentra estructurado de la siguiente manera. La sección 2 detalla la forma en la cual suelen diseñarse las AS orientadas a CC incorporando una descripción del conjunto de patrones arquitectónicos aplicables a la capa de aplicación. La sección 3 presenta el metamodelo desarrollado para representar AS cloud, mientras que la sección 4 muestra la herramienta implementada a fin de dar soporte a la tarea de diseño arquitectónico. La sección 5 presenta la aplicación del metamodelo a dos casos de estudio. Finalmente la sección 6 sintetiza las conclusiones y trabajos futuros asociados al metamodelo obtenido.

2. Arquitectura de Software basada en un Modelo de Capas para Entornos de CC La mayor parte de la bibliografía existente plantea que las AS orientadas a CC pueden verse como un diseño basado en un modelo de capas [25] –[27]. Esto se debe a que este modelo permite definir aplicaciones distribuidas con bajo acoplamiento. Es decir, logra dividir la funcionalidad que debe proveer la aplicación en múltiples componentes que pueden ser escalados de forma independiente y, por otro lado, posibilita el uso de un intermediario de comunicación para separar la funcionalidad de los aspectos relacionados con los proveedores de servicios. Aunque los autores difieren en el nombre y cantidad de capas, así como también en las responsabilidades de cada una de ellas, se considera que el esquema presentado en [26] constituye una abstracción adecuada de estos enfoques (Figura 1). La capa inferior (hardware) es la responsable de lograr una asignación eficiente, rápida y fluida de los recursos de hardware. La segunda capa (software kernel) contiene el software que administra los recursos de hardware subyacentes. Además permite que las aplicaciones de software se ejecuten, facilitándoles el uso eficiente de los recursos. La siguiente capa (software infrastructure) administra los recursos de red a las capas superiores y provee una base para la entrega de tecnología de información como servicio. La cuarta capa (software environment) provee una plataforma de desarrollo para las aplicaciones web.

ser adaptados para su uso en CC. Uno de los enfoques más completos y prometedores en esta área pareciera ser el propuesto por Fehling en [27], en donde presenta un conjunto de patrones para la especificación de la AS de una aplicación cloud. Esta propuesta abarca patrones que involucran tanto la infraestructura de la aplicación como la lógica de negocios requerida para dar respuesta a los requerimientos de los usuarios. La Tabla 1 resume los patrones de diseño relacionados a la capa de aplicación. El conjunto de patrones presentado se encuentra dividido en tres grupos según el tipo de elemento o aspecto de la capa de aplicación sobre el cual tiene influencia (capa de aplicación, componente de aplicación y administración de la aplicación). Para mayor detalle sobre los patrones de CC, se sugiere recurrir a [27].

ELEM. / ASP.

Tabla 1. Patrones arquitectónicos asociados a los distintos elementos de la capa de aplicación [27].

Capa de Aplicación

Esta plataforma es utilizada por los desarrolladores para programar aplicaciones que trabajen sobre los recursos del cloud. Finalmente, la capa de aplicación (application) permite a los usuarios acceder a las aplicaciones instaladas sobre el centro de datos de un proveedor cloud. En esta capa residen las aplicaciones web desarrolladas con el objetivo de hacer uso de los recursos de la nube. El concepto detrás del CC es bajar el cómputo a los proveedores de recursos remotos. El proveedor de servicios cloud es el responsable de ejecutar, administrar y actualizar los recursos de hardware de acuerdo con los requerimientos de los usuarios. Esto permite que los usuarios utilicen los servicios bajo demanda según su consumo a través de Internet. Debido a que existen diferentes tipos de requerimientos por parte de los usuarios, existen diferentes tipos de servicios: infraestructura como servicio (infrastructure as a service, IaaS), almacenamiento de información como servicio (data storage as a service, DaaS), comunicación como servicio (communication as a service, CaaS), plataforma como servicio (platform as a service, PaaS) y software como servicio (software as a service, SaaS). Cada uno de estos servicios se logra ofreciendo al usuario un subconjunto de las capas propuestas (tal como se visualiza en la Figura 1).

ICONO Y/O NOMBRE DEL PATRÓN

DESCRIPCIÓN

N Bandas

Descompone los componentes de la aplicación en N bandas, cada una de las cuales puede ser escalada elásticamente de forma independiente.

Red de Distribución de Contenido

Se establecen copias de contenido (múltiples componentes relacionados) en distintas locaciones físicas distribuidas en una red.

Componente con Estado

Componente de Aplicación

1

Componente sin Estado

Figura 1. Abstracción del modelo de capas aplicable a entornos de CC (adaptado de [25], [26]).

2.1. Patrones Arquitectónicos Los patrones arquitectónicos de CC ayudan a determinar la forma en la cual pueden distribuirse los componentes de aplicación. Una vez definido el estilo de alto nivel (partición basada en capas para el caso de CC), es necesario definir que patrones de diseño se utilizarán para especificar los componentes internos. Esta selección no debe realizarse de forma arbitraria, sino que siempre se encuentra relacionada con los requerimientos no funcionales de la aplicación. No todos los patrones de CC son nuevos. Muchos de los patrones existentes para las AS tradicionales pueden

Imagen Multicomponente

Componente de Interfaz de Usuario

Componente de Procesamiento

Componente de Procesamiento Batch

1

Las instancias de un componente de aplicación sincronizan su estado interno para proveer un comportamiento uniforme.

El estado de los componentes de la aplicación es manejado de forma externa para facilitar su instanciación y hacer que la aplicación sea más tolerante a fallas de componentes.

Los servidores virtuales almacenan múltiples componentes de aplicación que pueden no estar activos en todo momento a fin de reducir el costo de las operaciones de asignación y extracción.

Las interfaces de usuario son sincrónicas debido a que son accedidas por los usuarios. Las interacciones internas de la aplicación son asincrónicas para asegurar bajo acoplamiento.

El procesamiento es manejado en componentes que pueden ser escalados elásticamente.

Las solicitudes son demoradas hasta que las condiciones del entorno posibilitan su procesamiento.

Un componente de aplicación es un elemento de la AS que se define en base a un conjunto de componentes funcionales que indican la forma en la cual la funcionalidad de la aplicación debe implementarse.

Procesador basado en Transacciones

Procesador basado en Timeout

Procesador Idempotente

Componente de Acceso a Datos

Abstracción de Datos

Watchdog

Administración de la Aplicación

Adaptador a Proveedor

Administrador de Configuración

Administrador Elástico

Balanceador de Carga Elástico

Extiende el contexto transaccional al procesamiento de los mensajes que recibe, por lo que interactúa con las ofertas de almacenamiento, lectura, procesamiento y escritura de los datos en un contexto transaccional.

Envía una confirmación luego de que ha efectivamente procesado (de forma correcta) el mensaje recibido.

Asegura que los mensajes duplicados y los datos inconsistentes no afecten la funcionalidad de la aplicación.

Maneja la complejidad del almacenamiento de datos (dada por los protocolos de acceso y la consistencia de información) de forma oculta y aislada, asegurando la configuración de las estructuras de datos.

La información es abstraída para soportar, de forma inherente, la eventual consistencia de la información almacenada. Las aplicaciones hacen frente a las fallas por medio del monitoreo y remplazo de las instancias de componentes de aplicación (siempre que el proveedor tenga disponibilidad).

Encapsula las implementaciones específicas de un proveedor en una interfaz abstracta.

Almacena las configuraciones de los componentes de aplicación en una oferta de almacenamiento central a la cual las instancias de los componentes en ejecución pueden acceder periódicamente.

Se utilizan los recursos cloud a fin de monitorear la instanciación, asignación y remoción de los componentes de aplicación.

La cantidad de accesos sincrónicos al componente es utilizada para determinar la cantidad de instancias requeridas del componente de aplicación.

Se utiliza la cantidad de accesos al componente junto con mensajes para ajustar la cantidad de instancias requeridas del componente de aplicación. Cola Elástica

3. Metamodelo para Representar el Diseño Arquitectónico de una Aplicación Cloud Durante las primeras etapas del desarrollo de una aplicación cloud, el arquitecto debe trabajar en el diseño de una AS que sea desplegable sobre la infraestructura subyacente. Es decir, aunque su diseño se encontrará situado en la capa superior del esquema presentado en la Figura 1, sus componentes deberán interactuar con los elementos ubicados en las capas inferiores. Por este motivo, es necesario diseñar una arquitectura de aplicación que satisfaga los requerimientos (funcionales y no funcionales) pero que, al mismo tiempo, tenga en cuenta las ofertas de infraestructura disponibles (a fin de ajustar el diseño resultante a las necesidades específicas).

Se define como “descripción arquitectónica” a la representación de un sistema que puede ser utilizada para su diseño, el análisis de su diseño o para la instanciación del sistema [28]. Usualmente el conjunto de elementos que se utiliza para describir una arquitectura incluye componentes, conectores y restricciones arquitectónicas. El metamodelo propuesto para representar arquitecturas cloud (Figura 2) toma como base los patrones de diseño presentados en la Tabla 1. Propone un conjunto de elementos que sintetizan los principales componentes de una arquitectura y, al mismo tiempo, facilitan la especificación de los patrones definidos. Para esto, consta de dos especificaciones complementarias: una descripción UML (que define las clases, relaciones y atributos necesarios para modelar una AS) y un conjunto de restricciones OCL (que garantizan la consistencia de los modelos instanciados). Como se observa en la Figura 2, las clases del metamodelo UML modelan diferentes aspectos de una aplicación cloud. La sección “Cloud Application Description” contiene el conjunto de elementos que permite especificar la arquitectura del entorno CC a utilizar. Esta especificación se logra instanciando la clase Representation . Una instancia de Representation debe contener u...