Administración de recursos Grid para el proyecto magos

Texto completo

(1)ADMINISTRACIÓN DE RECURSOS GRID PARA EL PROYECTO MAGOS. WILLY ALEJANDRO MONTES CÁRDENAS. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTA. DC ENERO 2010.

(2) ADMINISTRACIÓN DE RECURSOS GRID PARA EL PROYECTO MAGOS. WILLY ALEJANDRO MONTES CÁRDENAS. Tesis de Grado presentado como requisito para optar por el título de Ingeniero de Sistemas y Computación. Director: PhD. Claudia Lucía Jiménez Guarín Profesor Asociado. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN BOGOTA. DC ENERO 2010.

(3) TABLA DE CONTENIDO 1. Resumen ...................................................................................................................................... 7. 2. Introducción ................................................................................................................................ 8. 3. 2.1. El Proyecto MAGOS............................................................................................................... 8. 2.2. Descripción del problema ................................................................................................. 10. Descripción general ................................................................................................................... 12 3.1. 3.1.1. Objetivo General ....................................................................................................... 12. 3.1.2. Objetivos Específicos ................................................................................................. 12. 3.2 4. 6. 4.1. Definición del problema .................................................................................................... 17. 4.2. Especificaciones ................................................................................................................ 17. 4.2.1. Casos de Uso del Desarrollador grid ......................................................................... 18. 4.2.2. Casos de Uso del Administrador del grid .................................................................. 23. Restricciones ..................................................................................................................... 25. Desarrollo del diseño ................................................................................................................ 27 5.1. Recolección de Información .............................................................................................. 27. 5.2. Alternativas de diseño ....................................................................................................... 27. 5.3. Diseño Detallado de la Solución ........................................................................................ 28. 5.3.1. MAGOS-ADMIN............................................................................................................. 28. 5.3.2. CMA (Cliente MAGOS-ADMIN) ..................................................................................... 33. Implementación ........................................................................................................................ 40 6.1. Descripción de la implementación .................................................................................... 40. 6.1.1. Ambiente de Desarrollo ............................................................................................ 40. 6.1.2. Desarrollo de los Casos de Uso ................................................................................. 41. 6.1.3. Depuración MAGOS .................................................................................................... 48. 6.1.4. Estructura de Directorios .......................................................................................... 51. 6.1.5. Requerimientos y Proceso de Instalación ................................................................. 54. 6.2 7. Antecedentes y Contexto .................................................................................................. 12. Diseño y especificaciones .......................................................................................................... 17. 4.3 5. Objetivos ........................................................................................................................... 12. Resultados esperados ....................................................................................................... 55. Validación .................................................................................................................................. 56 7.1. Métodos ............................................................................................................................ 56. 7.1.1. Caso de Uso: Monitorear Nodos ............................................................................... 56. 7.1.2. Caso de Uso: Monitorear Servicios ........................................................................... 56.

(4) 8. 9. 7.1.3. Caso de Uso: Desinstalar Servicio ............................................................................. 56. 7.1.4. Caso de Uso: Monitorear Aplicaciones ..................................................................... 56. 7.1.5. Caso de Uso: Instalar Aplicación ............................................................................... 56. 7.1.6. Caso de Uso: Desinstalar Aplicación ......................................................................... 57. 7.1.7. Caso de Uso: Agregar Nodo al grid............................................................................ 57. 7.1.8. Caso de Uso: Modificar Configuración de MAGOS ..................................................... 57. 7.2. Validación de resultados ................................................................................................... 57. 7.3. Capturas de Pantalla ......................................................................................................... 57. 7.3.1. Caso de Uso: Monitorear Nodos ............................................................................... 58. 7.3.2. Caso de Uso: Agregar Nodo al grid............................................................................ 60. 7.3.3. Caso de Uso: Monitorear Servicios ........................................................................... 60. Conclusiones.............................................................................................................................. 64 8.1. Discusión ........................................................................................................................... 64. 8.2. Trabajo futuro ................................................................................................................... 64. Referencias ................................................................................................................................ 65. 10 Apéndice: Experiencia de Desarrollo GT4IDE y GT4.................................................................. 66.

(5) LISTA DE FIGURAS Figura 1. Arquitectura general de MAGOS [6]...................................................................................................... 9 Figura 2. Descripción de Características de MAGOS. ......................................................................................... 10 Figura 3. Arquitectura de MAGOS-WORKFLOW [6] ............................................................................................... 13 Figura 4. Arquitectura de MAGOS-APPLICATION [9] .............................................................................................. 14 Figura 5. Arquitectura de MAGOS-SERVICE [7] ..................................................................................................... 15 Figura 6. Casos de uso del Desarrollador grid .................................................................................................. 18 Figura 7. Casos de Uso del Administrador del grid ........................................................................................... 23 Figura 8. Arquitectura general de MAGOS con MAGOS-ADMIN............................................................................ 29 Figura 9. Diagrama de clases MAGOS-ADMIN - Adaptadores, Delegados y Utilidades ....................................... 30 Figura 10. Diagrama de clases de MAGOS-ADMIN - VOs Generales.................................................................... 31 Figura 11. Diagrama de clases de MAGOS-ADMIN - VOs de Nodo ...................................................................... 32 Figura 12. Diagrama de clases de MAGOS-ADMIN - VOs de Servicio .................................................................. 33 Figura 13. Diagrama de Arquitectura de CMA ................................................................................................. 34 Figura 14. Diagrama de Clases de CMA - GUI General ..................................................................................... 35 Figura 15. Diagrama de clases de CMA - GUI Configuración............................................................................ 35 Figura 16. Diagrama de clases de CMA - GUI Nodo ......................................................................................... 36 Figura 17. Diagrama de clases de CMA - GUI Aplicación ................................................................................. 37 Figura 18. Diagrama de clases de CMA - GUI Servicio ...................................................................................... 38 Figura 19. Diagrama de clases de CMA - Kernel ............................................................................................... 39 Figura 20. Wizard de Ejecución de un Proceso. [6] ........................................................................................... 51 Figura 21. Estructura de directorios de MAGOS-ADMIN ...................................................................................... 52 Figura 22. Archivo de configuración de MAGOS-ADMIN ..................................................................................... 52 Figura 23. Estructura de directorios del CMA ................................................................................................... 53 Figura 24. Archivo de propiedades del CMA ..................................................................................................... 53 Figura 25. Punto de entrada CMA .................................................................................................................... 58 Figura 26. Monitoreo de Nodos - CMA ............................................................................................................. 58 Figura 27. Información básica de un Nodo ʹ CMA ........................................................................................... 59 Figura 28. Servicios Instalados en el Nodo - CMA............................................................................................. 59 Figura 29. Fuentes de Datos instaladas en el Nodo ʹ CMA .............................................................................. 59 Figura 30. Configuración del Nodo - CMA ........................................................................................................ 60 Figura 31. Agregar Nodo al grid - CMA ............................................................................................................ 60 Figura 32. Consulta de Servicios - CMA ............................................................................................................ 60 Figura 33. Servicio Grid ʹ CMA ......................................................................................................................... 61 Figura 34. Servicio create - CMA....................................................................................................................... 61 Figura 35. Consulta de Aplicaciones - CMA ...................................................................................................... 61 Figura 36. Información de una Aplicación - CMA ............................................................................................. 62 Figura 37. Instalar Aplicación - CMA ................................................................................................................ 62 Figura 38. Configuración MAGOS-ADMIN - CMA ................................................................................................. 62 Figura 39. Configuración MAGOS-SERVICE - CMA ................................................................................................ 63 Figura 40. Configuración MAGOS-APPLICATION - CMA ......................................................................................... 63 Figura 41. Configuración MAGOS-WORKFLOW - CMA .......................................................................................... 63.

