Repositorio Institucional de Documentos

I “Formalización y desarrollo de un workflow de inferencia filogenética basado en SaaS” Resumen Este trabajo aborda la formalización y desarrollo de un sistema de flujo de trabajo de inferencia filogenética empleando el paradigma de Software como Servicio (SaaS). Dicho sistema se ha configurado y desplegado sobre un entorno distribuido. En primer lugar se ha llevado a cabo un estudio sobre entornos similares planteados en la literatura de divulgación científica. Este estudio contiene una descripción de la situación reciente de sistemas similares al planteado que se están desarrollando en la actualidad. Finalizado el estudio previo, se ha llevado a cabo el análisis y posterior adaptación de un sistema de inferencia filogenética existente. El análisis previo recoge la composición y el funcionamiento del flujo de trabajo con el objetivo de conocer el tratamiento de la entrada y la salida del sistema. No obstante, no se plantea la necesidad de conocer los detalles del procesamiento que implementa cada componente en concreto. A continuación, se ha realizado un análisis para identificar y definir los usuarios finales, además de documentar y modelar los requisitos que debía satisfacer el sistema. Este análisis se ha realizado empleando técnicas de Ingeniería del Software y en especial aquellas relacionadas con la Ingeniería de Requisitos. Una vez documentados y modelados los requisitos funcionales y no funcionales del sistema se ha realizado el diseño de la arquitectura interna de cada uno de los componentes que constituyen el sistema. Finalizada la fase de diseño, se ha implementado cada componente individual del sistema definiendo una interfaz de entrada que permite exponer sus funcionalidades como un servicio Web. Cada componente interactúa con el sistema previo como una caja negra, ejecutando los procesos ordenadamente y capturando la salida. Seguidamente, se ha desarrollado un sistema que implementa un flujo de trabajo completo para la inferencia filogenética de un árbol evolutivo sobre un conjunto de secuencias de ADN mitocondrial humano y se ha expuesto dicho sistema como un servicio Web independiente, integrando todos los componentes previos. Este sistema contiene la lógica de negocio relacionada con la forma de constituir el flujo de trabajo completo para distintos tipos de secuencias biológicas. Ambos sistemas han sido desplegados en la nube como alternativa para evaluar posibles beneficios en cuanto a escalabilidad, disposición dinámica de recursos, alta disponibilidad de los servicios y reducción de costes económicos. También se ha empleado un sistema de almacenamiento de información externo en la nube para almacenar tanto las soluciones parciales como los resultados finales durante un periodo de tiempo, permitiendo al usuario el acceso a dichos resultados a través de Internet. Por último, se ha realizado un sistema de toma de decisiones mediante ficheros de log. Así se ha planteado un modelo de mejora sencillo basado en el entrenamiento de árboles de decisión. II III Índice general Resumen .................................................................................................................................... I 1. Introducción ...................................................................................................................... 1 1.1. Contexto del proyecto ......................................................................................................................... 1 1.2. Objetivos ............................................................................................................................................. 2 1.3. Metodología........................................................................................................................................ 2 1.4. Estructura de la memoria ..................................................................................................................... 3 2. Glosario ............................................................................................................................. 4 3. Estado del arte ................................................................................................................... 5 4. Análisis .............................................................................................................................. 8 4.1. Sistema previo ......................................................................................................................................... 8 4.1.1. Descripción ....................................................................................................................................... 8 4.2. Análisis del sistema ............................................................................................................................... 10 4.2.1. Usuarios finales .............................................................................................................................. 10 4.2.2. Stakeholders ................................................................................................................................... 10 4.2.3. Requisitos ....................................................................................................................................... 11 4.2.4. Casos de uso ................................................................................................................................... 12 4.2.5. Propuesta de solución ..................................................................................................................... 14 5. Diseño de la solución ...................................................................................................... 15 5.1. Paradigma SaaS ..................................................................................................................................... 15 5.2. Diseño de cada componente que constituye el flujo de trabajo ............................................................. 16 5.2.1. Presentación primaria ..................................................................................................................... 17 5.2.2. Relaciones y sus propiedades ......................................................................................................... 17 5.3. Diseño del componente que representa el flujo de trabajo .................................................................... 19 5.3.1. Presentación primaria ..................................................................................................................... 19 5.3.2. Relaciones y sus propiedades ......................................................................................................... 19 5.4. Arquitectura global del sistema ............................................................................................................. 20 5.5. Interfaz pública de cada servicio ........................................................................................................... 21 6. Implementación ............................................................................................................... 22 6.1. Software y tecnologías empleadas......................................................................................................... 22 6.2. Implementación de cada componente del flujo de trabajo .................................................................... 23 6.2.1. Implementación de la capa de negocio ........................................................................................... 23 6.2.2. Implementación sistema de almacenamiento externo .................................................................... 24 6.2.3. Implementación de los sistemas de compresión y notificación ..................................................... 25 6.2.4. Implementación del encapsulador e interfaz .................................................................................. 25 6.2.5. Aspectos interesantes de la implementación .................................................................................. 25 IV 6.3. Implementación del sistema flujo de trabajo ........................................................................................ 26 7. Despliegue y evaluación ................................................................................................. 27 7.1. Explicación de una traza completa de despliegue ................................................................................ 27 7.2. Verificación y validación del sistema ................................................................................................... 28 7.3. Resultados de la evaluación .................................................................................................................. 29 7.4. Sistema de toma de decisiones ............................................................................................................. 30 8. Gestión del proyecto y conclusiones .............................................................................. 31 8.1. Gestión del proyecto ............................................................................................................................. 31 8.1.1. Gestión de configuraciones ............................................................................................................ 31 8.1.2. Diagrama de Gantt ......................................................................................................................... 32 8.1.3. Coste total del proyecto ................................................................................................................. 33 8.2. Conclusiones ......................................................................................................................................... 34 Bibliografía ............................................................................................................................ 35 Anexo I. Análisis ................................................................................................................... 37 1. Formatos de entrada ......................................................................................................................... 37 2. Casos de uso .................................................................................................................................... 38 3. Descripción de los casos de uso ....................................................................................................... 39 Anexo II. Diseño de la solución ............................................................................................ 53 1. API REST de cada componente que constituye el flujo de trabajo ................................................. 53 2. Interfaz de cada servicio que forma parte de la capa middleware ................................................... 61 3. API REST componente que representa el flujo de trabajo .............................................................. 64 4. Comunicación: estándares de intercambio ...................................................................................... 66 Anexo III. Implementación .................................................................................................... 69 1. Mapa de errores ............................................................................................................................... 69 Anexo IV. Despliegue y evaluación ...................................................................................... 71 1. Evaluación del sistema .................................................................................................................... 71 2. Implementación de un sistema de toma de decisiones .................................................................... 73 Anexo V. Manual de usuario ................................................................................................. 77 1. Identificación del servicio................................................................................................................ 77 2. Servicios individuales ...................................................................................................................... 77 3. Servicio para un flujo de trabajo completo ...................................................................................... 79 1 1. Introducción Este capítulo contiene una introducción con el contexto y los objetivos principales del proyecto, la metodología empleada y, por último, se detalla la estructura del documento. 1.1. Contexto del proyecto La filogenética es la ciencia encargada del estudio y clasificación de la relación evolutiva entre organismos. En la actualidad los sistemas de inferencia filogenética tienen gran interés, ya que permiten no sólo hacer estudios evolutivos del individuo sobre poblaciones sino también tratar cuestiones más especificas como la detección de enfermedades raras a partir de secuencias de ADN mitocondrial humano. Concretamente, la detección de enfermedades se basa en la ubicación de secuencias de ADN en el árbol inferido. Recientemente se está abordando este tipo de análisis tan costosos computacionales aprovechando el avance de las tecnologías en cuanto al aumento de prestaciones [1]. Como punto de partida, se dispone de un sistema de inferencia filogenética previo desarrollado por el investigador Jorge Álvarez durante la realización de sus estudios de máster. Este sistema denominado PhyloFlow [2] permite el estudio de modelos evolutivos en alineamientos de secuencias de ADN mitocondrial. El sistema PhyloFlow [2] emplea métodos de selección de modelos evolutivos y de construcción de superárboles. Este sistema se perfila en la Figura 1, y se detallará más adelante en la sección 4.1.1. del documento (pág. 8). Figura 1. Sistema de inferencia filogenética mediante flujos de trabajo El sistema PhyloFlow [2] está desarrollado mediante flujos de trabajo que permiten una visión conceptualmente sencilla del diseño del sistema. El flujo de trabajo está formado por cuatro componentes que permiten la descarga, procesamiento biológico y evaluación de secuencias además de la generación de superárboles. Cada componente del flujo de trabajo es independiente del resto, y la ejecución de un flujo completo de trabajo implica la ejecución ordenada de todos los componentes que forman parte del sistema. Además este sistema emplea la herramienta HTCondor [3] basada también en flujos de trabajo que permite la distribución de los trabajos en distintas máquinas. Sin embargo esta solución tiene asociados una serie de problemas. En primer lugar, es un sistema acoplado en el que cada uno de los componentes depende un planificador de tareas desarrollado con la herramienta DAGMan [4] que establece las dependencias entre cada uno de los trabajos. En segundo lugar, el sistema no está distribuido y, por tanto, únicamente se puede ejecutar en una máquina computacionalmente potente que albergue la instalación del sistema. Además es un sistema que no es accesible remotamente y requiere la instalación del mismo para su utilización. Otro problema encontrado se debe a que la interfaz de entrada de cada uno de los componentes del flujo de trabajo no está suficientemente documentada. 2 Este trabajo aborda un análisis pormenorizado de las características detalladas del sistema PhyloFlow [2], sin profundizar en aspectos metodológicos y procedurales del procesamiento biológico realizado por el sistema para realizar el análisis filogenético. El objetivo del trabajo es desarrollar un sistema empleando el paradigma SaaS para obtener una solución que permite desplegar el sistema en un entorno distribuido reduciendo el acoplamiento y dando acceso al sistema de forma remota a través de un servicio Web. El entorno distribuido sobre el cual se ha desplegado el sistema es una plataforma de computación escalable en la nube que permite el aprovisionamiento de recursos dinámicamente. 1.2. Objetivos El objetivo principal del proyecto ha sido el análisis y desarrollo de una colección de servicios basados en tecnologías Web para la inferencia de árboles filogenéticos con la información biológica bajo el paradigma de Software como Servicio (SaaS). Los objetivos concretos plantean la búsqueda de entornos similares en la literatura científica, el análisis del sistema previo y los requisitos de una solución SaaS, el modelado bajo el paradigma considerado y finalmente la implementación y evaluación de un prototipo del sistema mediante un flujo de trabajo. Desde el primer momento se tomó la decisión de emplear un modelo basado en SaaS para la publicación de dichos servicios y emplear dicho modelo para conseguir una solución escalable que permite su aplicación en un entorno distribuido. El proyecto contempla también el desarrollo y despliegue del sistema en un entorno distribuido. Concretamente, se optó por emplear una plataforma de computación elástica en la nube que permita aumentar y disminuir los recursos dinámicamente para adaptarse a las exigencias computacionales. Además se ha llevado a cabo la validación del sistema a partir de una batería de pruebas automáticas desarrolladas durante el proyecto. Uno de los objetivos principales era validar el correcto funcionamiento del sistema en un entorno distribuido y evaluar las prestaciones del mismo para determinar el equilibrio entre el coste temporal y el coste económico. Por último se ha desarrollado un sistema de ayuda a la toma de decisiones en base a los ficheros de log obtenidos durante la validación y evaluación del sistema. De este modo se ha planteado un modelo de mejora sencillo basado en aprendizaje que facilita la elaboración de estrategias sobre el tipo de plataformas computacionales en las cuáles desplegar el sistema. 1.3. Metodología La metodología utilizada establece una organización en fases del proyecto y sus correspondientes hitos facilitando su seguimiento, identificación de carencias y retroalimentación del desarrollo, según un modelo de ciclo de desarrollo en cascada. Se ha seguido un flujo de trabajo basado en las fases principales que se consideran en Ingeniería del Software haciendo especial hincapié en aquellas relacionadas con la Ingeniería de Requisitos. Esto ha proporcionado como resultado un análisis profundo de las dependencias, características, necesidades y limitaciones de la solución. 3 1.4. Estructura de la memoria La memoria está estructurada en nueves capítulos que corresponden esencialmente a las fases principales del proyecto además de la gestión del proyecto y la bibliografía del trabajo. El segundo capítulo (pág. 4) contiene un glosario con la definición de aquellos conceptos más importantes relacionados con el trabajo. El tercer capítulo (pág. 5) se corresponde al estado del arte. Este capítulo contiene la información más relevante encontrada en la literatura científica con planteamientos de entornos similares al desarrollado. El capítulo de análisis (pág. 8) contiene la información recogida del análisis del sistema previo. Esta sección contiene una breve descripción del sistema que permite comprender suficientemente su funcionamiento y la documentación que forma parte del análisis del sistema que ha sido desarrollado. Finalmente, contiene la descripción de los usuarios finales del sistema, así como la documentación y modelado en casos de uso de los requisitos funcionales y no funcionales del sistema. En el capítulo de diseño de la solución (pág. 15) se describe el paradigma SaaS y se documenta el diseño de la solución propuesta. La solución propuesta contiene la descripción, relaciones entre elementos y los diagramas de la arquitectura diseñada. El sexto capítulo (pág.22) contiene los aspectos más interesantes de la implementación del sistema y las decisiones de implementación que se han tomado para el desarrollo del proyecto. El capítulo de despliegue y evaluación (pág. 27) explica la configuración y despliegue del sistema en un entorno distribuido, la nube comercial de Amazon Web Services (AWS). Además se documenta el proceso de validación del sistema y la evaluación del sistema y los resultados obtenidos. En el octavo capítulo (pág. 31) contiene la documentación relacionada con la gestión y planificación del proyecto. Se explica la metodología utilizada y se muestra la planificación del proyecto a través de un diagrama de Gantt. Finalmente se exponen las conclusiones finales del proyecto. Por último, se encuentran las secciones de bibliografía (pág. 35) y de anexos (pág. 37). 10 4.2. Análisis del sistema Una vez realizado el estudio del sistema previo, se ha realizado un análisis sobre el sistema. Este análisis contiene la descripción de los usuarios finales y los grupos de interés o stakeholders del sistema, la documentación de los requisitos funcionales y no funcionales que debe satisfacer el sistema y el modelado de estos en casos de uso. 4.2.1. Usuarios finales Los usuarios finales del sistema son aquellos usuarios que van a interactuar directamente con él. Por tanto, se han descrito tres tipos de usuarios finales posibles:  Usuario administrador: es aquel usuario que realiza de intermediario entre el sistema y el biólogo que desea obtener los resultados para proceder a realizar un análisis exhaustivo de los mismos. Este tipo de usuario está familiarizado con el dominio tecnológico, pero por el contrario puede no tener nociones del dominio de la aplicación.  Biólogo: es aquel usuario que se encarga de proponer un experimento, determinando las herramientas a usar en la ejecución del flujo de trabajo para luego interpretar los resultados obtenidos por el sistema en base a sus conocimientos sobre el dominio de la aplicación.  Otros sistemas externos o internos que integren componentes del flujo de trabajo. 4.2.2. Stakeholders El grupo de interés o stakeholders son aquellas personas, sistemas o documentación que están estrechamente relacionados con el sistema desarrollado pero puede que no sean los propios usuarios finales del mismo. Los stakeholders pueden proporcionan información respecto del sistema a desarrollar o interactuar directamente o indirectamente con él. Los stakeholders definidos para el sistema son:  Usuario finales  Sistema filogenético existente  Documentación del sistema previo 11 4.2.3. Requisitos En esta sección se han seleccionado aquellos requisitos funcionales y no funcionales que debe satisfacer el sistema. La Tabla 1 contiene numerados los requisitos funcionales y la Tabla 2 contiene los requisitos no funcionales del sistema. Requisitos funcionales RF-1 El sistema debe ofrecer una colección de servicios al usuario que permitan el análisis del ADN mitocondrial humano. RF-2 El sistema debe ofrecer un servicio de descarga de secuencias de ADN mitocondrial humano. RF-3 El sistema debe ofrecer un servicio de procesamiento de secuencias de ADN mitocondrial humano. RF-4 El sistema debe ofrecer un servicio de evaluación y construcción de soluciones parciales. RF-5 El sistema debe ofrecer un servicio de consenso e integración de soluciones parciales. RF-6 El sistema debe ofrecer un servicio de construcción de un único árbol filogenético a partir de soluciones parciales. RF-7 El sistema debe ofrecer un servicio que realice un flujo de trabajo completo que integre el resto de servicios ofrecidos. RF-8 El sistema debe ser capaz de almacenar resultados intermedios. RF-9 El sistema debe ser capaz de notificar al usuario los resultados generados como respuesta a su petición. RF-10 El sistema debe capturar la salida de error del sistema de inferencia filogenética existente. Tabla 1. Requisitos funcionales del sistema Requisitos no funcionales RNF-1 El sistema debe integrar el sistema de inferencia filogenética existente. RNF-2 El sistema debe ser capaz de interoperar con el sistema de inferencia filogenética existente. RNF-3 El sistema debe almacenar en un sistema de almacenamiento externo los resultados intermedios que permita el acceso a los mismos. RNF-4 El sistema debe emplear un protocolo de comunicación asíncrono debido al coste computacional derivado del análisis del ADN mitocondrial. RNF-4 El sistema debe notificar a los usuarios empleando el protocolo SMTP para el envío de correos electrónicos. RNF-5 El sistema será diseñado desde el punto de vista SaaS. RNF-6 El sistema debe definir y emplear un formato de intercambio estándar. RNF-7 El sistema debe ser robusto y realizar el tratamiento de excepciones pertinentes. RNF-8 El sistema debe ser portable y flexible. Tabla 2. Requisitos no funcionales del sistema 12 4.2.4. Casos de uso Esta sección contiene el modelado de los requisitos descritos anteriormente en casos de uso. Los casos de uso dan una visión gráfica de los pasos e interacciones entre los actores del sistema y el propio sistema para lograr un objetivo. Los actores del sistema pueden ser personas humanos u otros sistemas externos. Caso de uso: nivel 0 Los casos de uso de nivel cero sirven para mostrar las funcionalidades básicas del sistema y los pasos que se han de seguir para obtener un objetivo concreto. La Figura 4 muestra el modelado en casos de uso de nivel 0 del sistema. Figura 4. Diagrama de Casos de uso nivel 0 Este modelo muestra cinco casos de uso independientes entre sí que se corresponden a las principales funcionalidades del sistema PhyloFlow [2]. El caso de uso Download DB permite al actor principal ofrecer descargar secuencias de ADN mitocondrial humano de la base de datos de GenBank o recuperar bases de datos de secuencias de ADN disponibles. El caso de uso denominado Map-reduce permite al actor principal realizar un procesamiento biológico sobre secuencias de ADN. El caso de uso denominado Evaluation permite al actor principal realizar una evaluación de modelos evolutivos sobre secuencias de ADN y construcción de soluciones parciales. El caso de uso denominado Consensus permite al actor principal realizar una fase de consenso e integración de soluciones parciales. El caso de uso denominado Supertree permite al actor principal la construcción de un superárbol filogenético a partir de resultados parciales. El caso de uso denominado hmtDNAWorfklow es el encargado de realizar un flujo de trabajo completo para datos de secuencia de ADN mitocondrial humano, por tanto, ha de incluir al resto de casos de uso para llevar a cabo el análisis pertinente. El actor principal del sistema puede interactuar con los seis casos de 13 usos, debido a que puede realizar un flujo de trabajo completo o realizar fases individuales e independientes. La sección número 3 de Anexo I. Análisis (pág. 38) contiene la descripción formal de los casos de uso. Casos de uso: nivel 1 Los casos de uso de nivel uno sirven para mostrar las funcionalidades básicas del sistema y los funcionalidades subyacentes que emplean. La Figura 5 muestra el modelado en casos de uso de nivel 1 del sistema para los biólogos. La sección número 2 de Anexo I. Análisis (pág. 38) contiene los casos de uso centrados en el usuario administrador. Figura 5. Diagrama de Casos de uso nivel 1 para el usuario biólogo * Por simplificar el diagrama se han omitido el resto de casos de uso de los subsistemas Fetch Sequences, Sequences Processing y Sequecences Evaluation. Éstos y sus relaciones son idénticos a las mostradas en el sistema que denominado Supertree Building. A diferencia del diagrama de casos de uso de nivel cero, el diagrama de casos de uso de nivel uno está formado por cinco subsistemas. El subsistema denominado Workflow System es el encargado de establecer el flujo de trabajo integrando el resto de subsistemas, los cuáles equivalen a cada uno de los componentes del sistema PhyloFlow [2]. El actor principal puede interactuar con cualquiera de ellos, por tanto, no sólo puede obtener el resultado final de un flujo de trabajo completo, sino que también puede obtener soluciones parciales interactuando con cada componente de forma individual. Cada uno de los componentes está formado por uno o más casos de uso que representan la funcionalidad que desempeña dentro del flujo de trabajo, y tres casos de uso más que representan funcionalidades adicionales. El caso de uso denominado Business Logic Service representa el servicio que provee la 14 funcionalidad básica de la lógica de negocio. El caso de uso Store Service representa el servicio que provee funcionalidades relacionadas con el almacenamiento y descarga de soluciones parciales y finales. Por último, el caso de uso nombrado como Notification Service sería el encargado de proveer la funcionalidad para notificar al actor los resultados obtenidos. En el subsistema Workflow System, el caso de uso principal es el denominado hmtDNAWorkflow. Este caso de uso emplea el denominado como Scheduler. Este último representa la funcionalidad encargada de planificar los trabajos del flujo y solicitarlos a cada componente concreto. Por tanto, incluye los casos de uso que representas las funcionalidades básicas del resto de subsistemas. Por último, el caso de uso MailBox Service representa la funcionalidad asociada a la recepción de los resultados notificados por el resto de subsistemas. Cada uno de los subsistemas se ofrece como un servicio independiente bajo la visión SaaS. Por tanto, cada subsistema ofrece sus funcionalidades como un servicio a cada uno de los actores del diagrama. Esto permite que los subsistemas se encuentren totalmente distribuidos reduciendo el acoplamiento entre los mismos. El actor accederá a cada unos de los servicios ofrecidos a través de Internet. La sección número 3 de Anexo I. Análisis (pág. 38) contiene la descripción formal de los casos de uso. 4.2.5. Propuesta de solución La solución propuesta consiste en la división del sistema PhyloFlow [2] en cinco subsistemas independientes y desacoplados. Cuatro de ellos representan los componentes individuales del flujo de trabajo. El último es el encargado de realizar el flujo de trabajo completo integrando los anteriores ordenadamente. Cada una de las funcionalidades de los subsistemas será ofrecida como un servicio bajo el punto de vista SaaS. En concreto, cada funcionalidad será ofrecida como un servicio Web accesible a través de internet. Esta solución permite realizar un flujo completo de inferencia filogenética o realizar etapas individuales del proceso que combinadas puedan dar lugar a nuevos flujos de trabajo. Como cada una de las funcionalidades se ofrece como un servicio no sólo permite acceder al usuario final a ellas sino que cualquier otro sistema externo puedan integrar dichas funcionalidades en su dominio de aplicación. La Figura 6 muestra gráficamente la solución propuesta. Figura 6. Distribución de los subsistemas que contienen los casos de uso Debido a que los componentes se encuentran totalmente distribuidos se puede permitir el despliegue del sistema en un entorno distribuido. Esta solución permite que el sistema sea escalable y robusto, ya que la caída de un servicio no afectaría al resto, a excepción del que integra todos para realizar el flujo de trabajo completo. Por tanto, todos los servicios ofrecen un punto de entrada al subsistema que representan. 15 5. Diseño de la solución Este capítulo contiene la documentación generada durante la fase de diseño del sistema. Esta fase del trabajo se ha realizado a partir de los objetivos que debe cubrir el sistema definidos en la fase de análisis. El diseño se ha realizado bajo el paradigma de Software como Servicio con lo que el soporte lógico y los datos se han de alojar en el servidor. El objetivo principal ha sido realizar un diseño flexible que abstrajese mediante interfaces la implementación concreta de cada uno de los servicios, y permitiendo que cada servicio interno pueda tener una o más implementaciones concretas del mismo. Por tanto, el mayor esfuerzo invertido durante el diseño del sistema se ha destinado a realizar una solución lo más abstracta posible que dotará al sistema de flexibilidad y facilitará la reutilización de componentes. 5.1. Paradigma SaaS El paradigma Software as a Service (SaaS) propone un modelo en el que el software es ofertado como servicio al usuario final. El software está albergado en un servidor y los usuarios acceden al software empleando un navegador Web [15]. La Figura 7 muestra la arquitectura de un sistema bajo la visión Saas. Figura 7. Vista de alto nivel de un componente del sistema bajo el paradigma SaaS La figura anterior muestra las tres capas principales que componen el diseño una solución basada en SaaS. La capa denominada Interface es aquella capa del sistema que atiende las peticiones de los clientes que envían a través de la API ofrecida por la misma. La siguiente capa es la denominada Wrapper, debido a que encapsula el acceso a la lógica de negocio. Esta capa es la responsable de encapsular la comunicación entre las peticiones entrantes y las reglas de negocio del sistema. La tercera y última capa denominada Business Logic es la capa de negocio, es decir, aquella capa que contiene toda la lógica y reglas de negocio del sistema. El Instituto Nacional de Estándares y Tecnologías (NIST) define la computación en la nube a través de tres modelo de servicios: Software como Servicio (SaaS), Plataforma como Servicio (PaaS) e Infraestructura como Servicio (IaaS) [16]. 16 Con el modelo SaaS, los proveedores ofrecen aplicaciones que están desplegadas en una plataforma en la nube. El software se ejecuta en los servidores de la nube contratados por la empresa proveedora del servicio. Por tanto, si se detecta un error en el software solucionarlo en el servidor puede ser más sencillo y rápido, en lugar de distribuir y actualizarlo a todos los clientes [15]. Existen varios ejemplos de SaaS. Por ejemplo, Google ofrece varias aplicaciones Web, como Gmail y Google Docs. Ambas aplicaciones son ofrecidas como servicios online. Los beneficios principales que aporta el modelo SaaS al cliente final son reducción de costes y tiempos. En el modelo SaaS al contrario que en modelos tradicionales, el cliente no necesita contratar hardware especifico donde albergar el software contratado ya que este reside en los servidores de la empresa proveedora, por tanto, permite desplegar las aplicaciones de forma rápida y sencilla sin la necesidad de instalar ni configurar el software contratado [17]. Además el mantenimiento como las actualizaciones del software será gestionado por parte del proveedor de servicios. En general, el software desarrollado para ser implementado como un servicio es más eficiente y provee de mejor funcionalidad y flexibilidad [16]. El modelo SaaS especifica aplicaciones que normalmente son diseñadas para operar en centros de datos distribuidos. Tienen la ventaja de escalar tanto el servidor como el ancho de banda para proveer acceso a más usuarios, aumentar el rendimiento y el tratamiento de información. No existe la necesidad de rediseñar el software o de desplegarlo de nuevo. Esto significa que se tiene el mismo servicio independientemente del número de usuarios y no se debe añadir más hardware o sistemas, ya que el proveedor de la nube proporcionará dinámicamente la escala que necesites [16]. Por tanto, los principales beneficios que aporta SaaS respecto a otros modelos son seguridad, escalabilidad, flexibilidad, disponibilidad y reducción de costes económicos y temporales. En el dominio de la aplicación se han tenido en cuenta los aspectos relacionados con la escalabilidad y flexibilidad para adaptarse al número de usuarios, aumentando o disminuyendo el número de recursos para ofrecer el servicio. También esta solución reduce costes temporales al usuario final, ya que no debe instalar ni configurar el sistema. El sistema ya se encuentra desplegado y accesible en una plataforma de computación en la nube. Los centros de datos SaaS hoy en día garantizan que son altamente disponibles, esto implica generalmente que el proveedor tenga una cierta tolerancia a fallos o recuperación de errores para garantizar la disponibilidad en caso de producirse cualquier desastre. La elección de Amazon EC2 nos asegura la disponibilidad del servicio aproximadamente el 99,9999% del tiempo. 5.2. Diseño de cada componente que constituye el flujo de trabajo En primer lugar se ha llevado a cabo un diseño de alto nivel de cómo debía ser la estructura del sistema. Se ha tomado la decisión de realizar un diseño por capas, de tal forma que las capas del sistema se encargan de regir el comportamiento y dependencias del mismo. El sistema está formado por tres capas fundamentales, y cada una de ellas depende únicamente de la capa inmediatamente inferior. Mediante la arquitectura por capas se obtiene un diseño más flexible y reusable, ya que los cambios internos de una capa sólo afectan a la propia capa, y el número de dependencias se disminuye. 17 5.2.1. Presentación primaria La presentación primaria de los componentes que constituyen el flujo de trabajo se corresponde a la Figura 7 mostrada anteriormente que se corresponde al diseño de arquitectura de un sistema basado en SaaS. El diseño de la solución está formado por tres capas independientes. La capa denominada Interface es aquella capa de cada uno de los componentes encargada de atender las peticiones entrantes a través de la API ofrecida. La siguiente capa es la denominada Wrapper, debido a que encapsula el acceso a la lógica de negocio. Esta capa es la responsable de encapsular la comunicación entre las peticiones entrantes y las reglas de negocio del sistema. En el contexto de implementación, será la capa que encapsule toda la funcionalidad asociada al lanzamiento de los scripts de cada una de los componentes del sistema inferencia filogenética y se encargue del tratamiento de las salidas generadas, así como de la monitorización necesaria. La tercera y última capa denominada Business Logic es la capa de negocio, es decir, aquella capa que contiene toda la lógica y reglas de negocio del sistema. En este dominio de aplicación esta capa se corresponde con el sistema PhyloFlow [2], debido a que él posee todas las funcionalidades necesarias para la realización del análisis de filogenias de ADN mitocondrial humano. Si se aumenta el nivel de detalle, se puede observar la aparición de una capa middleware compuesta por varios elementos que ofrecen distintos servicios a través de sus interfaces. Esta capa añade un nivel más de indirección entre la capa Wrapper y la capa que contiene la lógica de negocio. La capa Wrapper se comunica con cada uno de ellos dotando al sistema de una funcionalidad completa en base a las funcionalidades ofrecidas por cada uno de los servicios. Por tanto, será el elemento representado como Business Logic Service el encargado de encapsular todas las llamas al sistema de inferencia filogenética. La Figura 8 muestra el diseño del sistema a un nivel de abstracción inferior. Figura 8. Vista con las capas de diseño de un componente genérico del flujo de trabajo 5.2.2. Relaciones y sus propiedades La capa Interface se encarga de ofrecer los métodos del servicio que se pueden invocar remotamente. Para ello se define y publica una API que indica las reglas para la invocación del servicio. Cada vez que recibe una petición, la atiende y procesa. Para ello emplea el servicio denominado como XMLService que se encarga de validar la petición, si es válida la capa invocará a la capa inferior. Dicha API está explicada y detallada en la sección número 1 de Anexo II. Diseño de la solución (pág. 53). La capa Wrapper o envoltorio es la que se encarga de encapsular el acceso a las reglas de negocio, y por tanto se delega sobre esta capa la comunicación con la capa de negocio y el acceso al resto de servicios que 18 dotan al sistema de la funcionalidad completa localizados en la capa middleware. La comunicación entre las capas Interface y Wrapper se rige en base a un lenguaje común previamente definido, y contendrá toda la información necesaria para realizar cualquier operación ofrecida por la lógica de negocio. Los servicios adicionales se encuentran en una capa adicional o middleware ubicada en un nivel inferior respecto a la capa Wrapper. Esta capa de middleware contiene entre otros los servicios para acceder a la capa de negocio, el almacenamiento de resultados y la notificación de los resultados al cliente. Un sistema diseñado por capas solo permite que existan dependencias entre los componentes de una misma capa y entre capas adyacentes. Sin embargo, todos los componentes de la capa middleware diseñada son independientes entre sí aumentado la flexibilidad del sistema en base a reducir dependencias. La Figura 9 muestra las relaciones entre los elementos de cada una de las capas descritas anteriormente. Figura 9. Vista de componentes y conectores de un componente genérico del flujo de trabajo La capa middleware intermedia está compuesta por cuatro servicios:  Business Logic Service: este servicio ofrece todas las operaciones relacionadas con la lógica de negocio interna.  Store Service: este servicio ofrece operaciones relacionadas con la utilización de un sistema de almacenamiento externo.  Notification Service: este servicio ofrece operaciones relacionadas con la notificación de información a usuarios.  Compression Service: este servicio ofrece operaciones relacionadas con la compresión y descompresión de recursos. El elemento Business Logic está formado por todos los scripts y librerías que componen cada una de los componentes del sistema de inferencia filogenética. Se encarga de realizar la descarga de secuencias de la base de datos GenBank, el procesamiento de las secuencias, generación de superárboles, etc. Todas las salidas se almacenan comprimidas en su correspondiente directorio. La interfaz completa está descrita en la sección número 2 de Anexo II. Diseño de la solución (pág. 61). 19 5.3. Diseño del componente que representa el flujo de trabajo Una vez realizado el diseño de cada uno de los sistemas que representan cada una de los cuatro componentes que constituyen el sistema PhyloFlow [2] se ha procedido a diseñar el sistema que debía contener la lógica del funcionamiento del flujo de trabajo. El diseño del sistema de alto nivel es idéntico al del sistema para cada componente del flujo de trabajo y, por tanto, también está dividió en tres capas que dependen solamente de la capa inmediatamente inferior. La capa intermedia denominada anteriormente como Wrapper en este contexto es denominada como Scheduler, ya que informa mejor de la funcionalidad ofrecida por dicha capa. 5.3.1. Presentación primaria La Figura 7 mostrada anteriormente revela el diseño del sistema que representa el flujo de trabajo. El nivel de interfaz se encargaría de publicar como servicio el flujo completo de un análisis filogenético. La capa intermedia la representaría el Scheduler o planificador de tareas que sería aquel componente encargado de realizar las peticiones correspondientes a cada uno de los componentes del flujo de trabajo en base a la información proporcionada por la lógica de negocio. En este caso, la capa Workflow representa las reglas de negocio, y por tanto, contiene la secuencia y orden de cada componente así como la operación y los parámetros que se ha de realizar. Si aumentamos el nivel de detalle del diseño del sistema en este caso no aparece una capa de middleware que ofrezca unos servicios complementarios. Sin embargo, se puede observar cómo dentro de la capa intermedia aparece un componente denominado MailBox, el cual se encargará de recuperar las respuestas recibidas por parte de los componentes como respuesta a las peticiones realizadas por el componente Scheduler. La Figura 10 muestra el diseño del sistema a un nivel de abstracción inferior. Figura 10. Vista con las capas de diseño del componente flujo de trabajo 5.3.2. Relaciones y sus propiedades La capa Interface se encarga de ofrecer los métodos del servicio que se pueden invocar remotamente. Para ello se define y publica una API que indica las reglas para la invocación del servicio. Cada vez que recibe una petición, la atiende y procesa. Dicha API está explicada y detallada en la sección número 3 de Anexo II. Diseño de la solución (pág. 64). La capa intermedia es la encargada de planificar las tareas del flujo de trabajo. Para ello, se comunica con la capa inferior para obtener la siguiente tarea a realizar dentro del flujo de trabajo actual y realizar la petición al componente concreto que debe realizarla. Para enviar las peticiones de forma correcta emplea el componente XMLService que se encarga de generar los mensajes en formato XML válidos en base al lenguaje de comunicación definido. 26 6.3. Implementación del sistema flujo de trabajo Una vez finalizado los cuatro sistemas que representan cada uno de los componentes constituyentes del flujo de trabajo se comenzó a realzar el sistema que debía planificar los trabajos del mismo para realizar un flujo de trabajo completo. La Figura 14 muestra la vista de componentes del sistema implementado: Figura 14. Vista de implementación del componente flujo de trabajo Este servicio debía utilizar un protocolo de comunicación asíncrono debido a que el tiempo completo de procesamiento de un flujo de trabajo completo es muy elevado. Se tomó la decisión de que este sistema no empleará el protocolo SMTP [23], que permite el envió de correos electrónicos, a cambio de emplear el protocolo IMAP [24], que permite la lectura de la bandeja de entrada. Este protocolo permite leer e interpretar los mensajes de respuesta recibidos por parte de todos los componentes que integran el flujo de trabajo y delega en el último componente del flujo de trabajo la tarea de enviar el mensaje con los resultados al cliente final. Para obtener un servicio asíncrono se genera un proceso independiente por cada petición recibida que es el encargado de gestionar las peticiones a cada uno de los componentes que integran el workflow y de recoger y analizar los resultados recibidos. Para la implementación del componente MailBox, el cual es el encargado de acceder a la bandeja de entrada, leer los mensajes nuevos y notificar al resto de procesos cuando haya un mensaje nuevo, se empleo el patrón Singleton. Este patrón permite que haya una única instancia de la clase en ejecución, por tanto, de esta forma se evitan problemas de concurrencia debido al acceso múltiple a la bandeja de correo electrónicos. 27 7. Despliegue y evaluación Una vez desarrollada la primera versión funcional del sistema se ha desplegado en un entorno distribuido. Para el despliegue del sistema en la nube se han realizado unas tareas previas. Estas tareas han consistido el lanzamiento de una instancia de una máquina Ubuntu 14.04 a partir de una imagen proporcionada por Amazon. Para esta instancia se ha configurado el volumen persistente de la máquina, las reglas de seguridad para acceder a la máquina y el centro de datos donde estará disponible (Irlanda). Una vez que la instancia esta lanzada se ha accedido vía ssh mediante un fichero que contiene una clave privada, ya que al instanciar una máquina se añade la clave publica al fichero que almacena las claves que tienen autorización de acceso. La configuración ha consistido en instalar todas las librerías de las que depende el sistema PhyloFlow [2] así como instalar un servidor Tomcat 7.0 sobre el que desplegar el sistema. Además se han copiada el sistema utilizando el comando scp o la herramienta Filezilla, se han añadido las variables de entorno necesarias del sistema PhyloFlow [2]. Una vez que se ha configurado completamente el entorno se ha creado un script que se encarga de lanzar el servidor Tomcat en el arranque de la máquina, de tal forma, que siempre que la máquina se reinicia el servidor quedará accesible. Po último, se ha realizado una instantánea de la máquina configurada. A partir de esta instantánea se pueden crear nuevas instancias que se encuentran totalmente configuradas de forma automática. 7.1. Explicación de una traza completa de despliegue Una vez que se encuentran las instancias que corresponden a cada uno de los componentes del sistema en ejecución y los servidores de aplicaciones se encuentran activos se puede realizar peticiones a los servicios Web. A continuación se explican las etapas principales de una traza completa de despliegue de una ejecución de un conjunto de secuencias de ADN mitocondrial. En primer lugar se solicita al servicio Web del componente Workflow System la realización de una ejecución completa para el análisis del ADN mitocondrial humano. El componente Workflow System valida la petición recibida y en el caso de ser correcta comienza el proceso. El planificador de tareas seleccionará el primer trabajo a realizar dentro del flujo de trabajo. A partir de dicho trabajo generará una cadena de caracteres en formato XML que cumpla el estándar de entrada definido con el método seleccionado y los parámetros de entrada necesarios. Enviará la petición al componente correspondiente y se mantendrá a la espera de la respuesta. Cuando reciba el mensaje con la respuesta descarga el fichero que la contiene. Analizara la respuesta empleado el formato de salida definido para obtener los valores de la respuesta. Si no aparece ningún bloque fault indicando un error durante el procesamiento selecciona el siguiente trabajo planificado. Realiza estas etapas iterativamente hasta el último trabajo del flujo. En la última etapa del flujo de trabajo, en lugar de emplear el correo electrónico propio introduce como parámetro el correo del cliente para que sea este el que reciba el mensaje con la solución final a su petición. 28 En el caso concreto del procesamiento del ADN mitocondrial humano el orden de las etapas es el siguiente: 1. Petición del cliente al componente Workflow System 2. Descarga de las secuencias de ADN mitocondrial humano 3. Procesamiento utilizando el método de haplogrupos 4. Procesamiento utilizando el método de genes 5. Evaluación de modelos evolutivos y generación de bootstraps 6. Consenso de las soluciones parciales antes de la fase de bootstraps 7. Consenso de las soluciones parciales tras la fase de bootstraps 8. Generación de un único superárbol Las respuestas generadas por cada componente se notificarán al componente Workflow System a través de correos electrónicos. El componente Workflow System accederá a la cuenta de correo electrónico empleando el protocolo IMAP [24] y de esta forma recuperara las respuestas a sus peticiones. La Figura 15 muestra la traza completa de despliegue. Figura 15. Traza de despliegue para un flujo completo de análisis filogenético de ADN mitocondrial 7.2. Verificación y validación del sistema Para la validación y verificación del sistema se ha empleando la herramienta JUnit 4 que ha permitido generar una batería de pruebas unitarias totalmente automáticas. Dichas pruebas se han realizado para validar el comportamiento del sistema ante fallos derivados de la entrada, la ejecución completa de un flujo de trabajo, el correcto funcionamiento del sistema de almacenamiento externo, etc. Este tipo de pruebas son de gran utilidad para validar que la integración de nuevos componentes o los cambios en el código no han implicado modificaciones en el comportamiento del sistema. En caso de modificarse permite detectar el error en función de los test fallidos. Además se han realizado pruebas del sistema en máquinas locales para verificar su correcto funcionamiento antes de desplegar el sistema en la nube proporcionada por Amazon. En ella también se han realizado pruebas para comprobar si permitía, entre otras coas, enviar correos electrónicos sin habilitar los puertos correspondientes en las reglas de seguridad. 29 Para llevar a cabo la evaluación del sistema se ha creado una batería de pruebas para la realización de flujos de trabajo completos con distintas métricas. Debido a las limitaciones computacionales de las instancias micro proporcionadas de forma gratuita por la plataforma Amazon EC2, en lugar de emplear secuencias de ADN mitocondrial se han empleado secuencias sintéticas o conjuntos de secuencias reducidas de las primeras. Los objetivos principales eran validar el comportamiento del sistema y evaluar el sobrecoste que supone ofrecer como servicio las funcionalidades de cada componente individual del sistema PhyloFlow [2] así como el sobrecoste total de un flujo de trabajo completo. 7.3. Resultados de la evaluación La evaluación del sistema se encuentra detallada en la sección Anexo IV. Despliegue y evaluación (pág. 71). Los resultados de la evaluación muestran que el sobrecoste que supone ofrecer cada componente como un servicio en el cómputo global de un flujo de trabajo es ínfimo tanto para secuencias de ADN mitocondrial como secuencias sintéticas. La Tabla 3 muestra el sobrecoste medio para cada uno de los componentes y el total en función del tipo de secuencia. Overhead medio en porcentaje Sequence Fetch Sequences Sequences Processing Sequences Evaluation hmtDNA 94% 0% 0% synthetic 70% 1% 2% Tabla 3. Sobrecoste medio en función del tipo de secuencia El componente Supertree Building no ha sido evaluado debido a que su implementación final no está finalizada. A pesar de que el sobrecoste sea elevado en el componente Fetch Sequences debido a que representa un parte ínfima del total del tiempo a penas afecta al sobrecoste total. Como el procesamiento de las secuencias sintéticas es menos costoso computacionalmente el sobrecoste es superior respecto a las secuencias de ADN mitocondrial, pero aún así es despreciable. A continuación la Figura 16 y la Figura 17 muestran dos gráficas comparativas de la evolución del sobrecoste en función del número de conjuntos de secuencias a procesar. Estas gráficas permiten observar además la diferencia que existe en cada operación entre el tiempo total y el tiempo de ejecución del sistema PhyloFlow [2] y las operaciones que implican un mayor coste temporal dentro del flujo de trabajo. Figura 16. Gráfica con los tiempos totales para 2 sets Figura 17. Gráfica con los tiempos totales para 16 sets 17% 79% 92% 90% 44% Phylo Time Total Time 4% 100% 100% 99% 96% Phylo Time Total Time 30 Cuando se aumenta el número de conjuntos de secuencias el porcentaje que supone el sobrecoste en el tiempo total se reduce. Esto se debe a que el coste temporal del procesamiento de secuencias tiene mayor complejidad, y por tanto, un coeficiente de crecimiento netamente superior. El componente Sequences Processing realiza el procesamiento biológico con los métodos dactal y mafft. En este tipo de flujo de trabajo la fase de mayor coste temporal, por tanto, es la de procesamiento biológico. También se puede observar como la fase de recuperación o descarga de secuencias tiene el mayor sobrecoste de todos. Esto se debe a que para las secuencias de ADN sintético no se realiza ninguna descarga únicamente se recupera una base de datos disponible en el sistema de ficheros del sistema. 7.4. Sistema de toma de decisiones A partir de la información recogida en los fichero de log en concreto los asociados a los servicios relacionados con el sistema PhyloFlow [2] se ha decidió crear perfiles de ejecución que permitan mejorar el aprovisionamiento de recursos. La información recogida de estos ficheros corresponde a tiempos de ejecución, consumo de memoria, método de procesamiento, número de reintentos y número total de sets y tipo de secuencias procesados. Así se ha plantea un método de mejora sencillo basado en el entrenamiento de un árbol de decisión sobre un conjunto de entrenamientos basado en tablas por cada uno de los componentes que constituyen el flujo de trabajo del sistema PhyloFlow [2]. Por último, se ha escogido que tipo de instancia se adaptaría mejor para cada prueba realizada considerando los costes económicos y temporales que implicaría su elección de forma aproximada. Este sistema ha permitido realizar una evaluación inicial del rendimiento del sistema estableciendo estrategias sobre el tipo de plataforma computacional en la cual desplegar cada componente del sistema. La implementación y conclusiones del sistema de toma de decisiones se encuentra detallada en la sección Anexo IV. Despliegue y evaluación (pág. 73). 31 8. Gestión del proyecto y conclusiones Este capítulo contiene toda la información relacionada con la gestión del proyecto y los procesos de seguimiento y control del mismo. Por último se exponen las conclusiones técnicas y personales del trabajo realizado. 8.1. Gestión del proyecto La metodología utilizada para llevar a cabo una correcta gestión del proyecto ha sido la un modelo de ciclo de desarrollo en cascada mejorado. Dicha metodología establece una organización en fases del proyecto y sus correspondientes hitos facilitando su seguimiento, identificación de carencias y retroalimentación del desarrollo. Las fases principales del proyecto corresponden a la fase de captura de requisitos y análisis del sistema, diseño de la solución, implementación y despliegue. Al final de cada una de las fases se ha realizado una verificación de la misma proporcionando retroalimentación tanto para la fase actual como las fases previas. Se ha seguido un flujo de trabajo basado en las fases principales que se consideran en Ingeniería del Software haciendo especial hincapié en aquellas relacionadas con la Ingeniería de Requisitos. Esto ha proporcionado como resultado un análisis profundo de las dependencias, características, necesidades y limitaciones de la solución. La Figura 18 muestra gráficamente el modelo de desarrollo en cascada mejorado. Figura 18. Modelo en cascada mejorado con retroalimentación en cada una de las fases 8.1.1. Gestión de configuraciones Para facilitar la comunicación con los directores del proyecto se ha empleado una carpeta compartida en la plataforma Dropbox. Esta carpeta se ha empleado para almacenar la documentación generada a lo largo de cada una de las fases del proyecto. Se ha empleado un repositorio privado Subversion para almacenar y realizar el control de versiones del código generado. Este repositorio ha sido de gran utilidad debido a que me ha permitido trabajar desde distintos dispositivos con una gestión totalmente automatizada del código. 32 8.1.2. Diagrama de Gantt La Figura 19 muestra el diagrama de Gantt con la planificación realizada del proyecto. Figura 19. Diagrama de Gantt con la planificación final del proyecto Observando el diagrama se puede concluir que se ha seguido de forma estricta el modelo de desarrollo en cascada. También se puede observar como al final de cada fase se ha realizado una reunión de seguimiento que ha generado una retroalimentación del proceso y las fases. 33 8.1.3. Coste total del proyecto Se ha llevado una contabilización de los esfuerzos dedicados a cada actividad del proyecto empleando una hoja de cálculo, cada punto de esfuerzo anotado sobre ella equivale a media hora de esfuerzo real. El coste total del proyecto seccionado por actividades se muestra en la Tabla 4 y la Figura 20. Actividades Esfuerzo total Porcentaje relativo Formación 54,5 h. 15% Análisis 43,5 h. 12% Diseño 47 h. 13% Implementación 88 h. 24% Despliegue y validación 47,5 h. 13% Documentación 54 h. 15% Gestión de proyecto 30 h. 8% 364,5 h. 100% Tabla 4. Esfuerzos totales y porcentaje relativo por actividad Figura 20. Gráfica con la división de los esfuerzos en actividades Observando la gráfica cabe destacar que se ha realizado un gran esfuerzo en las fases principales de la Ingeniería del Software desde la fase temprana de análisis hasta la validación y evaluación del sistema. La actividad que más esfuerzo a requerido ha sido la de implementación del sistema 34 8.2. Conclusiones Se ha desarrollado el proyecto siguiendo las fases principales de la Ingeniería del Software con el objetivo de conseguir un buen análisis y diseño de la solución. La realización de este trabajo ha supuesto afrontar, en lo personal, el trabajo de mayor envergadura hasta la fecha abordando todas las fases de desarrollo de Software. Ha sido necesario aplicar técnicas aprendidas a lo largo de la especialidad de Ingeniería del Software tanto para la gestión del proyecto como para el desarrollo del proyecto. Las fases de análisis y diseño han requerido un gran esfuerzo debido a la importancia que tenía realizar un sistema flexible y escalable que se pudiera ejecutar sobre distintas tipos de instancias. Para ello la utilización de ficheros de propiedades configurables ha sido indispensable facilitando la reproducibilidad del sistema sin la necesidad de modificar el código fuente. La fase de validación y evaluación del sistema ha permitido comprobar el correcto funcionamiento del sistema en una plataforma de computación en la nube. Por tanto, esta solución se podría aplicar sobre una plataforma similar con el objetivo de reducir los costes temporales y económicos empleando las instancias que mejor se adapten a cada componente. Se han cumplido los objetivos planteados inicialmente y se ha introducido un sencillo sistema para la ayuda a la toma de decisiones basado en árboles de decisiones. La utilización de estos árboles permitiría a un componente intermedio lanzar el tipo de instancia indicada para realizar el procesamiento seleccionado. El dominio de la aplicación ha sido novedoso, pero en general ha sido gratificante, debido a que en la actualidad se está realizando un gran esfuerzo en esta materia. Además la ayuda proporcionada por el investigador Jorge Álvarez en las fases iniciales del trabajo me permitió comprender la forma de operar con el sistema PhyloFlow [2]. La introducción de un sistema de ayuda a la toma de decisiones ha permitido hacer una evaluación inicial del rendimiento del sistema que, una vez en explotación permitiría generar estrategias sofisticadas de planificación y asignación dinámica de recursos que incluso tuviera en cuenta cuestiones de coste económico. Personalmente deseaba que el trabajo de fin de grado que realizase me permitiría aprender y conocer nuevas tecnologías Web, en concreto, aquellas relacionadas con los servicios Web. La realización de este trabajo no sólo me ha permitido formarme en el diseño e implementación de servicio Web, sino que me ha brindado la oportunidad de emplear una plataforma de computación en la nube. Por último, la ayuda que me han proporcionado tanto Javier como Gregorio para desarrollar el proyecto ha sido importantísima. Hemos realizado periódicamente reuniones de seguimiento del trabajo que me han permitido obtener una retroalimentación constante por su parte. 35 Bibliografía [1] Blanco et al. Rebooting the human mitochondrial phylogeny: an automated and scalable methodology with expert knowledge. BMC Bioinformatics (12):174. 2011 [2] Jorge Álvarez. Análisis filogenético molecular: Diseño e implementación de algoritmos escalables y fiables y verificación automática de propiedades de una filogenia. [3] HTCondor. High Throughput Computing. URL: http://research.cs.wisc.edu/htcondor/ [4] DAGMan. Directed Acyclic Graph Manager. URL: http://research.cs.wisc.edu/htcondor/dagman/dagman.html [5] Anduril. Component-based workflow framework. URL: http://www.anduril.org/anduril/site [6] Ovaska et al. Large-scale data integration framework provides a comprehensive view on glioblastoma multiforme. Genome Medicine 2010 2:65. [7] Java. Java Programming Language. URL: http://java.com/es/ [8] Perl. The Perl Programming Language. URL: http://www.perl.org/ [9] Phyton. Python Programming Language. URL: https://www.python.org/ [10] Matlab. Matlab, the Language of Technical Computing. URL: http://www.mathworks.com/products/matlab/ [11] Galaxy. Web-based platform for biomedical research. URL: http://galaxyproject.org/ [12] Liu et al. Cloud-based bioinformatics workflow platform for large-scale next-generation sequencing analyses. J BiomedInform (2014) [13] Globus Provision. Globus Transfer System. URL: https://www.globus.org/ [14] Maximum Likelihood. URL: http://en.wikipedia.org/wiki/Maximum_likelihood [15] Evert Duipmans. Business Process Management in the cloud: Business Process as a Service (BPaaS). 2012 [16] Don Jones. White paper: The Business Case for Software as a Service (SaaS). 2010 [17] Fujitsu. White paper: SaaS Business Enablement Services from Fujitsu. 2011 [18] BioPython. Tool for biological computation. URL: http://biopython.org/wiki/Main_Page [19] DendroPy. Library for phylogenetic computing. URL: https://pythonhosted.org/DendroPy/ [20] Maven. Software project management. URL: http://maven.apache.org/ [21] ZIP. ZIP archive file format. URL: http://en.wikipedia.org/wiki/Zip_(file_format) [22] GZIP. GZIP archive file format. URL: http://en.wikipedia.org/wiki/Gzip [23] SMTP. Simple Mail Transfer Protocol. URL: http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol 42 Consensus Pre: El fichero de secuencias de ADN mitocondrial humano de entrada es válido o de árboles filogenéticos. Post: Se realiza un procedimiento de consenso sobre las secuencias de entrada de ADN mitocondrial. Finalmente, se almacenan los resultados en un sistema de almacenamiento externo accesible al usuario. Descripción: El caso de uso comienza cuando el usuario desea realizar una fase de consenso sobre las secuencias de ADN mitocondrial que posee o sobre los árboles filogenéticos si ha realizado previamente una generación de bootstraps. El usuario envía la petición al servicio y una vez finalizado el consenso de los ficheros de secuencias o árboles filogenéticos será notificado. En el caso de que la petición sea sintácticamente incorrecta el sistema le notificará inmediatamente. En caso contrario, el sistema se encarga de solicitar al sistema PhyloFlow [2] que realice el procedimiento de consenso sobre el fichero de secuencias de entrada. Por último, el sistema se encargará recupera los resultados, almacenarlos en el sistema externo y notificar al usuario la ubicación del archivo que contiene los resultados obtenidos. Flujo de eventos Camino básico del caso de uso “Supertree” Usuario Sistema 1. Envía la petición de descarga del ADN mitocondrial incluye la URI que da acceso al fichero de datos de secuencia 2. Include Store Service 3. Include Business Logic Service 4. Include Store Service 5. Include Notification Service Camino alternativo Evento 1. El usuario ha introducido algún error en la petición. El sistema responde de forma síncrona informando del error al usuario. Evento 2. Se produce un error al descargar el fichero de entrada. El sistema responde de forma asíncrona informado del error al usuario. Evento 3. Se produce un error interno del sistema PhyloFlow que impide realizar el procedimiento de consenso. El sistema notifica al usuario el error producido de forma asíncrona. Evento 4. Se produce un error al almacenar el resultado en el sistema de almacenamiento externo. El sistema responde de forma asíncrona informando del error al usuario. 43 Supertree Pre: El fichero de secuencias árboles filogenéticos de entrada es válido. Post: Se realiza la construcción del superárbol a partir de los árboles filogenéticos generados previamente. Finalmente, se almacenan los resultados en un sistema de almacenamiento externo accesible al usuario. Descripción: El caso de uso comienza cuando el usuario desea realizar la construcción de un único árbol filogenético (superárbol) a partir de los ficheros de árboles filogenéticos que posee. El usuario envía la petición al servicio y una vez finalizado el consenso de los ficheros de secuencias será notificado. En el caso de que la petición sea sintácticamente incorrecta el sistema le notificará inmediatamente. En caso contrario, el sistema se encarga de solicitar al sistema PhyloFlow que realice la construcción del superárbol empleando el método y perfil seleccionados por el usuario. Por último, el sistema se encargará recupera los resultados, almacenarlos en el sistema externo y notificar al usuario la ubicación del archivo que contiene los resultados obtenidos. Flujo de eventos Camino básico del caso de uso “Supertree” Usuario Sistema 1. Envía la petición de descarga del ADN mitocondrial incluye la URI que da acceso al fichero de datos de secuencia 2. Include Store Service 3. Include Business Logic Service 4. Include Store Service 5. Include Notification Service Camino alternativo Evento 1. El usuario ha introducido algún error en la petición. El sistema responde de forma síncrona informando del error al usuario. Evento 2. Se produce un error al descargar el fichero de entrada. El sistema responde de forma asíncrona informado del error al usuario. Evento 3. Se produce un error interno del sistema PhyloFlow que impide realizar el procedimiento de construcción del superárbol. El sistema notifica al usuario el error producido de forma asíncrona. Evento 4. Se produce un error al almacenar el resultado en el sistema de almacenamiento externo. El sistema responde de forma asíncrona informando del error al usuario. 44 Business Logic Service Pre: - Post: Se captura la salida estándar y la salida de error generada por el sistema PhyloFlow [2]. Si el proceso ha finalizado con éxito el sistema recupera los resultados generados por el sistema PhyloFlow [2]. Descripción: El caso de uso comienza cuando el sistema desea obtener los resultados proporcionaos por una de las funcionalidades ofrecidas por el sistema PhyloFlow [2]. El sistema crea un proceso que invoca por línea de comando al sistema PhyloFlow [2], introduciendo por la entrada estándar los parámetros seleccionados. Se genera uno o más procesos que realizan la funcionalidad solicitada. Por último, el sistema recoge los resultados si el procesamiento ha tenido éxito. En caso contrario, captura el error que se ha producido a través de la salida del sistema PhyloFlow [2]. Flujo de eventos Camino básico del caso de uso “Business Logic Service” Sistema Sistema PhyloFlow 1. Genera un proceso, el cuál mediante línea de comandos invoca al sistema PhyloFlow 2. Realiza el procesamiento solicitado 3. Captura la salida de error 4. Recupera los resultados 45 Store Service Pre: - Post: Se realiza la descarga de un recurso identificado por una URI o se procede al almacenamiento de un recurso en el sistema de almacenamiento externo. Descripción: El caso de uso comienza cuando el sistema desea realizar la descarga de un recurso en base a una URI que posee. El sistema envía la petición al servicio y sus credenciales de acceso. Si las credenciales son válidas y posee permisos para realizar las acción solicitada, lectura o escritura, el sistema de almacenamiento externo realizará la acción solicitada. Por último, el sistema recuperará los archivos descargados o la URI que identifica al recurso almacenado. Flujo de eventos Camino básico del caso de uso “Store Service” Sistema Sistema externo de almacenamiento 1. Solicita la descarga de un archivo identificado por una URI 2. Comprueba las credenciales y las reglas de seguridad. 3. El sistema comprueba la URI. Si es correcta, descarga el archivo 4. Recupera el archivo descargado Camino alternativo Evento 2. Las credencias de acceso son inválidas o no posee permisos de lectura. El sistema de almacenamiento generara un error y el sistema lo captura. Evento 3. Se produce un error interno del sistema de almacenamiento externo debido a un error interno o una URI incorrecta. El sistema capturar el error. Camino básico II del caso de uso “Store Service” Sistema Sistema externo de almacenamiento 1. Solicita el almacenamiento de un archivo 2. Comprueba las credenciales y las reglas de seguridad. Almacena el archivo 3. Almacena el archivo y devuelve una URI con su ubicación 4. El sistema recupera la URI Camino alternativo Evento 2. Las credencias de acceso son inválidas o no posee permisos de escritura. El sistema de almacenamiento generara un error y el sistema lo captura. Evento 3. Se produce un error interno del sistema de almacenamiento externo debido a un error interno o una URI incorrecta. El sistema captura el error. 46 Notification Service Pre: El sistema posee las credenciales válidas para acceder al sistema remoto. Post: Se notifica al usuario final los resultados obtenidos a causa de la petición que realizó previamente. Descripción: El caso de uso comienza cuando el sistema desea notificar al usuario final los resultados que ha obtenido a causa de la petición que realizó previamente el usuario. El sistema envía las credenciales de acceso al sistema remoto de notificación. Si las credenciales son válidas, el sistema tendrá acceso y podrá notificar los resultados al cliente. En caso contrario, se generará un error. Flujo de eventos Camino básico del caso de uso “Notification Service” Sistema Sistema externo de notificación 1. Solicita la notificación de los resultados al cliente. 2. Comprueba las credenciales y las reglas de seguridad. 3. Notifica los resultados al cliente. Camino alternativo Evento 2. Las credencias de acceso son inválidas. El sistema de notificación generara un error y el sistema lo captura. 47 Configuration Pre: - Post: Se realiza la configuración del sistema para desplegarlo y lanzarlo de forma correcta sobre la máquina en la que reside. Descripción: El caso de uso comienza cuando el usuario desea configurar la máquina en la que se encuentra el sistema para poder utilizarlo. Para ello modifica los ficheros de configuración del subsistema estableciendo las variables de entorno, rutas y credenciales de acceso de cada servicio que compone el sistema. Por último, se realiza el despliegue del sistema. Si el sistema está bier configurado su puesta en marcha será correcta. Flujo de eventos Camino básico del caso de uso “hmtDNA Workflow” Usuario Sistema 1. Modifica los ficheros de configuración del sistema 2. Despliega el sistema sobre un servidor de aplicaciones 4. El sistema se actualiza y se lanza Camino alternativo Evento 4. El usuario ha configurado incorrectamente el sistema, por tanto, se genera algún tipo de error durante la puesta en marcha del mismo. 48 hmtDNA Workflow Pre: - Post: Se realiza un flujo de trabajo completo para la inferencia filogenética de un árbol evolutivo sobre un conjunto de secuencias de ADN mitocondrial humano. Descripción: El caso de uso comienza cuando el usuario desea realiza un análisis del filogenético sobre un árbol evolutivo sobre un conjunto de secuencias de ADN mitocondrial humano. El usuario envía la petición al servicio y una vez finalizado el flujo de trabajo completo para la inferencia de un árbol filogenético será notificado. En el caso de que la petición sea sintácticamente incorrecta el sistema le notificará inmediatamente. En caso contrario, el sistema se encarga de integrar cada uno de los servicios que se corresponden con cada componente del flujo de trabajo para llevarlo a cabo. Flujo de eventos Camino básico del caso de uso “hmtDNA Workflow” Usuario Sistema 1. Envía la petición de realización de un flujo de trabajo completo para secuencias de ADN mitocondrial. 2. Include Scheduler Camino alternativo Evento 1. El usuario ha introducido algún error en la petición. El sistema responde de forma síncrona informando del error al usuario. 49 Scheduler Pre: - Post: Se realiza un flujo de trabajo completo para la inferencia filogenética de un árbol evolutivo sobre un conjunto de secuencias de ADN mitocondrial humano integrando cada uno de los componentes del sistema PhyloFlow [2]. Descripción: El caso de uso comienza cuando el sistema solicita la realización de un flujo completo de ADN mitocondrial humano. Para ello solicita de forma secuencial y ordenada cada uno de los componentes que forman el flujo de trabajo la realización de uno o varios trabajos concretos. Emplea los resultados parciales de cada componente como la entrada de datos del siguiente componente. Flujo de eventos Camino básico del caso de uso “Scheduler” Sistema Componente Fetch Sequences 1. Envía la petición de descarga de la base de datos de ADN mitocondrial humano de GenBank 2. Include DownloadDB 3. Espera hasta obtener los resultados solicitados. Camino alternativo Evento 1. Se ha producido un error durante la realización de la petición y el mensaje recibido así lo indica. Flujo de eventos Camino básico del caso de uso “Scheduler” Sistema Componente Sequences Processing 1. Envía la petición de realizar el procesamiento biológico sobre las secuencias de entrada. 2. Include Map-reduce 3. Espera hasta obtener los resultados solicitados. Camino alternativo Evento 1. Se ha producido un error durante la realización de la petición y el mensaje recibido así lo indica. Flujo de eventos Camino básico del caso de uso “Scheduler” Sistema Componente Sequences Evalutaion 1. Envía la petición para la evaluación de modelos evolutivos sobre las secuencias de entrada. 2. Include Evaluation 3. Espera hasta obtener los resultados solicitados. Camino alternativo Evento 1. Se ha producido un error durante la realización de la petición y el mensaje recibido así lo indica. 50 Flujo de eventos Camino básico del caso de uso “Scheduler” Sistema Componente Sequences Evalutaion 1. Envía la petición para la generación de un único árbol filogenético consensuado a partir de las soluciones parciales de entrada. 2. Include Consensus 3. Espera hasta obtener los resultados solicitados. Camino alternativo Evento 1. Se ha producido un error durante la realización de la petición y el mensaje recibido así lo indica. Flujo de eventos Camino básico del caso de uso “Scheduler” Sistema Componente Supertree Building 1. Envía la petición para la generación de un único superárbol a partir de los resultados parciales de entrada obtenidos previamente 2. Include Supertree 3. Espera hasta obtener los resultados solicitados. Camino alternativo Evento 1. Se ha producido un error durante la realización de la petición y el mensaje recibido así lo indica. 51 MailBox Service Pre: - Post: Se recupera el mensaje solicitado por la entrada. Descripción: El caso de uso comienza cuando el sistema Scheduler recuperar un mensaje que se corresponde con la notificación de unos de los servicios integrados. Este mensaje contiene la respuesta a su petición. El sistema Scheduler solicita la recuperación del mensaje, el sistema comprueba las credenciales de acceso. Si las credenciales son válidas y el mensaje se encuentra en la bandeja de entrada el sistema entregará el mensaje solicitado. En caso contrario, el sistema seguirá consultado la bandeja de entrada cada cierto tiempo hasta obtener el mensaje solicitado. Flujo de eventos Camino básico del caso de uso “MailBox Service” Sistema Scheduler Sistema 1. Solicita la recuperación de un mensaje o notificación. 2. Comprueba las credenciales de acceso. 3. Cada cierto tiempo recupera los mensajes y notificaciones sin leer. Si coincide con el mensaje lo pedido. 4. Recupera el mensaje solicitado Camino alternativo Evento 2. Las credencias de acceso son inválidas. El sistema de almacenamiento generara un error y el sistema lo captura. Evento 3. El mensaje solicitado no se ha recibido aún. Se mantiene en este estado hasta que el mensaje solicitado se encuentre en la bandeja de entrada. Evento 3. Se produce un error interno del sistema de lectura de notificaciones. El sistema captura el error. 58 Consensus Descripción: se encarga de generar un único árbol filogenético consensuado a partir del mejor modelo evolutivo. Petición: Método URL POST /phyloflow /sequencesevaluation/consense Parámetros Estilo Tipo Descripción input plain api:Input Datos de entrada consensus plain api:Operation Operación a realizar method plain xsd:string Método de consensos de soluciones parciales after_bootstraps plain xsd:boolean Flag que indica si la etapa de consenso es posterior a la etapa de bootstrapping num_retries plain xsd:integer Número total de reintentos data plain api:Data Datos de entrada URI plain xsd:string Identificador de los recursos id_file (optional) plain xsd:string Identificador de los ficheros si es necesario directory (optional) plain xsd:string Identificador de los directorios si es necesario notification plain api:Notification Notificación email(choice) plain xsd:string Correo electrónico para notificar los resultados other(choice) plain xsd:string Otro tipo de notificación Respuesta: Estado Respuesta 200 “Ok your process ID is [PID]” 400 “Syntax Error: [error]” 500 “Internal Error, try again later” 59 Componente: Supertree Building Identidad: Supertree Building, ofrece una operación para la generación de un superárbol a partir de resultados parciales. Supertree Descripción: se encarga de generar el proceso de construcción del superárbol para los tipos de datos de entrada en base al método seleccionado. Petición: Método URL POST / phyloflow /supertreebuilding/supertree Parámetros Estilo Tipo Descripción input plain api:Input Datos de entrada supertree plain api:Operation Operación a realizar data_type plain xsd:string Tipo de secuencia de datos method plain xsd:string Método de construcción de un superárbol num_retries plain xsd:integer Número total de reintentos profile (optional) plain xsd:string Perfil del superárbol a generar data plain api:Data Datos de entrada URI plain xsd:string Identificador de los recursos id_file (optional) plain xsd:string Identificador de los ficheros si es necesario directory (optional) plain xsd:string Identificador de los directorios si es necesario notification plain api:Notification Notificación email(choice) plain xsd:string Correo electrónico para notificar los resultados other(choice) plain xsd:string Otro tipo de notificación 60 Respuesta: Estado Respuesta 200 “Ok your process ID is [PID]” 400 “Syntax Error: [error]” 500 “Internal Error, try again later” 61 2. Interfaz de cada servicio que forma parte de la capa middleware BussinesLogicService Este elemento ofrece todas las operaciones de la lógica de negocio. Por tanto encapsula todas la problemática relacionadas con la generación de procesos y recuperación de las salidas. Los servicios que ofrece son los siguientes: Operación: downloadDB (data_type, email) Descripción: se encarga de descargar o copiar los ficheros de secuencia para el tipo de datos y de dividirlos en sets de secuencias que se almacenan en “data/sets” en formato tar.gz. Parámetros: Parámetro Tipo Representación data_type String Tipo de secuencia email String Email de contacto Operación: map_reduce (data_type, method, num_retries, do_reduce, ref_seq) Descripción: se encarga de realizar el método procesamiento seleccionado para el tipo de datos de entrada sobre los ficheros de secuencia almacenados en formato tar.gz en “data/mapred”, almacenando en la misma carpeta los ficheros de secuencia en formato tar.gz. Si el flag do_reduce está activo genera un único fichero que contiene todos los resultados unidos. Parámetros: Parámetro Tipo Representación data_type String Tipo de secuencia method String Nombre del método que se desea emplear para el procesamiento de las secuencias num_retries int Número total de reintentos do_reduce boolean Flag de reducción ref_seq String Referencia de secuencia Operación: evaluate (data_type, eval_method, num_bootsraps, bs_method, cons_method, num_retries) Descripción: se encarga de evaluar los ficheros almacenados en el directorio “data/phylo” en formato tar.gz, para el tipo de secuencia de entrada y de seleccionar el mejor modelo de entre todos los evaluados. Además si el número de bootstraps de entrada es mayor de 0, se encarga de generar el número total de bootstraps solicitados a partir de los ficheros para el tipo de secuencia de entrada y de evaluar los bootstraps generados con el mejor modelo obtenido. Parámetros: Parámetro Tipo Representación data_type String Tipo de secuencia eval_method String Método de evaluación models String Modelos para realizar la evaluación num_retries int Número total de reintentos num_ bootsraps int Número total de ficheros a generar bs_method String Método de bootstrapping cons_method String Método de consenso 62 Operación: consensus (method, after_bootstraps, num_retries) Descripción: Se encarga de generar un árbol filogenético en base al método de consenso seleccionado. Si el flag after_bootstraps está activo genera el árbol de consenso teniendo en cuenta el resultado de la evaluación de los bootstraps. Parámetros: Parámetro Tipo Representación method String Método de consenso after_bootstraps boolean Flag que índica si la etapa de consenso es posterior a la etapa de bootstrapping num_retires int Número total de reintentos Operación: supertree (data_type, method, num_retries) Descripción: se encarga de generar el proceso de construcción del superárbol para los tipos de datos de entrada en base al método seleccionado. Parámetros: Parámetro Tipo Representación data_type String Tipo de secuencia method String Método de construcción del superárbol profile String Perfil del superárbol num_retries int Número de reintentos StorageService Este elemento ofrece operaciones relacionas con el almacenamiento, recuperación y eliminación de ficheros en un sistema de almacenamiento externo. Operación: URI - storeFile (fichero) Descripción: se encarga de almacenar en un sistema de almacenamiento externo el fichero solicitado. Devuelve la URI donde se encuentra el recurso. Parámetros: Parámetro Tipo Representación fichero File Fichero a almacenar Operación: File - downloadFile(URI) Descripción: se encarga de descargar el recurso que se encuentra en la URI de entrada. Devuelve el fichero que corresponde al recurso descargado. Parámetros: Parámetro Tipo Representación URI URI Identificador único de un recurso a descargar Operación: removeFile (URI) Descripción: se encarga de eliminar el recurso pasado como parámetro de entrada. 63 Parámetros: Parámetro Tipo Representación URI URI Identificador único de un recurso a eliminar CompressionService Este elemento ofrece operaciones relacionas con la compresión y descompresión de ficheros. Operación: File – compress (fichero) Descripción: se encarga de comprimir el fichero pasado por la entrada en un directorio temporal. Devuelve el fichero descomprimido en el directorio temporal. Parámetros: Parámetro Tipo Representación fichero File Fichero a descomprimir Operación: decompress (fichero) Descripción: se encarga de descomprimir el fichero pasado en un directorio temporal. Devuelve el fichero descomprimido. Parámetros: Parámetro Tipo Representación fichero File Fichero a descomprimir NotificationService Este elemento ofrece operaciones relacionas con el envió de notificaciones relacionadas con el final de un procesamiento. Operación: notifícate (cliente, fichero) Descripción: se encarga de notificar al cliente solicitado el fichero pasado por la entrada. Parámetros: Parámetro Tipo Representación subject String Asunto de la notificación client String Cliente a notificar fichero File Fichero que contiene los resultados generado 64 3. API REST componente que representa el flujo de trabajo Identidad: Workflow System, ofrece operaciones para la realización de un flujo de trabajo completo para el procesamiento y análisis filogenético de distintos tipos de secuencias. Synthetic Workflow Descripción: se encarga de gestionar el flujo de trabajo completo para el procesamiento y análisis filogenético de secuencias sintéticas integrando los componentes necesarios. Petición: Método URL POST /phyloflow/workflow/synthetic Parámetros Estilo Tipo Descripción email plain xsd:string Correo electrónico para notificar los resultados Respuesta: Estado Respuesta 200 “The workflow process has begun without problems. You will receive a message in your mailbox in a few hours” 400 “Syntax Error: invalid email” 500 “Internal Error, try again later” hmtDNA Workflow Descripción: se encarga de gestionar el flujo de trabajo completo para el procesamiento y análisis filogenético de secuencias de ADN mitocondrial humano integrando los componentes necesarios. Petición: Método URL POST /phyloflow/workflow/hmtDNA Parámetros Estilo Tipo Descripción email plain xsd:string Correo electrónico para notificar los resultados 65 Respuesta: Estado Respuesta 200 “The workflow process has begun without problems. You will receive a message in your mailbox in a few hours” 400 “Syntax Error: invalid email” 500 “Internal Error, try again later” 66 4. Comunicación: estándares de intercambio Estándar de entrada: descripción El formato de intercambio de datos para la entrada está divido en 3 secciones. La primera sección es obligatoria y describe la operación a realizar y los parámetros de entrada necesarios para cada operación así como el tipo de los mismos. Los parámetros de entrada se pueden introducir en cualquier orden. El sistema de inferencia filogenética ofrece las siguientes operaciones:  downloadDB: está operación descarga los datos deseados para el tipo de secuencia de entrada, cuyos parámetros son: o data_type: tipo de secuencia de datos o email: correo electrónico para informar al usuario en caso de abuso de descargas.  map-reduce: está operación realiza el procesamiento deseado mediante el método seleccionado al tipo de secuencia de entrada, cuyos parámetros son: o data_type: tipo de secuencia de datos o method: tipo de procesamiento o num_retries: número total de reintentos o do_reduce: reduce los ficheros de salida a uno único o ref_seq: referencia a la secuencia (opcional)  evaluate: está operación realiza la evaluación de modelos para el tipo de secuencia de entrada y de manera opcional realiza tanto la generación como la evaluación de bootstraps. Sus parámetros son: o data_type: tipo de secuencia de datos o method: tipo de procesamiento o num_retries: número total de reintentos o models: modelos a emplear en la evaluación (opcional) o num_bootstraps: número total de bootstraps a generar (opcional) o bs_method: método de creación de bootstraps (opcional) o cons_method: método de consenso (opcional)  consensus: está operación realiza el consenso de los datos generados en la fase de evaluación de modelos: o method: método de consensos o after_bootstraps: booleano que indica si se ha de realizar antes o después de la creación de bootstraps, es decir, los tiene o no en cuenta para la realización del consenso o num_retries: número total de reintentos  supertree: está operación genera el superárbol para los datos de entrada: o data_type: tipo de secuencia de datos o method: método de creación o num_retries: número total de reintentos o profile: perfil del superárbol (opcional) La segunda sección describe los datos de entrada, los cuales se emplearán para realizar los procesamientos solicitados. Esta sección es obligatoria para todas las operaciones salvo para la operación downloadDB, ya que es la única operación que no procesa datos de entrada.  uri: es una cadena de caracteres que representa el identificador único que permite el acceso al recurso que contiene o se corresponde a los datos de entrada  id_file: es una cadena de caracteres que representa una expresión regular para seleccionar únicamente aquellos datos que cumplen dicha expresión  directory: es una cadena de caracteres que representa el nombre de la carpeta donde se ubican los datos a procesar 67 La última sección está relacionada con el proceso de notificación. En la actualidad se puede notificar al usuario mediante un correo electrónico que contendrá la respuesta a su petición.  email: correo electrónico al cual notificar el resultado del servicio  other: otro tipo de mecanismo (sin uso actualmente) Estándar de entrada: xsd <?xml version="1.0" encoding="UTF-8" ?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="input"> <xs:complexType> <xs:sequence> <!-- Operation --> <xs:choice> <xs:element name="downloadDB"> <xs:complexType> <xs:all> <xs:element name="data_type" type="xs:string"/> <xs:element name="email" type="xs:string"/> </xs:all> </xs:complexType> </xs:element> <xs:element name="map-reduce"> <xs:complexType> <xs:all> <xs:element name="data_type" type="xs:string"/> <xs:element name="method" type="xs:string"/> <xs:element name="num_retries" type="xs:integer"/> <xs:element name="do_reduce" type="xs:boolean"/> <xs:element minOccurs="0" maxOccurs="1" name="ref_seq" type="xs:string"/> </xs:all> </xs:complexType> </xs:element> <xs:element name="evaluate"> <xs:complexType> <xs:all> <xs:element name="data_type" type="xs:string"/> <xs:element name="method" type="xs:string"/> <xs:element name="num_retries" type="xs:integer"/> <xs:element minOccurs="0" maxOccurs="1" name="models" type="xs:string"/> <xs:element minOccurs="0" maxOccurs="1" name="num_bootstraps" type="xs:integer"/> <xs:element minOccurs="0" maxOccurs="1" name="bs_method" type="xs:string"/> <xs:element minOccurs="0" maxOccurs="1" name="cons_method" type="xs:string"/> </xs:all> </xs:complexType> </xs:element> <xs:element name="consensus"> <xs:complexType> <xs:all> <xs:element name="method" type="xs:string"/> <xs:element name="after_bootstraps" type="xs:boolean"/> <xs:element name="num_retries" type="xs:integer"/> </xs:all> </xs:complexType> </xs:element> <xs:element name="supertree"> <xs:complexType> <xs:all> <xs:element name="data_type" type="xs:string"/> <xs:element name="method" type="xs:string"/> <xs:element name="num_retries" type="xs:integer"/> <xs:element minOccurs="0" maxOccurs="1" name="profile" type="xs:string"/> </xs:all> </xs:complexType> </xs:element> </xs:choice> <!-- Input Data --> <xs:element name="data" minOccurs="0" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="URI" type="xs:string"/> <xs:element minOccurs="0" maxOccurs="1" name="id_file" type="xs:string"/> <xs:element minOccurs="0" maxOccurs="1" name="directory" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <!-- Notification --> <xs:element name="notification"> <xs:complexType> <xs:choice> <xs:element name="email" type="xs:string"/> <xs:element name="other" type="xs:string"/> </xs:choice> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> 74 En la herramienta KNIME [25] se crea un flujo de trabajo como el de la Figura 24 para cada conjunto de entrenamiento. Los ficheros de entrada contienen el conjunto de entrenamiento a partir del cual se crea un árbol de decisión. Se han empleado las secuencias sintéticas para generar estos árboles y las secuencias de ADN mitocondrial para establecer árboles predictivos, por último, se genera una imagen con el árbol de decisión. Figura 24. Flujo de trabajo para crear un árbol de decisión A continuación, la Figura 25 muestra los resultados de los modelos derivados del entrenamiento y las pruebas realizadas con ellos para el componente Fetch Sequences. Figura 25. Árbol de decisión para el componente Fetch Sequences En este caso debido a que sólo se realizaban copias de la bases de datos disponibles para todos los perfiles de entrenamiento descritos la decisión establecía emplear instancias de tipo micro. La Figura 26 y la Figura 27 muestran los resultados de los modelos derivados del entrenamiento y las pruebas realizadas con ellos para los componentes Sequences Processing y Sequences Evaluation respectivamente. En el primer caso la variable de mayor peso es el número de reintentos debido al defecto comentado anteriormente producido en la fase de backup que obliga a aumentar el número de reintentos a la par que se aumenta el conjunto de secuencias. 75 Figura 26. Árbol de decisión para el componente Sequences Processig Figura 27. Árbol de decisión para el componente Sequences Evaluation 76 77 Anexo V. Manual de usuario En esta sección se detallan los procedimientos que deben realizar un usuario para utilizar correctamente el sistema. 1. Identificación del servicio Todos los servicios Web ofrecidos son de tipo REST, por tanto, el usuario debe emplear una herramienta que le permita realizar peticiones REST al servicio que desee, por ejemplo, la herramienta REST Advanced Client para el navegador Google Chrome que ofrece una interfaz gráfica para realizar las peticiones de forma sencilla. Otra alternativa sería implementar un sistema propio utilizando cualquier lenguaje de programación que soporte peticiones REST. El primer paso que debe realizar el usuario es identificar el servicio que desea consumir. Una vez identificado debe consultar la API de dicho servicio para conocer el protocolo de comunicación establecido. Ésta informa de la ubicación exacta del servicio, el método HTTP y los parámetros de entrada. Además se ha de tener en cuenta el estándar de comunicación establecido. 2. Servicios individuales Por ejemplo, para realizar una petición al servicio Fetch Sequences una vez consultada la API se conoce que la URL del servicio que es la dirección relativa /phyloflow/fetchsequences/download, el método HTTP es POST y los parámetros de entrada para dicha operación son el tipo de secuencia y el correo electrónico. Por tanto, la petición a enviar en el payload del mensaje tendrá la siguiente estructura: <input> <downloadDB> <data_type>hmtDNA</data_type> <email>[email protected]</email> </downloadDB> <notification> <email>[email protected]</email> </notification> </input> A continuación la Figura 28 se muestra un ejemplo empleando la herramienta REST Advanced Client comentada anteriormente. En esta petición se solicita obtener la base de datos de secuencias sintéticas. La Figura 28 muestra el procedimiento a realizar. Figura 28. Petición POST al servicio Fetch Sequences con la herramienta REST Advanced Client 78 Si el servicio responde con un estado 200 significa que la petición ha tenido éxito. Si la petición fuera sintácticamente incorrecta el servicio responderá con el estado 400 que equivale a petición incorrecta. En cambio si se produjese un error interno durante el análisis de la petición el servicio responderá con un estado 500 que equivale a error interno del servidor. Si la petición ha tenido éxito el servidor comenzará a realizar el procesamiento solicitad, cuando finalice el servicio notificará al correo electrónico los resultados obtenidos. La Figura 29 muestra el mensaje enviado al correo electrónico con el adjunto que contiene los resultados. Figura 29. Mensaje de respuesta del servicio Fetch Sequences El fichero adjunto con la respuesta contiene la URI que da acceso a los resultados comprimidos en el sistema de almacenamiento de Amazon S3. La URI contiene caracteres de escape, por tanto, se deben modificar antes de introducirla en el navegador. La respuesta a la petición anterior es la siguiente: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <output> <result> <status>Status: OK</status> <data> <URI>https://buckete3e1db59-fae0-4145-8da4-b1492f63d502.s3-eu-west1.amazonaws.com/sets.zip?Expires=1403726111&amp;AWSAccessKeyId=AKIAI2NWUPUT5KCSJ7EQ&amp;S ignature=Asa%2BPxyxrge0s57oE2uCOkQbOkQ%3D </URI> </data> </result> </output> Si se hubiera producido un error durante el procesamiento la respuesta tendría un bloque fault que contendría el error producido y una breve explicación del mismo. De esta forma, el usuario podría detectar si ha introducido algún parámetro erróneo o si el servicio está momentáneamente fuera de servicio. La única diferencia respecto al resto de servicios es que este servicio no requiere una entrada de datos a procesar. Las peticiones del resto de servicios como indica la API de cada uno de ellos debe tener un campo para los datos de entrada. Basta con utilizar el campo data del fichero de respuesta en la siguiente petición, siempre y cuando el recurso siga estando disponible. 79 A continuación, se muestra como se ha de realizar una petición al componente Sequences Processing para realizar un procesamiento biológico sobre las secuencias sintéticas obtenidas anteriormente. En este caso se ha seleccionado el método dactal con un número de reintentos igual a 3. La petición tiene la siguiente estructura: <input> <map-reduce> <data_type>dna</data_type> <method>dactal</method> <num_retries>3</num_retries> <do_reduce>false</do_reduce> <ref_seq>backup</ref_seq> </map-reduce> <data> <URI>https://buckete3e1db59-fae0-4145-8da4-b1492f63d502.s3-eu-west1.amazonaws.com/sets.zip?Expires=1403726111&amp;AWSAccessKeyId=AKIAI2NWUPUT5KCSJ7EQ&amp;S ignature=Asa%2BPxyxrge0s57oE2uCOkQbOkQ%3D </URI> </data> <notification> <email>[email protected]</email> </notification> </input> Nuevamente se ha de esperar a que finalice el procesamiento por completo para obtener los resultados. Para interactuar con el resto de componentes que constituyen el flujo de trabajo se realiza de la misma forma. La única variación se produce en el campo que corresponda a la operación y parámetros del servicio que se desee consumir. 3. Servicio para un flujo de trabajo completo Si se desea realizar un flujo de trabajo completo sin la necesidad de integrar manualmente cada una de las fases el usuario puede consumir el servicio Web publicado por el componente Workflow System. Al igual que para los servicio anteriores el primer paso es consultar la API del servicio para conocer el protocolo de comunicación. Este servicio realiza un flujo de trabajo predeterminado y, por tanto, no es necesario que el usuario añada ningún parámetro a excepción del correo electrónico. Consecuentemente, si se desea realizar un flujo de trabajo completo simplemente se debe enviar un parámetro etiquetado con email que representa el correo electrónico del usuario. Por tanto, la petición sería la siguiente: <email>[email protected]om</email> Exactamente igual que para los servicios anteriores si la petición tiene éxito responderá con el estado 200, si la petición es sintácticamente incorrecta lo hará con estado 400 y, por último si se produce un error interno responderá con el estado 500. El componente System Workflow se encargará de realizar las peticiones ordenadamente y capturar los resultados parciales. El último nodo del flujo de trabajo completo será el encargado de notificar al usuario los resultados. El mensaje con los resultados será exactamente igual que el mostrado en la Figura 29. 80