PlasmidNet. Sistema de Información de Módulos Funcionales de Plásmidos
¿Cuál es el enfoque que seguiremos en PlasmidNet?. En nuestro objetivo de abrazar la simplicidad al máximo hemos construido el embrión (thinCMS) de lo que podrá ser un CMS más elaborado. Hemos conservado únicamente un aspecto que consideramos crucial: separar los roles de diseño del sitio web del rol de programación del mismo. En una frase la maqueta del sitio es la base de la construccióny por tanto se mantiene constantemente actualizada.
5.2.
Implementación
Todo parte de la maqueta, la versión inicial del portal y las posteriores modificaciones. Cada modificación en un elemento gráfico, hoja de estilos, imagen, etc. . . , se desarrolla sobre la maqueta.
A partir de aquí el flujo de la información es el siguiente:
1) Los archivos de estilos css se exportan al entorno del servidor web tal cuál están definidos en la maqueta. Esto no es del todo trivial, porque es necesario asegurarse desde el principio que el sistema de nombrado de los elementos css no va a colisionar con ninguna librería javascript de las librerías que se utilizan o se van a utilizar en programación. Para ello es fundamental prefijar adecuadamente los distintos elementos.
2) El html es fraccionado en un html global (de la página; recordemos que estamos en el ámbito de un proyecto de una única página) y diferentes fragmentos de identidad funcional que hemos denominado (artefactos) injertables o widgets a lo largo de este documento. Todos estos elementos son almacenados en la base de datos (específica, diferenciada de la base de datos biológica). Los widgets son eliminados de la página principal dejando en su lugar puntos de inserción. Para todos los elementos se genera un código de versión que es una reducción criptográfica md5 del contenido html.
3) La aplicación (web app) carga la página principal, como si fuera un html convencional suministrada por el servidor web y carga los injertables desde la base de datos a medida que los va necesitando.
Puntos de inserción, widgets y la página como un todo cuentan con un conjunto de etiquetas tags html específicas de PlasmidNet, que se prefijan con pn- por parte del diseñador de la maqueta y que obedecen a un contrato entre el diseñador y el programador. Estas etiquetas son meras marcas que finalmente ayudan al programa a decidir qué hacer en cada momento: mostrar o no el widget, de qué forma, qué datos se muestran. Usando intensivamente estrategias COC pueden llegar a automatizarse una buena parte de este contrato, reutilizándose con facilidad partes del código.
La operatividad de la maqueta es laxa, no es una exigencia. Las acciones que no se im- plementen, basta con que sean documentadas. En realidad deberíamos denominar la maqueta como ‘versión estática del sitio web’. Sí conviene implementar algunas funciones en respuesta a algunos eventos muy ligadas a la presentación. En nuestro caso, por ejemplo, está implementada la acción del botón superpuesto que nos lleva al inicio de la página. Estas funciones se inte- gran en un javascript que debe ser incorporado a la aplicación tal cuál está implementado, sin modificaciones o mediante modificaciones automáticas.
Todos estos acuerdos obedecen únicamente al criterio de que la maqueta sea la base de intercambio de información funcional entre diseñadores y programadores. La semántica de tags puede ser más o menos prolija, y debe ir evolucionando hacia una reutilización extrema de código ya existente, pero no es un elemento que deba estar cerrado a priori.
La fragmentación en injertables almacenados en la bd junto a su versión calculada nos ofrece una serie de ventajas propias de un gestor de contenidos tradicional y otras propias de Plasmid- Net:
1) Los widgets pueden ser reutilizados entre páginas o sitios diferentes y editados individual- mente.
2) Los widgets pueden ser actualizados dinámicamente desde la web app si se detecta algún cambio en su versión (se descargan desde la bd). En el capítulo Navegador explicamos su interpretación desde la web app.
3) Pueden versionarse como otros elementos de la aplicación, de forma que un programador tenga acceso a una versión distinta a la que están utilizando los usuarios.
El entorno de administración gráfico que suministran los portales puede implementarse de dos maneras:
1) Administrando los widgets en aplicaciones especializadas en la maquetación de sitios web sencillos (como Bootstrap Studio).
2) Utilizando las utilidades de PlasmidNet.
La aplicación provee un proxy browsersync que facilita enormemente las pruebas ya que está configurado para reiniciar automáticamente el navegador ante cambios de javascript y html y sin necesidad de reinicio para inyectar en caliente los cambios en los css.
Un flujo de trabajo de construcción web en PlasmidNet es como sigue:
1) Levantar dos servidores web, uno con la aplicación y otro con la maqueta, ambos intercep- tados por browsersync.
2) Cualquier cambio en el software la maqueta dispara dos flujos, el refresco del proxy de manera que se visualiza inmediatamente y la generación de los widgets y la página principal que se distribuye automáticamente al sistema de archivos del servidor web de la aplicación. 3) El proxy del servidor web reacciona a los cambios y es reiniciado automáticamente.
El propio navegador Chrome ofrece muchas posibilidades para cambiar elementos HTML5 al vuelo sobre el propio navegador.
En definitiva, con las herramientas de automatización extrema, entre las que incluimos brow- sersync PlasmidNet proporciona un entorno muy ágil de trabajo que evita la necesidad de adquirir o incorporar nuevos productos.
6
Orquestador distribuido de tareas
6.1.
Planteamiento
No es suficiente que PlasmidNet sea capaz de resolver peticiones de usuario de respuesta inmediata. Es cierto que las operaciones de generación de los resultados de una consulta a la base de datos o la construcción de gráficos basados en esos datos pueden resolverse interactivamente con el usuario porque requieren unos pocos segundos de espera. Pero existen solicitudes que inevitablemente conllevarían tiempos de espera inasumibles para una interacción en tiempo real.
Necesitamos que nuestro sistema admita datos que el propio usuario aporte: nuevas secuencias de proteínas, nuevas secuencias de plásmidos, que deben ser analizadas funcionalmente, siguiendo un camino parecido a las secuencias que sirvieron para construir las agrupaciones funcionales originales de la aplicación, basadas en familias, superfamilias y módulos. Se requiere entonces volver a ejecutar procesos de alineamiento y clasificación, como los utilizados para la carga inicial de nuestra base de datos.
Del mismo modo es necesario que el mismo proceso inicial de carga de la base de datos de PlasmidNet sea fácilmente reproducible para adaptarlo con el mínimo esfuerzo a la evolución de las fuentes de información (bases de datos de plásmidos, proteínas, anotaciones) y a la mejora de las herramientas utilizadas (DFAST, MMseqs2, HHblits, . . . ) o a evoluciones de nuestro propio software de proceso.
Como estos procesos se componen de varios pasos en cada uno de los cuales se realiza una acción determinada y estos pasos han de ejecutarse en un determinado orden, necesitamos una forma de definir estas secuencias y una forma de lanzar ordenadamente su ejecución. Necesitamos un orquestador de tareas. También podríamos referirnos a este tipo de sistema como motor de flujos de trabajo, pero preferimos el término, más moderno, de orquestador porque explicita su función central: la coordinación.
Otro aspecto fundamental que queremos tener en cuenta es el de la reproducibilidad. No sólo nuestro orquestador debe poseer capacidades ejecutivas, también debe tener memoria. Es crucial contar con un sistema de descripción y configuración de flujos que podamos almacenar como parte de la documentación del proyecto. Si además incluimos uno o más pasos de estos flujos en imágenes docker, incluido el propio orquestador, tendríamos todos los elementos necesarios
para reproducir los resultados en cualquier plataforma. Además, en el servidor web de la webapp, necesitamos:
1) Recepción de solicitudes diferidas del usuario, junto a todos los datos relacionados: secuen- cias, ficheros,. . .
2) Identificar la solicitud con un código e informarlo al usuario.
3) Que el usuario pueda consultar el estado de su solicitud y consultar los resultados si ésta ha finalizado.
4) Que el sistema informe al usuario cuando la solicitud haya finalizado.
Nuestra primera tentación fue la de integrar una plataforma existente; NextFlow [25] parecía una buena opción. Opera sobre una máquina virtual de java, utiliza el lenguaje groovy y aporta una DSL para la definición de los flujos de trabajo. Pero la herramienta es compleja y ofrece mucho más de lo que en principio necesitamos: atentábamos inmediatamente contra el principio de homogeneidad: no solo precisábamos de otra plataforma, sino también de todo un entorno java para poder ejecutarla. El empaquetado mediante contenedores de este entorno facilitaría las cosas, pero ¿y si reutilizábamos de alguna forma lo que ya teníamos desarrollado en nodejs?. ¿Por qué no desarrollar las comunicaciones entre los diferentes contenedores implicados en el flujo reutilizando la capa de servicios REST que hemos implementado?.
6.2.
Definiciones
Nodo PlasmidNet o simplemente nodo, se refiere una instancia de servidor web Plas- midNet. Como tal escucha en un puerto determinado, y normalmente está desplegado sobre el sistema anfitrión como contenedor docker.
Flujo de trabajoo simplemente flujo o pipeline que es el término utilizado en el desarrollo. El flujo de trabajo es el conjunto de tareas a realizar para obtener un determinado resultado e incluye las dependencias de ejecución entre las mismas. Por tanto incluye una especificación de flujo.
Paso de ejecución, o simplemente paso, o step que es el término utilizado en el desarrollo. Constituye el elemento mínimo de ejecución. Es el elemento mínimo visto desde la coordinación, porque algunos de estos pasos despliegan internamente a su vez otro flujo interno, como en los provistos por DFAST o MMseqs2 en sus imágenes docker, donde se encadena la ejecución de varios trabajos.
Una solicitud de usuario, desencadena la ejecución de un flujo (pipeline), es decir, la ejecución de una tarea de usuario, o simplemente tarea (task como se denomina en el código). Cada tarea lleva asociada una especificación de flujo de trabajo (pipeline) y consta de pasos (steps) de ejecución.
El término tarea para referirnos a una operación solicitada por un usuario es un tanto desafortunado ya que también denominamos tareas a las diferentes operaciones publicadas sobre gulp(donde nos hemos dejado influenciar por la propia terminología de la plataforma gulp task). Incluso nos planteamos inicialmente utilizar el propio gulp para desarrollar los flujos. Esperamos que no cause confusión, y lo vamos a incluir como aspecto a mejorar en futuras refactorizaciones del código.