(6) LISTA DE TABLAS Tabla 1. Descripción Caso de Uso Monitorear Nodos ....................................................................................... 18 Tabla 2. Descripción Caso de Uso Monitorear Servicios ................................................................................... 19 Tabla 3. Descripción Caso de Uso Añadir Réplicas a un Servicio ...................................................................... 20 Tabla 4. Descripción Caso de Uso Quitar Réplicas a un Servicio ....................................................................... 20 Tabla 5. Descripción Caso de Uso Desinstalar Servicio ..................................................................................... 21 Tabla 6. Descripción Caso de Uso Monitorear Aplicaciones ............................................................................. 21 Tabla 7. Descripción Caso de Uso Instalar Aplicación....................................................................................... 22 Tabla 8. Descripción Caso de Uso Desinstalar Aplicación ................................................................................. 23 Tabla 9. Descripción Caso de Uso Agregar Nodo al grid .................................................................................. 23 Tabla 10. Descripción Caso de Uso Quitar Nodo del grid ................................................................................. 24 Tabla 11. Descripción Caso de Uso Modificar Configuración de MAGOS ........................................................... 25.

(7) 1 Resumen La computación en malla (Grid Computing1) es una infraestructura tecnológica que permite compartir poder computacional y almacenamiento de datos. El proyecto MAGOS aparece como un middleware para facilitar y simplificar el desarrollo de aplicaciones orientadas a servicios sobre un grid. Sin embargo, el proyecto MAGOS carece de una herramienta que soporte la administración de los diferentes recursos del grid. La elaboración de dicha herramienta es el objetivo de este trabajo.. 1. En este trabajo se utiliza la terminología técnica en ingles. Las palabras y siglas grid, middleware, standalone, por nombrar las más frecuentes, son dejadas en ese idioma de forma intencional.. 7.

(8) 2 Introducción Actualmente, las aplicaciones han evolucionado y, a medida que progresan, sus exigencias de poder de procesamiento y almacenamiento de información crecen. Surge la necesidad de repositorios ágiles y robustos para almacenar los datos y una gran potencia de cómputo para realizar las complejas operaciones que implica el procesamiento de esos datos. Sumado a estos requerimientos, ahora más que nunca, las aplicaciones tienen la necesidad de cooperar entre sí a través de los procesos de negocio. La tecnología grid Computing se postula como una buena alternativa para resolver estas necesidades dado que su principal objetivo es compartir los recursos ofrecidos por conjuntos de sistemas heterogéneos de forma segura y eficiente, indistintamente de su ubicación[1]. Una infraestructura grid integra y coordina recursos provenientes de dominios heterogéneos, que no se encuentran sujetos a un control centralizado, por medio del uso de protocolos e interfaces libres y estándar para poner a disposición del usuario atributos que ayuden a cumplir con sus demandas[2]. Estos sistemas han madurado y evolucionado hacia una nueva generación [3], una generación orientada a servicios. Esta generación permite un mayor uso del grid ya que ofrece servicios que pueden ser accedidos por una gran cantidad de usuarios. El principio de este paradigma es que un usuario ofrece un servicio, una entidad orientada a la red que ofrece una función específica [4], que puede ser descubierta por otro usuario, el cual puede decidir aprovecharlo y/o componerlo para crear una nueva funcionalidad y ofrecerla como un nuevo servicio [5]. Partiendo de este punto de vista y teniendo presente que las infraestructuras grid se hacen más accesibles día a día para los desarrolladores y cuya curva de aprendizaje es muy pronunciada, nace el proyecto MAGOS (Middleware Architecture for Grid Oriented Services). MAGOS es un middleware que busca simplificar el proceso de enfrentarse a un grid, por lo que brinda facilidades de instalación, descubrimiento y composición de servicios. El objetivo principal de este middleware es establecer una arquitectura en la cual aplicaciones autónomas y heterogéneas puedan instalarse de forma sencilla sobre el grid, proporcionando sus requerimientos de forma descriptiva, sin generar acoplamiento y permitiendo la cooperación entre ellas[6].. 2.1. El Proyecto MAGOS. MAGOS es una herramienta que facilita a desarrolladores de aplicaciones orientadas a servicios el uso de un datagrid mediante un proceso basado en la descripción declarativa de requerimientos no funcionales [7]. MAGOS simplifica los aspectos de la infraestructura tecnológica y reduce la curva de aprendizaje del desarrollador SOA (Service Oriented Architecture) permitiéndole concentrarse más en las características de su aplicación que en los detalles de instalación y cooperación dentro del grid. MAGOS provee mecanismos para que las aplicaciones instaladas puedan cooperar con aplicaciones de terceros garantizando seguridad y confidencialidad [6]. El principal aporte de MAGOS es facilitar los procesos de descripción, instalación, ubicación y ejecución de aplicaciones que exponen servicios en un datagrid, respetando la heterogeneidad y autonomía de cada una de estas. [8]. 8.

(9) MAGOS se fundamenta en una arquitectura multicapas, orientadas a lograr cada una de las tareas principales anteriormente descritas. En la Figura 1 se presenta la arquitectura de MAGOS. La capa MAGOS-SERVICE [7] se encarga de la instalación, ubicación y ejecución de servicios sobre el grid de forma independiente de otros servicios y siguiendo su descripción no funcional. MAGOSAPPLICATION[9] se ocupa de la instalación de aplicaciones sobre el grid, donde una aplicación está compuesta por uno o más servicios que cooperan entre sí. Esta capa tiene la información de las aplicaciones y servicios y ofrece un catálogo con diversos filtros que permiten consultar las aplicaciones. Y por último, la capa MAGOS-WORKFLOW [6], cuya labor es permitir la orquestación y cooperación de las aplicaciones a través de procesos.. Figura 1. Arquitectura general de MAGOS [6]. Como se mencionó anteriormente, en el ambiente MAGOS se habla de tres propiedades claves, heterogeneidad, autonomía y cooperación, que aplican a los dos tipos de componentes principales que maneja el middleware: aplicaciones y servicios. Con la heterogeneidad se busca que los componentes se comuniquen entre sí sin importar el hardware, el sistema operativo o la fuente de datos que necesiten para su funcionamiento. La autonomía permite que se describan a sí mismos para poder ser instalados sobre el grid y, una vez hecho esto, puedan tomar decisiones a la hora de ejecutarse. Por último, el objetivo de la cooperación consiste en que la ejecución de los 9.

(10) componentes sea coordinada y conjunta [7]. En la Figura 2 se pueden apreciar estas características. Los conectores indican dependencia. La aplicación 1 está compuesta por los servicios A, B, C y D, mientras la aplicación 2 por los servicios X, E, C y F. Las dos aplicaciones comparten el servicio C, sin embargo cada una es propiedad de un desarrollador diferente.. Figura 2. Descripción de Características de MAGOS.. 2. Dentro de la arquitectura MAGOS, el propósito del presente trabajo es proponer y desarrollar una infraestructura que permita administrar los diferentes recursos disponibles del grid. Esta infraestructura respeta las características de estos recursos y aprovecha las facilidades ofrecidas por las diferentes capas de la arquitectura MAGOS para cumplir con su funcionalidad.. 2.2. Descripción del problema. Dentro del contexto MAGOS, los desarrolladores grid cuentan con herramientas que les permiten implementar servicios grid. A partir de estos servicios, pueden crear aplicaciones MAGOS e instalarlas sobre el middleware. Luego, el desarrollador puede consultar las aplicaciones instaladas y usarlas dentro de la definición de procesos de negocio. Posteriormente, estos procesos pueden ser consultados y ejecutados. Siguiendo esta secuencia de eventos, el desarrollador puede querer obtener un rendimiento diferente del grid para la ejecución de sus procesos. Para esto, podría desinstalar una aplicación, modificar el número de réplicas de un servicio o simplemente cambiar la configuración de una de las capas del middleware. Estas operaciones de administración de los diferentes recursos que se encuentran disposición del desarrollador son el objetivo de MAGOS-ADMIN. Este componente es una herramienta que ofrece servicios que habilitan al desarrollador la administración de los recursos del grid y el poder de adaptarlo a sus necesidades.. 2. Tomado de la presentación de sustentación de tesis de Maestría de[6], [7] y [9].. 10.

(11) El presente documento está organizado de la siguiente forma: El capítulo 3 presenta la descripción general del problema y antecedentes que aportan a la solución. En el capítulo 4 se presenta una definición precisa del problema dando los casos de uso y restricciones derivadas. En el capítulo 5 se exponen las diferentes fuentes de información usadas para encontrar las alternativas de solución, así como la descripción de cada una, en específico, la que se decide implementar. En el capítulo 6 se habla del ambiente de desarrollo de la solución y de los resultados obtenidos. En el capítulo 7 se presentan los métodos usados para la validación de la solución así como los resultados esperados de estos. El capitulo 8 presenta las conclusiones.. 11.

(12) 3 Descripción general 3.1. Objetivos. 3.1.1 Objetivo General El objetivo general de este trabajo es diseñar y desarrollar una herramienta que permita administrar los diferentes recursos del grid para el proyecto MAGOS. Debe proveer granularidad de administración a nivel de servicios, aplicaciones y procesos, teniendo en cuenta que, las aplicaciones, son autónomas y heterogéneas.. 3.1.2 Objetivos Específicos ¾ Plantear y desarrollar un componente que complemente la arquitectura MAGOS y exponga servicios de administración sobre los diferentes recursos del grid. Dicho componente permite: o. Monitorear los diferentes nodos del grid que están registrados en MAGOS en cuanto a características de procesamiento y disponibilidad de servicios.. o. Administrar la replicación de un servicio MAGOS.. o. Administrar la replicación de un servicio de datos MAGOS.. o. Administrar las aplicaciones instaladas sobre MAGOS.. ¾ Plantear y desarrollar una aplicación stand-alone que permita hacer uso de los servicios de administración de MAGOS. ¾ Asegurar la actualización de herramientas de desarrollo compatibles con el proyecto MAGOS. 3.2. Antecedentes y Contexto. El proyecto MAGOS ha tenido dos grandes iteraciones de desarrollo: la primera, en donde se creó MAGOS, se definió su arquitectura y la funcionalidad de cada una de las capas [7][9][6], y la segunda, donde se virtualizó el ambiente MAGOS, se crearon extensiones a éste y se corrigieron errores encontrados sobre los resultados de la primera iteración[10][11][12]. En la primera iteración se diseñó MAGOS sin tener en cuenta una futura necesidad de administrar los recursos del grid. Esta necesidad se hizo evidente en la segunda durante el desarrollo de extensiones del middleware. Dado que, en la segunda iteración, no estaba planeada la realización de dicha herramienta, se dejó pendiente para una futura iteración o extensión de MAGOS. El desarrollo de MAGOS-ADMIN contempla la administración de los recursos del grid, para lo cual, en la arquitectura existente, se cuenta con servicios que pueden ser adaptados y/o extendidos para que soporten dicha funcionalidad. Al estudiar los servicios prestados por las distintas capas de MAGOS (Ver Figura 1) se llegó a las siguientes consideraciones:. 12.

(13) ¾ MAGOS-WORKFLOW Esta capa permite la cooperación entre las aplicaciones instaladas en MAGOS. Logra la ejecución de diferentes procesos de negocio compuestos de diversas aplicaciones sobre el grid [6]. Las aplicaciones que hacen parte del flujo de actividades de un proceso de negocio pueden cambiar en el tiempo, es decir, una aplicación puede ser desinstalada o puede cambiar sus políticas de seguridad, impidiendo que el proceso se ejecute nuevamente. Dado que MAGOSWORKFLOW tiene en cuenta este hecho, la administración de los procesos está intrínseca en la definición de la capa y no es necesario ofrecerla nuevamente en MAGOS-ADMIN. La arquitectura de esta capa se presenta en la Figura 3.. Figura 3. Arquitectura de MAGOS-WORKFLOW [6]. ¾ MAGOS-APPLICATION Esta capa está encargada de la instalación, ubicación y ejecución de las aplicaciones en el grid. Para cumplir con su objetivo cuenta con un catálogo de las aplicaciones instaladas y de los respectivos servicios que las componen así como sus correspondientes dependencias [9]. La Figura 4 muestra la arquitectura de esta capa.. 13.

(14) Figura 4. Arquitectura de MAGOS-APPLICATION [9]. Los servicios expuestos por esta capa son: o. Instalación de aplicaciones en MAGOS. o. Consulta del catálogo de aplicaciones instaladas. o. Validación de la existencia de aplicaciones. o. Ejecución de aplicaciones instaladas. De estos servicios, la instalación de aplicaciones y consulta del catálogo son relevantes para MAGOS-ADMIN. Adicionalmente, se necesita que la capa ofrezca servicios de consultas sobre el catálogo de servicios instalados y la desinstalación de aplicaciones completas como de servicios individuales.. ¾ MAGOS-SERVICE Esta capa tiene la información de los nodos que conforman el grid, conoce la localización y el poder computacional de cada uno. Por otro lado, sabe donde están instalados los servicios tanto grid como de datos y sus distintas réplicas [7]. Esta capa ofrece los siguientes servicios: o. Localización de servicios 14.

(15) o. Consulta de servicios por identificador. o. Instalación de servicios. o. Desinstalación de servicios. o. Consulta de la información de un nodo del grid. Adicionalmente, MAGOS-SERVICE cuenta con una operación de localización de los nodos que conforman el grid, sin embargo, esta no se ofrece como un servicio de la capa. La arquitectura de la capa se expone en la Figura 5.. Figura 5. Arquitectura de MAGOS-SERVICE [7]. 15.

(16) Todos los servicios ofrecidos por MAGOS-SERVICE colaboran con la administración de los recursos del grid. No obstante, se requiere la implementación de un servicio que permita la consulta de servicios que se encuentren instalados en determinado nodo. Por otro lado, es necesario exponer como servicio la operación de localización de los nodos que conforman el grid y crear servicios que habiliten al administrador para poder agregar y quitar nodos al mismo. ¾ GT4UTILS Esta es una librería que ofrece tres utilidades convenientes para las capas de MAGOS. Estas son: o. Utilidades para una creación y extracción rápida y simple de archivos jar. o. Utilidades para el manejo de archivos de configuración. o. Operaciones que permiten la carga dinámica de clases durante ejecución y la invocación de servicios GT4 (Globus Toolkit versión 4 [13]).. La funcionalidad clave de esta librería, para el componente de administración, es el manejo de los archivos de configuración. Esta utilidad permite la carga y consulta de propiedades individuales de configuración para una capa de la arquitectura. Adicionalmente, a estas operaciones se requiere poder obtener el conjunto completo de propiedades de configuración y realizar modificaciones sobre estas.. 16.

(17) 4 Diseño y especificaciones 4.1. Definición del problema. Como se mencionó anteriormente, el desarrollador grid, en el contexto MAGOS, desea obtener información referente a cada una de las máquinas que conforman el grid, tanto información de rendimiento y almacenamiento como información de los servicios instalados en estas. Por otra parte, el desarrollador necesita información y un mecanismo para administrar los diferentes servicios y aplicaciones instalados en MAGOS para poder acomodar las características que ofrece el grid a las condiciones óptimas. A partir de esto, MAGOS-ADMIN brinda las siguientes funcionalidades: ¾ Permitir, al desarrollador y al administrador, realizar un monitoreo sobre los diferentes recursos de MAGOS. Teniendo en cuenta que el término recurso, dentro de este documento, hace referencia a nodos del grid (máquinas), servicios y fuentes de datos instalados en MAGOS y aplicaciones MAGOS. ¾ Permitir una administración de dichos recursos, específicamente, cambiar la cantidad de elementos de un recurso existente en el grid, agregar un nuevo recurso y quitar completamente un recurso. ¾ Permitir la modificación de la configuración de cada una de las capas de MAGOS.. 4.2. Especificaciones. Las siguientes son las especificaciones que debe cumplir una solución adecuada del problema: ¾ Se desea que la administración de los recursos se realice por medio de un API (Application Programming Interface) de servicios para ser expuesto al desarrollador MAGOS. ¾ Se desea el desarrollo de una aplicación GUI (Graphical User Inteface) stand-alone que consuma ese API y permita su uso desde equipos de desarrollo actuales. ¾ Se desea la reutilización de las operaciones existentes para ofrecer servicios de administración de los recursos y no hacerlas en su totalidad. Por lo tanto, se define como alcance del trabajo un punto intermedio entre los cambios necesarios a una capa MAGOS, la cual que ofrece servicios útiles para los objetivos del proyecto, y afectar la funcionalidad de la capa realizando toda la lógica de un nuevo servicio. La especificación funcional se concreta a través de los casos de uso que se presentan a continuación. Estos casos de uso están definidos para dos actores del sistema: el desarrollador grid y el administrador del grid. Cabe resaltar que los casos de uso del desarrollador también aplican para el administrador.. 17.

(18) 4.2.1 Casos de Uso del Desarrollador grid A continuación se muestran y describen los casos de uso que aplican a un desarrollador grid:. Figura 6. Casos de uso del Desarrollador grid. 4.2.1.1 Caso de Uso: Monitorear Nodos Descripción. Permite al desarrollador monitorear los diferentes nodos del grid. De cada nodo se puede obtener información acerca de su poder computacional y los recursos que se encuentran instalados sobre este. Entidades MAGOS-ADMIN MAGOS-SERVICE Involucradas MAGOS-SERVICENODE Flujo Normal de Eventos Desarrollador Sistema 1. Solicita ver las máquinas del grid Muestra la lista de IPs de las máquinas que conforman el grid. 2. Escoge la IP de la máquina de la cual desea ver la información detallada. Muestra la información de la máquina que corresponde a la IP escogida. Tabla 1. Descripción Caso de Uso Monitorear Nodos. 4.2.1.2 Caso de Uso: Monitorear Servicios Descripción. Permite monitorear los servicios que se encuentran instalados en MAGOS. La información que se puede obtener de un servicio se compone de sus características básicas, dependencias y réplicas. 18.

(19) Entidades Involucradas. MAGOS-ADMIN MAGOS-APPLICATION MAGOS-SERVICE. Flujo Normal de Eventos Desarrollador Sistema 1. Solicita ver los servicios instalados en el grid (Servicios grid o de Datos). Ofrece los criterios de búsqueda por identificador lógico o nombre del servicio. 2. Ingresa palabras de búsqueda o selecciona la opción de mostrar todos los servicios. Muestra la lista de servicios que coinciden con los criterios de búsqueda. 3. Selecciona el servicio del cual desea ver la información detallada. Muestra la información detallada del servicio seleccionado. Tabla 2. Descripción Caso de Uso Monitorear Servicios. 4.2.1.3 Caso de Uso: Añadir Réplicas a un Servicio Descripción. Permite aumentar el número de réplicas de un servicio instalado en el grid. Dicho número no puede exceder la cantidad de nodos del grid donde no se encuentra instalado el servicio. MAGOS-ADMIN Entidades Involucradas MAGOS-APPLICATION MAGOS-SERVICE Flujo Normal de Eventos Desarrollador Sistema 1. Realiza una consulta sobre los servicios instalados. Muestra la lista de servicios que coinciden con los criterios de búsqueda. 2. Selecciona el servicio al que desea aumentarle el número de réplicas. Muestra la información detallada del servicio seleccionado. 3. Activa la opción de aumentar el número de réplicas del servicio. Muestra un diálogo solicitando la cantidad de replicas adicionales que desea y si va a exceder o no el máximo de réplicas definido para el servicio. 19.

(20) 4. Escoge un número mayor al número de réplicas existentes y decide si respetar o no el máximo definido al instalar la aplicación. Modifica el número de réplicas del servicio. Tabla 3. Descripción Caso de Uso Añadir Réplicas a un Servicio. 4.2.1.4 Caso de uso: Quitar Réplicas a un Servicio Descripción. Permite disminuir la cantidad de réplicas de un servicio instalado en el grid, desinstalarlo. Entidades MAGOS-ADMIN MAGOS-APPLICATION Involucradas MAGOS-SERVICE Flujo Normal de Eventos Desarrollador Sistema 1. Realiza una consulta sobre los servicios instalados. Muestra la lista de servicios que coinciden con los criterios de búsqueda. 2. Selecciona el servicio al que desea reducirle el número de réplicas. Muestra la información detallada del servicio seleccionado. 3. Donde se muestran las diferentes réplicas del servicio, selecciona las que desea quitar y activa la opción de reducir el número de réplicas del servicio. Modifica el número de réplicas del servicio. Tabla 4. Descripción Caso de Uso Quitar Réplicas a un Servicio. 4.2.1.5 Caso de Uso: Desinstalar Servicio Descripción. Permite desinstalar un servicio del grid. El desarrollador debe poder decidir si desea forzar la desinstalación del servicio si encuentra aplicaciones y/o servicios que dependan de éste. MAGOS-ADMIN Entidades Involucradas MAGOS-APPLICATION MAGOS-SERVICE Flujo Normal de Eventos Desarrollador Sistema 1. Realiza una consulta sobre los servicios instalados. 20.

(21) Muestra la lista de servicios que coinciden con los criterios de búsqueda. 2. Selecciona el servicio que desea desinstalar. Muestra la información detallada del servicio seleccionado. 3. Activa la opción de desinstalar servicio. Despliega un diálogo preguntando si desea forzar la desinstalación aún si encuentra servicios que dependan de éste. 4. Elige y acepta. Desinstala el servicio de acuerdo a las opciones escogidas. Tabla 5. Descripción Caso de Uso Desinstalar Servicio. 4.2.1.6 Caso de Uso: Monitorear Aplicaciones Descripción. Permite monitorear las aplicaciones que se encuentran instaladas sobre MAGOS. La información a la que se puede acceder de una aplicación consiste en sus características como nombre, identificador, descripción, cuál es su servicio principal, etc. Entidades MAGOS-ADMIN MAGOS-APPLICATION Involucradas MAGOS-SERVICE Flujo Normal de Eventos Desarrollador Sistema 1. Solicita ver las aplicaciones instaladas en el grid. Ofrece los criterios de búsqueda por identificador, nombre, descripción o categoría de la aplicación. 2. Ingresa palabras de búsqueda o selecciona la opción de mostrar todas las aplicaciones. Muestra la lista de aplicaciones que coinciden con los criterios de búsqueda. 3. Selecciona la aplicación de la cual desea ver la información detallada. Muestra la información detallada de la aplicación seleccionada. Tabla 6. Descripción Caso de Uso Monitorear Aplicaciones. 21.

(22) 4.2.1.7 Caso de Uso: Instalar Aplicación Descripción Entidades Involucradas. Permite instalar una nueva aplicación en MAGOS. MAGOS-ADMIN MAGOS-APPLICATION Flujo Normal de Eventos Desarrollador Sistema 1. Selecciona la opción de instalar aplicación. Muestra un diálogo solicitando el descriptor de instalación de la aplicación. 2. Ingresa el descriptor de la aplicación. Instala la aplicación. Precondiciones Los archivos gar de los servicios que componen la aplicación deben contener la documentación generada por medio del Cliente MAGOS. Tabla 7. Descripción Caso de Uso Instalar Aplicación. 4.2.1.8 Caso de Uso: Desinstalar Aplicación Descripción. Entidades Involucradas. 1.. 2.. 3.. 4.. Permite desinstalar una aplicación de MAGOS. Se debe permitir al desarrollador decidir forzar la desinstalación de los servicios públicos o autorizados de la aplicación. MAGOS-ADMIN MAGOS-APPLICATION Flujo Normal de Eventos Desarrollador Sistema Realiza una consulta sobre las aplicaciones instaladas. Muestra la lista de aplicaciones que coinciden con los criterios de búsqueda. Selecciona la aplicación que desea desinstalar. Muestra la información detallada de la aplicación seleccionada. Activa la opción de desinstalar la aplicación. Despliega un diálogo preguntando si desea forzar la desinstalación de todos los servicios que componen la aplicación aún si algunos de estos sean servicios públicos o autorizados, o solo desinstalar los servicios privados. Elige y acepta. Desinstala la aplicación y los servicios 22.

(23) que la componen de acuerdo a las opciones escogidas. Tabla 8. Descripción Caso de Uso Desinstalar Aplicación. 4.2.2 Casos de Uso del Administrador del grid Los casos de uso anteriormente mencionados también aplican para el administrador del grid. Adicionalmente, los siguientes casos de uso son propios de este rol:. Figura 7. Casos de Uso del Administrador del grid. 4.2.2.1 Caso de Uso: Agregar Nodo al grid Descripción Entidades Involucradas. Permite añadir un nodo más al grid. MAGOS-ADMIN MAGOS-SERVICE Flujo Normal de Eventos Administrador Sistema 1. Solicita ver las máquinas del grid Muestra la lista de IPs de las máquinas que conforman el grid. 2. Selecciona la opción de agregar una nueva máquina al grid. Muestra un diálogo solicitando la URI de la capa MAGOS-SERVICENODE del nuevo nodo a instalar. 3. Ingresa la URI Valida la URI dada y agrega el nodo al grid. Precondiciones La máquina que se va a agregar al grid debe tener instalado y configurado MAGOS-SERVICENODE y, por consiguiente, las tecnologías de las que depende esta capa. Tabla 9. Descripción Caso de Uso Agregar Nodo al grid. 23.

(24) 4.2.2.2 Caso de Uso: Quitar nodo del grid Descripción. Entidades Involucradas. 1.. 2.. 3.. 4.. Permite quitar un nodo del grid. Al quitar un grid se debe tener en cuenta que pueden existir servicios grid y/o de datos instalados sobre éste que sean réplicas únicas. El administrador debe decidir si forzar la remoción del nodo si se llega a presentar el caso. MAGOS-ADMIN MAGOS-APPLICATION MAGOS-SERVICE Flujo Normal de Eventos Administrador Sistema Solicita ver las máquinas del grid Muestra la lista de IPs de las máquinas que conforman el grid. Escoge la IP de la máquina que desea quitar del grid. Muestra la información de la máquina que corresponde a la IP escogida. Selecciona la opción de remover el nodo del grid. Muestra un diálogo preguntando si se debe forzar la remoción del nodo aún si se encuentran réplicas únicas de servicios en ese nodo. Elige y acepta. Remueve el nodo de acuerdo a las opciones escogidas. Tabla 10. Descripción Caso de Uso Quitar Nodo del grid. 4.2.2.3 Caso de Uso: Modificar Configuración de MAGOS Descripción. Permite ver y modificar la configuración de cada una de las capas de MAGOS. Este caso de uso se divide en dos casos: ¾ Modificación de la configuración de las capas MAGOS-ADMIN, MAGOSSERVICE, MAGOS-APPLICATION o MAGOS-WORKFLOW ¾ Modificación de la configuración de un nodo del grid (capa MAGOSSERVICENODE). Caso 1. Entidades Involucradas. MAGOS-ADMIN MAGOS-SERVICE MAGOS-APPLICATION MAGOS-WORKFLOW. Flujo Normal de Eventos Administrador 1. Escoge la opción de ver la configuración de las capas de MAGOS. 24. Sistema.

(25) Muestra la configuración de cada una de las capas MAGOS. 2. Realiza los cambios deseados a la configuración de las capas y guarda los cambios. Efectúa los cambios de la configuración e informa que se debe reiniciar el Globus (contenedor GT4 [13]) de los nodos a los que se les cambio la configuración para que los cambios se hagan efectivos. Caso 2 MAGOS-ADMIN MAGOS-SERVICENODE Flujo Normal de Eventos Administrador Sistema 1. Solicita ver las máquinas del grid Muestra la lista de IPs de las máquinas que conforman el grid. 2. Escoge la IP de la máquina de la que desea modificar la configuración. Muestra la información de la máquina que corresponde a la IP escogida. 3. Se dirige a la configuración del nodo, realiza los cambios deseados a la configuración y guardar los cambios. Efectúa los cambios de la configuración e informa que se debe reiniciar el Globus del nodo para que los cambios a la configuración se hagan efectivos.. Entidades Involucradas. Tabla 11. Descripción Caso de Uso Modificar Configuración de MAGOS. 4.3. Restricciones. Dada las especificaciones se obtienen las siguientes restricciones: ¾ La arquitectura de la solución debe complementar la arquitectura MAGOS agregando los servicios de administración de recursos al conjunto de servicios ya ofrecidos por el middleware. ¾ La interacción del usuario con los recursos y su administración debe realizarse por medio de la aplicación GUI stand-alone. ¾ Escalabilidad: Dado que la solución debe ser un API de servicios, esta debe soportar una carga considerable de usuarios. Por la parte de la aplicación GUI, dado que es stand-alone un único usuario puede acceder a esta simultáneamente. 25.

(26) ¾ A nivel de seguridad y rendimiento no se establecen restricciones. Tampoco se realizaron servicios de administración de estos aspectos. ¾ En cuanto a flexibilidad, se desea que el API de servicios se comunique por medio de mensajes XML (eXtensible Markup Language) para que conserve uniformidad con las demás capas de MAGOS.. Adicionalmente se presentaron restricciones de carácter técnico. Este trabajo se desarrolla en paralelo con [14] y, dado que ambos proyectos están basados en la infraestructura grid y el Proyecto MAGOS, se decide desde un comienzo implementar las soluciones bajo las condiciones de las dos iteraciones de desarrollo del middleware. Estas condiciones consisten en la utilización de los equipos de la sala de cómputo Alan Turing de la Universidad de Los Andes. Inicialmente, se instalan en tres de estos equipos las máquinas virtuales obtenidas de la última iteración de MAGOS.. 26.

(27) 5 Desarrollo del diseño 5.1. Recolección de Información. Toda la información que se necesita para desarrollar la solución se obtiene, básicamente, de dos fuentes: la implementación del proyecto MAGOS, el código como tal, y los trabajos de tesis que corresponden a las dos iteraciones del desarrollo del middleware. A partir de estas fuentes se obtiene información de cómo opera cada una de las capas de MAGOS, cómo pueden ser utilizados los servicios que cada una ofrece y que servicios se deben implementar para completar la funcionalidad deseada. MAGOS funciona sobre un grid en el que en cada nodo debe contar con una instalación de GT4. En cada uno de estos nodos es necesario que se encuentre instalado el componente MAGOSSERVICENODE (Ver Figura 5), el cual es el encargado, en primera instancia, de instalar los servicios en el contenedor local de GT4. Por otra parte, ofrece un servicio que provee información acerca de la configuración del hardware existente en el nodo y, por último, presta un servicio de replicación que se encarga de asociar las fuentes de datos a los servicios del grid [7]. Ahora bien, las capas MAGOS-SERVICEMANAGER (Figura 5), MAGOS-APPLICATION y MAGOS-WORKFLOW deben encontrarse instaladas en alguno de los nodos del grid, no necesariamente en el mismo. Por su parte, MAGOS-SERVICEMANAGER es el encargado de instalar los servicios sobre el grid independientemente de otros servicios y siguiendo su descripción no funcional. Además, permite la localización de los servicios de acuerdo a su disponibilidad con el objetivo de lograr el mejor desempeño a la hora de realizar la ejecución de estos. Este componente cuenta con una base de datos en la cual almacena información referente a los servicios que se han instalado en el grid, las diferentes replicas que se crearon a partir de estos y las fuentes de datos que usan [7]. A su vez, MAGOS-APPLICATION permite la instalación de aplicaciones en el grid apoyándose en Magos-SERVICE para cumplir su funcionalidad. A la hora de instalar una aplicación este componente registra la meta-data de la aplicación en una base de datos para poder ofrecer la consulta de esta última a través del catálogo [9]. Por otro lado, MAGOS-WORKFLOW es quien permite la cooperación de las aplicaciones instaladas en el grid por medio de procesos de negocio. Para realizar la administración de estos procesos, esta capa cuenta con una base de datos que almacena la información y cada una de las instancias de estos [6]. Teniendo en cuenta esta información, MAGOS-SERVICE y MAGOS-APPLICATION cuentan, en sus respectivas bases de datos, la información relevante para MAGOS-ADMIN. En esas bases de datos se encuentran las descripciones de las fuentes de datos, los servicios y aplicaciones instaladas y las respectivas dependencias entre estos recursos, información vital para lograr la administración de los mismos.. 5.2. Alternativas de diseño. Dado que las especificaciones y restricciones del diseño limitan mucho las alternativas posibles de solución, se considera y describe en este trabajo aquella que cumple en mayor grado con las siguientes dos características: ¾ Extiende la arquitectura existente reutilizando al máximo los servicios ya ofrecidos por esta.. 27.

(28) ¾ Causa el menor impacto a la implementación actual de MAGOS. Teniendo en cuenta esto, MAGOS-ADMIN se diseña como una capa que complementa la arquitectura de MAGOS, un conjunto de servicios encapsulados en un servicio grid que conserva la misma estructura de las demás capas que hacen parte del middleware. Para lograr validar, probar y ofrecer una aplicación que consuma los servicios de MAGOS-ADMIN, se construye un cliente GUI, el Cliente MAGOS-ADMIN, de aquí en adelante CMA. La arquitectura de esta aplicación se divide en dos capas: interfaz gráfica y orquestador/delegado de servicios que se comunica con MAGOS. Dado que el CMA tiene un alto manejo de ventanas y diálogos que interactúan con el usuario, se decide usar la herramienta grafica ofrecida por Swing: JDesktopPane. Esta herramienta permite tener una sola ventana que actúa como contenedor para todas las demás ventanas y diálogos que interactúan con el usuario.. 5.3. Diseño Detallado de la Solución. A continuación se presenta el diseño detallado de cada parte de la solución, MAGOS-ADMIN y el CMA. Se describe el diagrama de arquitectura, definiendo cada componente que la conforma y luego se muestran los diagramas de clases que hacen parte de la solución.. 5.3.1 MAGOS-ADMIN 5.3.1.1 Diagrama de Arquitectura de MAGOS con MAGOS-ADMIN MAGOS-ADMIN ofrece los servicios de administración de los recursos del grid. No se presenta la arquitectura interna del componente dado que no está compuesto por otro. Esta capa funciona como un orquestador que, según la solicitud que le entreguen, delega las operaciones a las otras capas MAGOS y, una vez obtiene las respectivas respuestas, las combina e informa el resultado de las operaciones y/o consultas. En la Figura 8 se puede observar cómo, esta capa, complementa a MAGOS y se comunica con las demás capas del middleware. En esta figura se listan los servicios ofrecidos por MAGOS-ADMIN en una anotación para facilitar si lectura y no congestionar el diagrama.. 28.

(29) Servicios de Administración - Monitoreo de nodos del grid - Agregar nodo al grid - Quitar nodo del grid. - Monitoreo de servicios - Añadir réplicas a servicio - Quitar réplicas a servicio - Desinstalar Servicios - Monitoreo de aplicaciones - Instalar Aplicación - Desinstalar Aplicación - Cambiar la configuración de las capas de MAGOS. Figura 8. Arquitectura general de MAGOS con MAGOS-ADMIN. 5.3.1.2 Diagramas de Clases Las clases de MAGOS-ADMIN están divididas en 4 paquetes: adaptadores, delegados, utilidades y objetos del mundo. Primero, las clases del paquete de adaptadores son el punto de entrada de la capa. Segundo, los delegados son las clases que se encargan de orquestar y delegar la responsabilidad a las demás capas de MAGOS y así cumplir con la funcionalidad de administración de los recursos. Tercero, las utilidades son clases que ofrecen un conjunto de operaciones que facilitan el trabajo de las demás clases. Por último, los objetos de negocio, estas clases representan las entidades del entorno MAGOS. La composición de los 3 primeros paquetes se muestra en la Figura 9 y seguido se encuentra una descripción más detallada de cada paquete. Más adelante se presentan los diagramas de clases de los objetos del mundo con sus respectivas descripciones.. 29.

(30) Figura 9. Diagrama de clases MAGOS-ADMIN - Adaptadores, Delegados y Utilidades. 5.3.1.2.1 Adaptadores Este paquete está conformado por IAdminAdapter y AdminAdapter (Ver Figura 9). IAdminAdapter define los servicios que ofrece MAGOS-ADMIN de forma flexible ya que estos reciben y retornan mensajes XML. AdminAdapter es la implementación de estos servicios. Esta encargada de transformar los mensajes XML de las solicitudes que recibe la capa en objetos del mundo que son entregados a los delegados para realizar la lógica de negocio. Igualmente, esta clase se encarga de transformar los objetos recibidos como resultado de la invocación de los delegados en mensajes XML de respuesta. 5.3.1.2.2 Delegados Este paquete es el encargado de orquestar la invocación de los servicios ofrecidos por las demás capas de MAGOS. Lo conforman IAdminDelegate y AdminDelegate. IAdminDelegate, al igual 30.

(31) que IAdminAdapter, define los servicios que ofrece MAGOS-ADMIN pero ya orientados a los objetos del mundo. La implementación AdminDelegate se encarga de orquestar y delegar la llamada de los servicios de acuerdo a la lógica de administración de los diferentes recursos del grid. Una vez recibida la respuesta de cada una de las llamadas, estas se combinan para formar la respuesta de toda la tarea de administración realizada y es entregada a los adaptadores para ser procesada y entregada a quien invocó el servicio. 5.3.1.2.3 Utilidades Este paquete está conformado por 3 clases que ofrecen operaciones de utilidad para los demás paquetes: XMLParser, StubUtil (Ver Figura 9) y Constants. Primero, XMLParser, es una colección de funcionalidades que permiten a los adaptadores analizar los mensajes XMLs y transformarlos en objetos del mundo. Esta clase se apoya en la tecnología Commons Digester de Apache la cual le permite hacer la manipulación de los mensajes XML. Segundo, StubUtil, esta clase expone operaciones que permiten a los delegados comunicarse con las demás capas de MAGOS. Por último, Constants, esta interfaz está compuesta por un conjunto de constantes usadas por las diferentes partes de la capa que representan rasgos de la lógica de negocio. 5.3.1.2.4 Objetos del Mundo Este paquete está formado por un conjunto de POJOs (Plain Old Java Object) que representan elementos de configuración o de comunicación entre los componentes del sistema. Si bien, no representan información básica de negocio, contienen información que corresponde a estructuras de información de acuerdo con patrones de estilo VO (Value Object). Se organiza en tres grupos: VOs generales, VOs de nodo y VOs de servicio. 5.3.1.2.4.1. VOs Generales. Estos objetos corresponden a los mensajes de entrada y salida de las solicitudes de servicios y consultas de la capa. La Figura 10 presenta a estos objetos.. Figura 10. Diagrama de clases de MAGOS-ADMIN - VOs Generales. 31.

(32) 5.3.1.2.4.2. VOs de Nodo. Este grupo contiene los objetos que conforman la información y las distintas partes de un nodo MAGOS. La describe el contenido de cada uno de estos objetos.. Figura 11. Diagrama de clases de MAGOS-ADMIN - VOs de Nodo. La información del nodo es representada por NodeInfo, esta clase contiene la información básica del mismo, como lo es su información de procesamiento y almacenamiento, un conjunto de propiedades de configuración del nodo, Configuration, la lista de fuentes de datos instaladas, DataSource, y la lista de servicios instalados, cuya representación se describe más adelante. Adicionalmente, dentro de este grupo se encuentra NewConfiguration, clase que representa una nueva configuración de una capa MAGOS. 5.3.1.2.4.3. VOs de Servicio. La Figura 12 muestra las clases que componen este grupo, el cual representa un servicio instalado en el grid. La clase Service contiene la información básica del servicio como lo es su identificador lógico, su nombre, su dueño, entre otras, sumado a eso, tiene los detalles de replicación del servicio, Replicate, y, en caso de ser un servicio tipo create, incluye las características de la fuente de datos que representa, BDArgument.. 32.

(33) Figura 12. Diagrama de clases de MAGOS-ADMIN - VOs de Servicio. 5.3.2 CMA (Cliente MAGOS-ADMIN) En esta sección se describe el diseño detallado de CMA, presentando su arquitectura y los diagramas de clases de sus componentes.. 5.3.2.1 Diagrama de Arquitectura de CMA CMA es una aplicación que interactúa con el administrador y desarrollador grid. La arquitectura de esta dividida en dos capas principales: GUI y Kernel. Por una parte, la capa GUI contiene todos los 33.

(34) elementos gráficos que se comunican con el usuario y aprovecha los servicios ofrecidos por el Kernel para cumplir con la funcionalidad del cliente. Por otra parte, está el Kernel, esta capa es la encargada de recibir las peticiones de la GUI, transformarlas y delegarlas a MAGOS-ADMIN. La Figura 13 presenta la arquitectura de CMA.. Figura 13. Diagrama de Arquitectura de CMA. 5.3.2.2 Diagramas de Clases Al igual que su arquitectura, las clases de CMA están divididas en dos grandes paquetes: GUI y Kernel. El paquete GUI contiene los elementos que permiten la visualización de la información y la interacción del usuario con los servicios de administración. Físicamente, las clases que componen este paquete se encuentran agrupadas por tipo de elemento gráfico que representan, pero lógicamente están divididas de acuerdo a los recursos que permiten administrar. Esta división es: general, configuración, nodo, aplicación y servicio (Ver Figura 13). Por otro lado, en el paquete Kernel se encuentran las clases que reciben las solicitudes de la interfaz gráfica, analizarlas,. 34.

(35) transformarlas en mensajes XML y enviarlas a MAGOS-ADMIN para que sean ejecutadas. A continuación se presentan los diagramas de clases de cada uno de estos paquetes mencionados.. 5.3.2.2.1 GUI Ȃ General Este paquete contiene la ventana principal que sirve como contenedor para todas las demás ventanas y diálogos que interactúan con el usuario. También contiene la ventana interna que permite el login a la aplicación y un listener que se encarga de capturar las acciones hechas por el usuario en la ventana principal y delega la respectiva funcionalidad a las respectivas ventanas de la aplicación. Las clases mencionadas se muestran en la Figura 14.. Figura 14. Diagrama de Clases de CMA - GUI General. 5.3.2.2.2 GUI Ȃ Configuración La Figura 15 presenta las clases contenidas en este paquete. Estas clases permiten la visualización y modificación de las propiedades de configuración de las diferentes capas de MAGOS.. Figura 15. Diagrama de clases de CMA - GUI Configuración. 35.

(36) 5.3.2.2.3 GUI Ȃ Nodo En este paquete se encuentra el conjunto de clases que permiten la administración de los nodos del grid. Permiten la visualización de la información de los nodos, la cual está compuesta por la información básica del nodo, como su ubicación y características de rendimiento, la configuración actual del nodo y la lista de fuentes de datos y servicios instaladas en el nodo, las clases de estos últimos se presentan en secciones contiguas. En la Figura 16 se presenta el diagrama de clases de este paquete.. Figura 16. Diagrama de clases de CMA - GUI Nodo. 5.3.2.2.4 GUI Ȃ Aplicación En la Figura 17 se presentan las clases que hacen posible la visualización de la información de las aplicaciones instaladas en MAGOS. Contiene las ventanas que permiten instalar una nueva aplicación y consultar el catálogo de las mismas.. 36.

(37) Figura 17. Diagrama de clases de CMA - GUI Aplicación. 5.3.2.2.5 GUI Ȃ Servicio Este paquete contiene las herramientas para permitir la visualización de los servicios instalados en MAGOS. Contiene las ventanas que permiten consultar el catálogo de servicio y mostrar la información detallada de los servicios, como lo es su información básica, replicas, dependencias, fuentes de datos usadas, entre otros. La Figura 18 presenta las clases que logran esta labor.. 37.

(38) Figura 18. Diagrama de clases de CMA - GUI Servicio. 5.3.2.2.6 Kernel Este paquete es el encargado de recibir todas las peticiones provenientes de la interfaz gráfica, analizarlas, transformarlas y enviarlas como solicitudes en mensajes XML a la capa MAGOS-ADMIN. En la Figura 19 se muestran las principales clases del Kernel.. 38.

(39) Figura 19. Diagrama de clases de CMA - Kernel. IMagosFacade define los servicios necesarios para cumplir con la lógica de negocio expuesta por MAGOS-ADMIN. La implementación MagosFacade emplea las diferentes utilidades para lograr comunicarse con la capa de administración y enviar a la GUI la información que desea ver el usuario de la aplicación. InstallAppUtils es una clase tomada del cliente de MAGOSAPPLICATION la cual permite procesar los descriptores de instalación de aplicaciones. [9] StubUtils presta operaciones que permiten que el CMA se comunique correctamente con MAGOS-ADMIN. XMLParser ofrece utilidades para analizar y transformar los mensajes obtenidos de la capa de administración en objetos del mundo de negocio. Por último, PropertyUtils es una utilidad que permite cargar y obtener la configuración del cliente.. 39.

(40) 6 Implementación 6.1. Descripción de la implementación. En esta sección se presenta como es el ambiente de desarrollo sobre el que se desenvuelve este trabajo.. 6.1.1 Ambiente de Desarrollo El ambiente de desarrollo de MAGOS-ADMIN y el CMA se divide en dos: implementación de la lógica de negocio e implementación de servicios y pruebas. Esta división se da por el hecho de que el entorno MAGOS está compuesto por máquinas virtuales. El desempeño de una máquina virtual es mucho menor que el de una maquina física por lo que hace menos productivo el desarrollo sobre este. Debido a esto, se decide realizar la implementación y compilación de la lógica de negocio en un entorno físico y, luego, trasladarla al entorno virtual donde se realiza la implementación de los servicios y las correspondientes pruebas. En los requerimientos de instalación se hace mención de todas las tecnologías usadas en el ambiente. A continuación se describen cada uno de los ambientes de desarrollo.. 6.1.1.1 Implementación de la Lógica de Negocio La implementación de la lógica de negocio consiste en el desarrollo y modificación de los diferentes núcleos de las capas de MAGOS y el desarrollo del CMA. Como se mencionó anteriormente, todas las capas del middleware están compuestas por dos partes: el núcleo o core de la capa y el servicio grid que contiene al primero. Este ambiente está sobre Windows (XP, Vista, 7) y se emplea el IDE (Integrated Development Environment) Eclipse 3.5. Se decide usar esta herramienta ya que está provista con varias utilidades que agilizan el desarrollo. Con ayuda del IDE se compilan los núcleos de las capas en archivos jar que se envían al ambiente virtual donde se puede probar su funcionamiento. Para el envío de estos archivos se elige utilizar un servidor FTP intermediario en donde, desde la ubicación física, se suben los archivos jar con ayuda del explorador de Windows y se descargan desde la máquina virtual por medio de un explorador web. Esto permite resolver asuntos de compatibilidad entre Windows y Linux. Por otro lado, el desarrollo de CMA se realiza íntegramente sobre este ambiente. Al estar completa la implementación del cliente se migra a las maquinas virtuales para que todas las partes de la solución queden en una única ubicación.. 6.1.1.2 Implementación de Servicios y Pruebas En este ambiente se desarrollan los servicios grid, los cuales exponen la funcionalidad de las capas MAGOS y son desplegados en el contenedor de GT4. Para la implementación estos se cuenta con 2 opciones: MAGE-GDT[15] y GT4IDE[16], ambos son plug-ins para Eclipse. En seguida se listan las características encontradas en cada uno de estos. ¾ MAGE-GDT . Funciona con Eclipse de versiones mayores o iguales a 3.5. . Requiere de una versión de java mayor o igual a 1.6 40.

(41) . No requiere de GT4 para su funcionamiento. . Se conocen, por documentación encontrada en [10], [11] y [12], que presenta varios bugs que dificultan su uso.. ¾ GT4IDE . Es un proyecto obsoleto. . Funciona, únicamente, sobre Eclipse 3. . Está compilado con java 1.5. . Requiere de una instalación completa de GT4 para su funcionamiento, es decir, solo funciona sobre Linux. . Se conocen, por documentación encontrada en [10], [11] y [12], que posee varios bugs que dificultan su uso.. La herramienta escogida es GT4IDE, se elige este plug-in dado que las demás capas MAGOS se encuentran implementadas con esta herramienta y se prefiere conservar uniformidad en sus distintos componentes. Otra razón de la elección, es que se tiene más documentación de su uso gracias a la primera iteración de MAGOS. Por otro lado, en las maquinas virtuales se cuenta con Linux y una instalación completa de GT4. En el apéndice 10 se describe la experiencia de trabajo con este plug-in y varios puntos a tener en cuenta a la hora de desarrollar usando esta herramienta.. 6.1.2 Desarrollo de los Casos de Uso A continuación se presentan los detalles relevantes de la implementación de cada uno de los casos de uso de este trabajo, en especial, a los consecuentes cambios realizados a las diferentes capas de MAGOS.. 6.1.2.1 Caso de Uso: Desinstalar Servicio Para la implementación de este caso de uso se cuenta con que MAGOS-SERVICE ya tiene desarrollada la implementación del servicio de desinstalación de un servicio, sin embargo, esta implementación, solo afecta la información de esa capa. Dado que existe información almacenada de los servicios en la capa MAGOS-APPLICATION es necesario realizar cambios en esta capa. Teniendo esto presente, se realizan las siguientes modificaciones en MAGOS-ADMIN: ¾ Se añade la operación undeployService al servicio grid expuesto por la capa, la cual invoca su homónimo del núcleo de la capa. ¾ Se agrega la operación undeployService al delegado de servicios, la cual se encarga de transformar la petición entregada como mensaje XML y realizar la lógica del caso de uso. ¾ Se crea la clase UndeployVO en el paquete co.edu.uniandes.application.vo. Esta clase representa una petición de desinstalación de un servicio o una aplicación.. 41.

(42) ¾ Se agrega la operación parseUndeployVO al delegado de servicios, este método permite analizar un mensaje XML recibido por la invocación de un servicio de desinstalación, ya sea de un servicio o de una aplicación ¾ Se agrega la operación serviceHasDependents en la clase Application. Este método recibe el identificador de un servicio y consulta en la base de datos de la capa si existen servicios que dependen del servicio dado. ¾ Se agrega la operación removeService en la clase Application. Este método se encarga de delegar la responsabilidad de desinstalar el servicio al DAO (Data Access Object) de aplicaciones. ¾ Se crea el método removeService en la interfaz ApplicationDAO y se implementa en ApplicationDAOImpl. Este método se encarga de remover la información del servicio de la base de datos de MAGOS-APPLICATION. ¾ Se crea el método deleteService en la clase ApplicationDAOImpl el cual se encarga de invocar a MAGOS-SERVICE y remover completamente el servicio de MAGOS.. 6.1.2.2 Caso de Uso: Desinstalar Aplicación ara este caso de uso se cuenta con lo implementado para el caso de uso de desinstalar un servicio. MAGOS-APPLICATION es quien posee toda la información de las aplicaciones y de los respectivos servicios que la componen. Dado esto, se hacen los siguientes cambios a la capa: ¾ Se añade la operación undeployApplication al servicio grid expuesto por la capa, la cual invoca su homónimo del núcleo de la capa. ¾ Se agrega la operación undeployApplication al delegado de servicios, la cual se encarga de transformar la petición entregada como mensaje XML y realizar la lógica del caso de uso. ¾ Se agrega la operación removeApplication en la clase Application. Este método se encarga de delegar la responsabilidad de desinstalar la aplicación al DAO de Aplicaciones. ¾ Se crea el método remove en la interfaz ApplicationDAO y se implementa en ApplicationDAOImpl. Este método se encarga de remover la información de la aplicación y sus respectivos servicios de la base de datos de MAGOS-APPLICATION. También se encarga de realizar la invocación de MAGOS-SERVICE para remover los servicios que la componen. Una aplicación MAGOS puede estar compuesta por varios servicios y estos servicios pueden tener diferentes alcances, es decir, algunos son públicos, otros autorizados y otros privados (Ver Figura 2). En MAGOS-APPLICATION, la descripción de la composición, requerimientos y propietarios esta asociada con la aplicación y no con sus servicios. La política de desinstalación de una aplicación definida en este trabajo es la siguiente: si la aplicación está compuesta por servicios no privados, el usuario del servicio de administración debe decidir si remover estos servicios no privados o dejarlos en el grid a disposición de otras aplicaciones. Accidentalmente, como consecuencia del segundo caso, los servicios que no se desinstalan quedan huérfanos. Estos servicios son aquellos que no pertenecen a ninguna aplicación, es decir, aquellos que se dejaron instalados en el grid por decisión del usuario cuando 42.

(43) desinstaló la aplicación que los contenía. Estos servicios, al no estar contenidos en una aplicación, pierden la información de quien es su dueño y cuáles son sus requerimientos de memoria y procesamiento. La falta de esta información causa que estos servicios puedan ser consultados únicamente por el administrador y, por ende, este usuario es el único que puede desinstalarlos. Adicionalmente, estos servicios pierden las propiedades de aumentar o disminuir su número de replicas. Con CMA, el administrador, puede identificación y desinstalar, si es necesario, estos servicios.. 6.1.2.3 Caso de Uso: Monitorear Servicios Para este caso de uso se requiere de la participación de las capas MAGOS-APPLICATION y MAGOSSERVICE dado que estas contienen la información de los servicios. MAGOS-APPLICATION hace manejo del catálogo de servicios pero no ofrece medios de consulta a estos. Por otro lado, MAGOS-SERVICE ofrece únicamente la consulta de servicios por identificador, en otras palabras, solo se puede consultar un servicio a la vez. De acuerdo con esto se realizan los siguientes cambios a las capas. Cambios realizados a MAGOS-APPLICATION: ¾ Se agrega el método findServices al servicio grid expuesto por la capa. ¾ Se agrega el método findServices al delegado de servicios. ¾ Se crea el método findServices al catálogo de MAGOS-APPLICATION (Ver Figura 4). ¾ Se crea la operación processService al catálogo, operación que verifica si un servicio es candidato a ser incluido en el resultado de una consulta. Las razones por las que un servicio puede no pertenecer a una respuesta están dadas por su alcance, si el servicio es privado solo puede ser visto por el administrador o el dueño del servicio, si es autorizado pueden verlo, además, aquellos usuarios autorizados. No se realizan modificaciones a la capa MAGOS-SERVICE dado que se puede obtener la información necesaria de los servicios mediante la consulta por identificador. Esto se permite ya que MAGOSADMIN se encarga de obtener la información de ambas capas y combinarla para dar las características completas de los servicios.. 6.1.2.4 Caso de Uso: Monitorear Nodos La lógica de este caso de uso se separa en dos etapas: Primero, se ofrece un servicio de consulta de los nodos que componen el grid y, luego, se ofrece un servicio de consulta de la información completa de un nodo. Para la implementación del primer servicio se cuenta con que la capa MAGOS-SERVICE posee una operación que retorna el conjunto de direcciones IP de los nodos que componen el grid. Sin embargo, dicha operación no se expone como un servicio, es un método privado para uso propio de la capa. La acción que se toma es modificar la capa MAGOS-SERVICE para que exponga esta operación dentro de los servicios que ofrece para que pueda ser usado por terceros. A continuación se presenta la lista de cambios hechos a la capa MAGOS-SERVICE, desde el más externo al más interno:. 43.