Kepler

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA Análisis y evaluación del sistema Kepler

AUTORES Francisco J. García-Bonet Raúl Casado Ramón Pérez Blas M. Benito

Universidad de Granada Red de Información Ambiental Centro Andaluz de Medio Ambiente

CONTENIDOS

Introducción..................................................................................3 ¿Qué es Kepler?............................................................................3 Características de Kepler.............................................................................4

Los flujos de trabajo en Kepler......................................................5 El lenguaje de modelado de Kepler...............................................7 Vergil, la interfase de Kepler..........................................................8 Requerimientos de hardware.....................................................................11 Algunos problemas conocidos....................................................................11

Los Directores.............................................................................11 Selección del Director adecuado................................................................12

Los Actores..................................................................................13 Control de flujo............................................................................15 Kepler y los Sistemas de Información Geográfica........................16 Hoja de ruta de Kepler.................................................................16 Algunos sistemas similares.........................................................17 Bibliografía..................................................................................18 Glosario.......................................................................................19

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Introducción En los últimos años, gracias al desarrollo de las tecnologías de comunicación y las infraestructuras de datos distribuidos, se ha incrementado la necesidad de interfases adaptables y herramientas para acceso a datos y ejecución de análisis complejos. Este tipo de análisis pueden ser modelados como flujos de trabajo descritos en un lenguaje formal. En este contexto se está produciendo un importante avance en el desarrollo de sistemas de diseño y ejecución de flujos de trabajo, capaces de proveer desde un mismo interfaz acceso a los datos, servicios y módulos de computación necesarios para cualquier tipo de análisis. Sistemas de estas características tienen una gran penetración en el sector académico, y en investigación genética y farmacológica, ya que posibilitan recogida, estructuración, procesamiento de grandes masas de datos y análisis y publicación de los resultados sin necesidad de recurrir a expertos en tecnologías de la información que diseñen los sistemas de análisis desde cero. Las características modulares de estos sistemas y la implementación de protocolos de transferencia de datos estandarizados los hacen muy flexibles para cualquier tipo de análisis, y esta flexibilidad le abre hueco en cualquier campo para el que se encuentre aplicación. En el presente trabajo analizamos en profundidad el sistema Kepler, una prometedora herramienta a tener en cuenta en el campo del análisis y gestión medioambiental.

¿Qué es Kepler? Kepler (http://kepler-project.org/) es un proyecto colaborativo (ver cuadro 1), de código abierto, que pretende proporcionar un “entorno de modelado y resolución de problemas”. Mas concretamente, se trata de un sistema diseñado para crear modelos ejecutables utilizando una representación visual de los procesos que implican. La representación gráfica de estos modelos, también llamadas flujos de trabajo muestra el flujo de datos entre los distintos componentes del análisis. Kepler está especialmente diseñado para dar soporte al flujo de datos en distintos dominios técnicos y científicos, como la bioinformática, la ecoinformática y la geomática entre otros, pero sus características pueden ser aplicadas a cualquier campo que requiera flujos de trabajo con datos para resolver problemas. Kepler combina perfectamente el diseño de alto nivel de flujos de trabajo con la ejecución e interacción en tiempo real, acceso a datos locales y remotos, invocación de servicios locales y remotos, con un control interno de concurrencia y un mecanismo de planificación. El sistema proporciona características para monitorizar la ejecución de flujos de trabajo, recuperación de fallos, y control de origen de servicios y datos. Kepler se basa en el sistema Ptolemy II (http://ptolemy.berkeley.edu/ptolemyII/), desarrollado en la Universidad de Berkeley. Este proyecto estudia el diseño e implementación de sistemas de computación, enfocándose en el ensamblado de componentes concurrentes. La clave del proyecto es la utilización de modelos de ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

1

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

computación que gobiernan las interacciones entre componentes. Kepler comparte con Ptolemy II la interfase gráfica, Vergil, y las capacidades de diseño, modelado y ejecución, pero extendiendo las funcionalidades de Ptolemy II, incluyendo un siempre creciente número de componentes orientados al análisis y procesamiento de datos, como plug-ins para trabajar con bases de datos, para comunicarse con otras aplicaciones, computación GRID, extensiones de programación, transformación de datos, creación de metadatos, etc... Cuadro 1: Entidades colaboradoras en el proyecto Kepler SEEK: Science Environment for Ecological Knowledge (http://seek.ecoinformatics.org/). GEON: Geosciences Network (www.geongrid.org). ROADNet: Real-time Observatories, Applications, and Data management Network (http://roadnet.ucsd.edu). EOL: Enciclopedia Of Life (www.eol.org). CIPRES: Cyberinfraestructure for Phylogenetic Research (www.phylo.org). REAP: Real-time Environment for Analytical Processing (http://reap.ecoinformatics.org). Kepler CORE: NCEAS (www.nceas.ucsb.edu), UC Davis, UC Santa Barbara y UC San Diego.

El proyecto está cofinanciado por la NSF (National Science Foundation, www.nsf.gov), el DOE (Department of Energy, www.energy.gov) y DARPA (Defense Advanced Research Projects Agency, www.darpa.mil). El soporte logística está a cargo del NCEAS (Nacional Center for Ecological Analysis and Synthesis, http://www.nceas.ucsb.edu/).

Características de Kepler ●

Kepler es multiplataforma: El sistema está programado en Java, por lo que solo es necesario tener el entorno de ejecución instalado para que Kepler funcione en cualquier sistema operativo. Sin embargo, la plataforma tiene influencia en el desempeño de Kepler: Windows solo puede ceder 1.4 Gb de memoria RAM a Java, mientras que los entornos basados en UNIX (Linux, BSD, MacOS) le pueden proporcionar mayores cantidades de RAM. Esta cuestión es de gran importancia cuando se trabaja con información SIG, debido a los grandes tamaños de archivo que son habituales en esta disciplina.

●

Kepler es extensible: Su código abierto y carácter modular permiten a cualquier usuario con conocimientos en Java implementar nuevos módulos. En este aspecto el sistema no tiene restricciones, y puede ser modificado y extendido a voluntad. Por otra parte, las condiciones exigidas por el equipo que desarrolla Kepler a sus programadores aseguran la legibilidad e interpretabilidad del código, facilitando la labor de programación de nuevas extensiones.

●

Kepler es flexible: La gran cantidad de componentes de modelado, el acceso a todo tipo de servicios y las posibilidades infinitas de interconexión entre módulos de procesamiento permiten que Kepler, aunque está diseñado en el ámbito científico, pueda ser aplicado a cualquier campo técnico, como la gestión ambiental.

●

Los módulos de procesamiento y los flujos de trabajo programados con Kepler son fácilmente intercambiables y versionables, a través de su formato de archivo propio KAR (Kepler ARchive format). Además pueden utilizarse sobre otras plataformas de modelado afines, ya que comparten el lenguaje de intercambio MoML (Modeling Markup Language).

●

Kepler trabaja con metadatos: La existencia de metadatos en formatos estándar (EML, Darwin Core y otros) facilita mucho el trabajo con Kepler, que puede

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

2

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

configurar automáticamente los módulos de procesamiento para que se adapten a las características del conjunto de datos descrito por los metadatos. ●

Kepler conecta con otros programas: Utilizando JNI (Java Native Interface), Kepler puede conectar con programas escritos en otros lenguajes instalados en el sistema para realizar tareas específicas.

●

Ejecución distribuida: Kepler permite acceder a servicios web que se integran en los flujos de trabajo como módulos de procesamiento. Esta capacidad le permite aprovechar cualquier tipo de servicio, siempre que el servidor permanezca en línea.

●

Kepler permite la ejecución por lotes: los flujos de trabajo de Kepler pueden ejecutarse por lotes y en segundo plano, permitiendo al usuario una utilización aceptable de su sistema para otras tareas mientras el programa ejecuta el flujo.

●

Librerías de componentes extensible y personalizada: Kepler tiene una extensa librería por defecto, que puede ser ampliada mediante búsquedas en el repositorio de Kepler, intercambio de módulos con otros usuarios y programación específica de módulos. Además la librería local está preparada para que el usuario pueda configurarla según los módulos que mas habitualmente utiliza.

●

Distintos modelos de computación: Kepler puede ejecutar los flujos de trabajo según distintos patrones adaptados a las necesidades del flujo; secuencialmente, en paralelo, dependiente del tiempo real...

●

Kepler posee un interfaz amigable, que facilita el diseño visual y la ejecución de los flujos de trabajo.

●

Soporte para multitud de fuentes de datos: Kepler está preparado para trabajar con datos de todo tipo, independientemente de su estructura o tamaño. Ya sean datos tabulados en hojas de cálculo, texto plano, binarios o matrices (entre muchos otros), el sistema tiene módulos de importación prácticamente para todo. Por supuesto soporta acceso local y remoto a bases de datos como Oracle o MS Access, entre otras.

Los flujos de trabajo en Kepler Como flujo de trabajo puede entenderse una red de procesos analíticos, que puede ser simple y lineal, o muy compleja y no lineal, diseñada para trabajar sobre un conjunto heterogéneo de datos, en el que tanto el flujo de datos como los componentes que los procesan son representados según un lenguaje formal específico. Kepler se aplica a flujos de trabajo con gran volumen de datos, altos requerimientos computacionales, transformación de datos, análisis y simulación. Kepler hereda de Ptolemy II el paradigma de modelado orientado a actores, que diferencia los componentes del flujo de trabajo y enfatiza la concurrencia y comunicación entre actores, que están gobernado por un “director”. Un flujo de trabajo tiene una serie de componentes formalmente descritos (algunos están representados visualmente sobre la interfase de Kepler en la Figura 1): ●

Director: Controla la ejecución del flujo de trabajo basándose en un modelo de computación concreto, y determina en que modo los “actores” se comunican

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

3

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

entre sí. El modelo de computación de cada Director determina cuántas veces se ejecuta el flujo (iteraciones), si se ejecuta secuencialmente o en paralelo, y las características concretas del tipo de ejecución. Por ejemplo el Director SDF (Synchronous Dataflow Network) se ha diseñado para ejecutar flujos multihilo cuya secuencia de ejecución está predeterminada (se sabe en que momento se inicia cada paso del flujo), mientras que el Director PN (Process Network) permite ejecutar flujos multihilo gestionando dinámicamente la secuencia de ejecución. Dentro de un flujo de trabajo pueden existir distintos niveles, cada uno con un Director específico, dependiendo de los requerimientos computacionales del nivel. ●

Actor: Es el elemento fundamental de un flujo de trabajo, y Kepler lleva incluidos unos 350 en su librería. El actor es una unidad computacional que tiene puertos de entrada a través de los cuales se alimenta de datos, un núcleo de procesamiento que opera con los datos, y puertos de salida, que ofrece los datos transformados a un nuevo actor. Un actor puede ser configurado mediante sus parámetros, y añadiéndole puertos. Una serie de actores conectados forman un flujo de trabajo. El conjunto de actores de un flujo toma las instrucciones de ejecución del director. Kepler incluye actores con capacidades matemáticas, estadísticas, procesamiento de señales, entrada, manipulación y salida de datos, conexiones con otros programas como R, Matlab o Grass. Los actores tienen un comportamiento polimórfico según el cuál se adaptan a las condiciones de ejecución y comunicación establecidas por el director. Por ejemplo, el actor ficticio PLUS, para sumar operandos, bajo el director SDF (Synchronous Data-Flow) funcionaría en el momento en que todos los puertos de entrada tuvieran datos, mientras que bajo el director DE (Discrete Event systems), la suma se realizaría en cuanto cualquier puerto tuviera datos.

●

Actor compuesto (composite actor): Es un conjunto de actores unidos en un subflujo de trabajo (también denominado “flujo anidado”) que se representa como un solo actor pero computa operaciones complejas. Los “actores compuestos opacos” contiene su propio director, mientras que los “actores compuestos transparentes” son regidos por el director del flujo de trabajo. Son útiles porque pueden guardarse como actores para su reutilización, y además proporcionan claridad para interpretar flujos de trabajo muy complejos.

●

Receptores (receivers): Median en la comunicación entre actores, y son proporcionados por el director.

●

Parámetros: Son valores configurables que pueden ser asignados a un flujo de trabajo, a un director o a un actor. Controlan aspectos clave de las simulaciones, como valores iniciales.

●

Relaciones: Permiten ramificar flujos de datos, para enviar los mismos datos a distintos lugares del flujo de trabajo.

●

Puertos: Conectan los actores entre sí, para la entrada y salida de datos. Los puertos pueden ser de entrada, salida, o entrada/salida. Además, cada puerto puede conectarse a un solo puerto de otro actor, o a varios puertos de varios actores (multipuerto). Los “puertos externos” son utilizados para conducir datos desde un actor compuesto al flujo que lo contiene.

●

Canal: Es el vínculo que representa el flujo de datos entre puertos de actores distintos.

●

Paquetes de datos (tokens): Los canales transportan los datos encapsulados

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

4

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

como “tokens”. Cada token tiene asignado un tipo de datos concreto (enteros, coma flotante, etc). Un flujo de trabajo implementado en Kepler tiene las siguientes características: ●

Diseño abstracto y jerarquizado del flujo de trabajo.

●

Representación visual comprensiva y modelado conceptual de todos los elementos del flujo de trabajo.

●

Planificación y gestión de la ejecución de los flujos de datos según distintos modelos computacionales.

●

Computación intensiva y eficiente.

●

Uso transparente de recursos y servicios locales y remotos.

●

Implementabilidad en cualquier plataforma de software.

●

Reproducibilidad de análisis con bajo esfuerzo.

●

Reutilización de elementos de flujos ya existentes.

●

Documentación conveniente de todos los aspectos del análisis.

●

Flexibilidad para la inspección de resultados “al vuelo”.

●

Fácil reestructuración y parametrización del flujo.

●

Se puede incluir en un repositorio para ser utilizado por otras personas.

El lenguaje de modelado de Kepler MoML (Modeling Markup Language) es un esquema XML diseñado para interconectar componentes parametrizados utilizado por Kepler como lenguaje para construir los flujos de trabajo. Está heredado de Ptolemy, y tiene las siguientes características: ●

Integración WEB: está diseñado para su uso en internet, las referencias a archivos se hacen mediante URLs tanto relativas como absolutas.

●

Independiente de la implementación: MoML está diseñado para trabajar con distintas herramientas de modelado.

●

Extensibilidad: Los componentes se parametrizan de dos modos; a) pueden tener propiedades con nombre representadas por cadenas de caracteres; b) se pueden asociar con un archivo externo de configuración que puede estar en cualquier formato entendible por el componente. Típicamente será otro XML schema, como PlotML o SVG (Scalable Vector Graphics).

●

Clases y herencia: Los componentes pueden definirse en MoML como clases que después pueden ser instanciadas en el modelo. Los componentes pueden extender otros componentes a través de un mecanismo de herencia orientado a objetos.

●

Independencia semántica: MoML no define semánticas para la interconexión de componentes. Representa únicamente las relaciones jerárquicas entre entidades con sus propiedades, puertos y canales. Es el director el que define la semántica de las interconexiones.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

5

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Vergil, la interfase de Kepler Vergil es un editor de flujos de trabajo basado en Java, heredado de Ptolemy II. A través de Vergil el usuario interacciona amigablemente con el sistema Kepler para construir y ejecutar flujos de trabajo, arrastrando y soltando componentes desde el panel lateral al espacio de trabajo, y conectándolos entre sí (ver Figura 1). El menú de Vergil proporciona acceso a todas las funciones de Kepler, algunas de la cuáles (las mas utilizadas) se encuentran en la barra de herramientas. Entre estas se encuentran las relacionadas con la navegación del espacio de trabajo y ejecución del flujo de trabajo. El panel lateral (área de componentes y datos) de Kepler da acceso a los componentes del flujo de trabajo y a los datos, proporcionando un interfaz de búsqueda basado en ontologías de dominios de aplicación. Bajo el panel lateral está el navegador, que permite situar la vista principal en cualquier lugar de un flujo de trabajo extenso. El espacio de trabajo es el lugar donde se diseña el flujo de trabajo.

Figura 1: Vergil, estructura de la interfase y componentes de un flujo de trabajo.

Los distintos actores pueden ofrecer sus salidas en ventanas diferentes según se trate de texto, gráficos descriptivos o imágenes (ver Figura 2). ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

6

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Para cada elemento disponible en el panel lateral o en el área de trabajo Kepler dispone de una descripción detallada de sus funciones y parámetros asociados, que se despliega como una ventana de documentación (ver Figura 3). Las fuentes de datos pueden (deben) llevar metadatos escritos según el lenguaje EML (Ecological Metadata Languaje; http://knb.ecoinformatics.org/software/eml/). Los metadatos asociados a un conjunto de datos pueden visualizarse desde Kepler, tal y como muestra la Figura 4.

Figura 2: Ejemplos de ventanas de salidas de los actores Image y Display del flujo de trabajo representado en la Figura 1.

Figura 3: Ventana de documentación de un elemento de Kepler, en este caso el Director SDF.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

7

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Figura 4: Vista de los metadatos de la base de datos “Datos meteorológicos” representada en el flujo de trabajo de la Figura 1. ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

8

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Vergil permite abrir varias instancias de la interfase con distintos flujos de trabajo abierto (aunque solo uno puede estar ejecutándose) para copiar y pegar componentes de un flujo a otro. Una descripción exhaustiva de la utilización de Vergil está fuera del objetivo del presente informe, pero para profundizar en su uso pueden consultarse los siguientes documentos (reseñados en la bibliografía): Kepler User Manual, y Kepler Getting Started Guide.

Requerimientos de hardware Kepler y su interfase Vergil están escritos en java, un lenguaje interpretado con ciertos requerimientos de hardware. Para correr Kepler sin problemas se recomiendan: ●

300 Mb de disco libres.

●

1 GB de RAM.

●

CPU 2GHz.

●

Java 1.5.x.

●

Conexión a internet.

●

R instalado en la computadora (no necesario en versiones windows).

Algunos problemas conocidos Al estar programado en un lenguaje interpretado y funcionar sobre una máquina virtual, Kepler consume muchos recursos, por lo que necesita máquinas relativamente potentes (PCs actuales de gama media) para ejecutarse sin problemas. La implementación actual del código de Kepler lo hace ineficiente para procesar datos organizados en matrices tridimensionales. Para cubrir estas necesidades son mas adecuados entornos orientados a matrices como SciLab, Octave o Matlab.

Los Directores Kepler permite ejecutar flujos de trabajo utilizando distintos modelos de computación, representados por los Directores. Distintos flujos pueden operar mas o menos eficientemente según el Director que les sea asignado, por lo que es de gran importancia conocer las características de los Directores. Director PN (Process Networks): En los flujos dirigidos por este director los actores funcionan como procesos independientes que se ejecutan concurrentemente, cada uno con su propio hilo de control, y se comunican entre sí mediante canales unidireccionales. El volumen de escritura de datos en un canal no está limitado, pero la lectura de datos si puede estarlo, e iniciarse el actor cuando tiene suficientes datos. El Director PN no precalcula el plan de trabajo de los actores, por lo que los flujos de trabajo gobernados por este director tienen muy pocas restricciones, pero pueden se muy ineficientes. Este director puede ocasionar resultados inesperados, como la terminación automática de un flujo cuando un actor pasa demasiada información a otro, ocasionando desbordamiento de memoria.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

9

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Director SDF (Synchronous Data-Flow): Se utiliza para redes de procesos especializadas con una producción y consumo fijos de datos entre actores. Permite análisis estáticos en flujos de datos que garantizan la ausencia de caminos muertos, determinando de antemano los tamaños de buffer requeridos y optimizando la organización de la ejecución de los actores. Es muy eficiente para sistemas en los que el flujo de datos es constante y conocido. No tiene en cuenta el factor tiempo, lo que debe tenerse en cuenta para aquellos actores que necesitan este factor. Es apropiado para flujos simples, como el formateo de datos tabulares, conversión entre tipos de datos, lectura y ploteado de series de datos. El Director SDF controla el número de veces que el flujo es iterado, mediante el valor de su parámetro iterations (0=infinitas iteraciones!). Este Director asume que cada actor consume o produce un paquete de datos por iteración del flujo, por lo que los actores que no cumplen con esta norma deben declarar el número de paquetes que producen o consumen. Este director puede configurarse mediante el parámetro vectorizacionFactor, que incrementa el número de acciones de los actores por cada iteración del flujo. Director DE (Discrete Event systems): Está diseñado para la simulación y modelado de sistemas dependientes del tiempo. Los actores se comunican a través de secuencias de eventos situados en una línea de tiempo real. Cuando en el flujo existen actores que necesitan sus propios datos (en bucles autoalimentados) se puede producir un error de camino muerto (deadlock). Para solucionarlo, a estos actores se les antepone el actor TimedDelay para generar unos datos de partida que inicialicen el bucle. Este Director tiene los parámetros startTime y stopTime para determinar la ventana temporal de trabajo. El parámetro stopWenQueueIsEmpty, cuando tiene el estado false, previene la finalización de la ejecución cuando el flujo se queda sin eventos. Director CT (Continuous-Time models): Está diseñado para modelar sistemas que predicen como evolucionan los sistemas en función del tiempo (sistemas dinámicos) gobernados por sistemas de ecuaciones diferenciales lineales y no lineales. Este director calcula el tamaño de los pasos de integración y puede utilizar distintos algoritmos para resolver las ecuaciones diferenciales ordinarias (ODE Solver Algorithm): ExplicitRK23Solver, ExplicitRK45Solver, BackwardEulersolver y ForwardWulerSolver. Cada uno tiene distinto desempeño y precisión; los dos primeros funcionan con paso variable, cuando el director puede cambiar el tamaño de paso de acuerdo a la estimación del error. Los dos últimos son de paso fijo, en los que el usuario especifican el tamaño de paso. El tamaño de paso se configura mediante los parámetros initStepSize, maxStepSize y minStepSize. El parámetro timeResolution permite ajustar el compromiso entre velocidad y precisión del algoritmo, garantizando que no se utilicen innecesariamente tamaños de paso demasiado pequeños. Director DDF: En flujos con bucles o ramificaciones, u otras estructuras de control, que no requieren procesamiento en paralelo. Este director ejecuta el flujo en un solo hilo, como el SDF, pero no precalcula el plan de ejecución, y la producción y consumo de datos de los actores puede variar durante la ejecución. Es útil para diseñar flujos con estructuras de control que no requieren procesamiento en paralelo y que utilizan interruptores booleanos en alguna de estas estructuras o en una ramificación.

Selección del Director adecuado Ante esta diversidad de directores, puede seguirse un algoritmo de selección como el representado en la Figura 5.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

10

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Figura 5: Selección de un Director apropiado según la naturaleza del flujo de trabajo.

Los Actores Kepler dispone de un Repositorio de Componentes Analíticos, del que los usuarios pueden descargar componentes de flujo desde el interfaz del programa. Estos actores pueden ser instanciados en el espacio de trabajo, o ser guardados a la librería local de recursos. Los actores correspondientes a una misma familia están representados por iconos concretos que identifican su función. Estos iconos facilitan la interpretación visual de los flujos de trabajo, una vez que se conocen apropiadamente. Los actores de Kepler están escritos en java, pero cualquier código escrito en lenguajes distintos a java pueden ser incluidos en kepler encapsulando el código en java. Cualquier usuario con conocimientos de java puede generar el código para compilar e incluir en Kepler un nuevo actor. Kepler dispone de un formato de archivo propio para guardar componentes y flujos completos, KAR (Kepler Archive Format) que permite compartirlos fácilmente Estos ficheros pueden ser importados desde el interfaz del programa. A continuación se presenta una pequeña lista de actores y sus utilidades, que solo tiene como objetivo mostrar algunas de las capacidades que los actores pueden proporcionar a los flujos de trabajo. ●

BinaryFileReader: Lee archivos binarios y ASCII, devolviendo el resultado como cadenas.

●

DarwinCoreDataSource: Importa metadatos de Darwin Core.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

11

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

●

DatabaseQuery: Permite realizar consultas sobre una base de datos.

●

DBConnect: Conecta con una base de datos local o remota.

●

EML2Dataset: Este actor entiende el lenguaje de metadatos EML, y captura la metainformación cuando un conjunto de datos es accedido local o remotamente, transmitiendo los datos a los actores siguientes. Este actor configura sus puertos de salida para que correspondan con los campos de la base de datos descritos por los metadatos. Cada vez que el actor se ejecuta, exporta una fila de datos a través de sus puertos. EML2Dataset puede descomprimir conjuntos de datos, y exportarlos a distintos formatos. Por ejemplo, puede ser configurado para crear un puerto que transmita toda la tabla en formato csv. Este actor dispone de la posibilidad de filtrar datos mediante consultas SQL a través de un constructor de consultas "Query Builder", al que se accede desde las preferencias del actor.

●

ExpressionReader: Lee archivos línea por línea, y evalúa cada línea como una expresión de Kepler.

●

ExternalExecution: Se utiliza para lanzar aplicaciones externas desde un flujo de Kepler. El actor puede pasar valores a la aplicación y recoger los resultados para enviarlos a los siguientes actores. La aplicación invocada debe estar instalada localmente y en ocasiones, correctamente configurada. El parámetro directory permite especificar el directorio de trabajo. El parámetro command sirve para introducir la acción que deseamos que realice el programa externo.

●

FileReader: Devuelve el contenido de un archivo como una única cadena de texto. Puede tomar entrada desde un parámetro del flujo de trabajo.

●

FileToArrayConverter: Lee cada línea de un archivo y devuelve una columna de datos con los valores.

●

GDALFormatTranslator: Convierte entre distintos formatos SIG usando GDAL.

●

GDALWarpAndProjection: Convierte entre distintas proyecciones geográficas usando GDAL.

●

GridREscaler: Homogeiniza extensión y resolución de capas SIG. Utiliza los algoritmos Nearest Neighbor y Inverse Distance. Este actor puede realizar las operaciones directamente sobre disco duro, evitando problemas de memoria sobre capas muy grandes, pero ralentizando el proceso. Esta opción puede desmarcarse para acelerar el cálculo.

●

Harvester: Se le proporciona una URL de un repositorio de servicios, y el Harvester recoge y analiza todos los archivos WSDL del repositorio, creando instancias de actores de servicio web en la librería local de actores. El Harvester facilita un rápido prototipado y desarrollo de aplicaciones basadas en servicios web.

●

ImageDisplay: Muestra en pantalla una imagen o un gráfico (de un análisis estadístico).

●

ImageJ: Lee una imagen y la abre junto a una barra de herramientas para procesarla. En http://rsb.info.nih.gov/ij/macros/ hay una librería de macros para este actor.

●

LineReader: Lee un fichero línea a línea (una por iteración), y devuelve una cadena por línea. Útil para leer listados secuencialmente según itera el flujo de trabajo.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

12

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

●

MergeGrid: Se utiliza para combinar dos imágenes SIG, según distintas operaciones (media, suma, resta, mascara). También permite hacer mosaicos de imágenes).

●

OpeNDAP: Se utiliza para acceder a fuentes de datos DAP 2.0. (Data Access Protocol). Recoge los datos especificados y automáticamente configura sus puertos para emitir datos al siguiente actor. A este actor se le indica la URL desde la que lee los datos y una expresión constante (CE) que permite especificar un subconjunto de datos que descargar.

●

OpenDatabaseConnection: Abre una conexión con una base de datos indicándole el formato de la base de datos, URL, usuario y contraseña.

●

Ramp: El actor Ramp funciona como una orden “for loop”, que ejecuta una operación un número determinado de veces. El actor Ramp también es útil cuando se utiliza el director PN, porque este director no permite configurar iteraciones. El número de iteraciones está controlado por el parámetro firingCountLimit , y son controladas incrementando un índice progresivamente. Los parámetros init y step controlan la magnitud del incremento de este índice. Este actor puede utilizarse como contador, o para generar un nombre de archivo por cada iteración del flujo.

●

ReadTable: permite acceder a datos guardados en formato .xls de MS Excel.

●

SampleDelay: Permite la inicialización de un bucle proporcionando una señal de inicio. Evita los caminos muertos en bucles que necesitan datos del mismo bucle (bucle autoalimentado). El valor inicial que proporciona se configura mediante el parámetro initialOutputs. En las siguientes iteraciones este actor solo deja pasar datos, pero no produce ninguno.

●

SimpleFileReader: Lee y devuelve el contenido de un archivo como una sola cadena. Solo toma datos de otro componente del flujo, y no puede hacerlo desde un parámetro del flujo.

Control de flujo Los flujos de trabajo de Kepler pueden tener una gran complejidad, dependiendo del análisis a realizar. Para abordar cualquier peculiaridad de un análisis complejo Kepler dispone de posibilidades para controlar el flujo de información y diseñar estructuras de control. Entre las estructuras de control mas importantes en los flujos de Kepler están las ramificaciones, determinadas por el elemento “Relación”, y las estructuras denominadas bucles (o “loops” en lenguaje informático). Un bucle permite a un flujo iterar, reenviando información a actores situados corriente arriba. Las herramientas adecuadas para iterar y generar bucles en flujos de trabajo son: ●

Iteraciones del director SDF: Configurando el director para que realice varias iteraciones (parámetro iterations > 1) el flujo puede realizar n iteraciones independientes (el resultado de una iteración no depende de los resultados de iteraciones previas). Flujos con actores como LineReader, para transformar series de valores leídos de un archivo son los apropiados para esta técnica.

●

Actores Ramp y Repeat: Ambos actores permiten diseñar estructuras de control gobernadas por un índice determinado por los parámetros de Ramp, y repetir las iteraciones un número de veces determinadas por el actor Repeat.

●

Listados: Los listados de datos permiten procesar series de valores sin

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

13

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

necesidad de iterar. Los actores Expression y los actores R están diseñados para procesar matrices. ●

Bucles retroalimentados: Consisten en iteraciones que dependen de los valores de iteraciones anteriores. Requieren el actor SampleDelay para proporcionar un paquete de datos inicial.

Kepler y los Sistemas de Información Geográfica Entre las capacidades de Kepler se incluye la posibilidad de diseñar flujos de trabajo basados en información geoespacial para el modelado ambiental. En este ámbito, para la importación de formatos raster Kepler utiliza la librería GDAL, que le da soporte para mas de 40 especificaciones diferentes. Esta librería también proporciona utilidades básicas de procesamiento para capas raster. En la librería estándar de Kepler pueden encontrarse actores orientados al procesamiento de información geoespacial, como operadores aritméticos, elaboración de mosaicos, cambio de resolución, y visualización de capas. Estas capacidades están complementadas por otros actores diseñados para trabajar con información vectorial, en formato SHP de ESRI, o GML (Geographic Markup Language). Si bien el número de actores relacionados directamente con información geográfica en Kepler es reducido (sobre todo si comparamos con paquetes de software específicos de esta disciplina), existen al menos dos circunstancias que favorecen la utilización de Kepler para análisis espaciales complejos: 1. Acceso a servicios geoespaciales vía servicio web: La cantidad y calidad de los servicios web orientados a la publicación y tratamiento de la información geográfica está creciendo exponencialmente, y las posibilidades de Kepler para acceder a todos esos servicios incluyéndolos como actores en los flujos de trabajo incrementa sus competencias en la disciplina SIG. Como ejemplo, Kepler es capaz de trabajar con datos proporcionados por el servicio ArcIMS, el servidor de datos SIG para internet desarrollado por ESRI. 2. Interacción de Kepler con otros programas: Kepler puede trabajar en conjunto con programas SIG instalados en el sistema susceptibles de ser gobernados mediante línea de comandos. Como ejemplo, el SEEK (Science Environment for Ecological Knowledge, http://seek.ecoinformatics.org/) está desarrollando actores SIG basados en rutinas de GRASS, un sistema SIG muy potente. En este mismo aspecto, una interacción potencial aún por desarrollar es la que Kepler podría tener con gvSIG (www.gvsig.gva.es) y su extensión raster Sextante (www.sextantegis.com), un binomio gratuito y libre, enteramente escrito en Java, que está en continuo crecimiento. Estas posibilidades pueden dotar a Kepler de todas las funcionalidades SIG necesarias para un buen desempeño en flujos de trabajo diseñados para el modelado ambiental.

Hoja de ruta de Kepler Kepler está en continuo desarrollo, y para la próxima versión se está trabajando para implementar algunas de estas nuevas características: ●

Favorecer que múltiples grupos de distintas disciplinas puedan crear fácilmente, soportar y poner a disposición pública extensiones para Kepler específicas para distintos dominios.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

14

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

●

Mejor soporte disciplinas.

para

aquellas

características

necesarias

para

todas

las

●

Extensibilidad independiente: Favorecer la extensibilidad del sistema dividiendo el sistema en; a) el kernel (conjunto mínimo de componentes funcionales); b) conjuntos de actores para distintas disciplinas. En este sentido se está desarrollando un sistema de configuración que soporte la descarga, instalación y actualización del kernel de Kepler y de paquetes, extensiones y actores.

Algunos sistemas similares Kepler no es en ningún modo el único producto de modelado disponible, y a continuación se presentan algunas alternativas. ●

SCI-tegic: (http://accelrys.com/products/scitegic/): Potente plataforma clienteservidor de código cerrado que permite construir flujos de trabajo combinando gráficamente componentes para captura, filtro, y análisis de datos.

●

SCIRun (http://software.sci.utah.edu/scirun.html): Programa de código abierto y gratuito, para simulación 3D y análisis de imagen.

●

Kensington Discovery Edition (www.scimax.de/): Plataforma informática diseñada para soportar flujos de información a gran escala para la investigación en ciencias de la vida. Especializado en minería de datos y visualización.

●

Taverna (http://taverna.sourceforge.net/): Herramienta de código abierta gratuita para diseño y ejecución de flujos de trabajo. Utiliza SCUFL (Simple Conceptual Unified Flow Language) para expresar los flujos de datos. Orientado a la utilización de recursos en red, y análisis de secuencias de ADN y otras utilidades de bioinformática molecular.

●

Triana (http://www.trianacode.org/index.html). Entorno de resolución de problemas de código abierto y gratuito, que combina una interfase intuitiva con un conjunto de potentes herramientas de análisis. Procesamiento de señales, texto e imágenes. Permite integrar herramientas propias.

●

Pegasus (http://pegasus.isi.edu/). Código libre y gratuito. Permite construir flujos de trabajo en términos abstractos. Se utiliza en astronomía, biología y geología principalmente.

●

Simulink (www.mathworks.com/products/simulink/): Plataforma propietaria de modelado, implementada como una extensión del entorno computacional Matlab. Permite modelar, simular y analizar sistemas dinámicos en múltiples dominios.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

15

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Bibliografía Kepler User FAQ: www.kepler-project.org/Wiki.jsp?page=UserFAQ Kepler Project FAQ: http://kepler-project.org/Wiki.jsp?page=ProjectFAQ Getting Started Guide: http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/keplerdocs/user/app/getting-started-guide.pdf?rev=1.3&content-type=application/pdf Kepler Actor Reference: http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/keplerdocs/user/app/ActorReference.pdf?rev=1.2&content-type=application/pdf Kepler User Manual: http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/keplerdocs/user/app/UserManual.pdf?rev=1.5&content-type=application/pdf Iterations in Kepler: www.kepler-project.org/Wiki.jsp?page=Kepler_Iterations Directors in Kepler: www.kepler-project.org/Wiki.jsp?page=DirectorsInKepler Collection-Oriented Scientific Workflows for Integrating and Analyzing Biological Data, T. McPhillips, S. Bowers, B. Ludäscher. In 3rd International Conference on Data Integration for the Life Sciences (DILS), LNCS/LNBI 2006. http://daks.ucdavis.edu/~sbowers/McPhillips_et_al_DILS06.pdf Scientific Workflow Management and the Kepler System, B. Ludäscher, I. Altintas, C. Berkley, D. Higgins, E. Jaeger-Frank, M. Jones, E. Lee, J. Tao, Y. Zhao, Concurrency and Computation: Practice & Experience, 18(10), pp. 1039-1065, 2006. http://www.sdsc.edu/%7Eludaesch/Paper/kepler-swf.pdf Actor-Oriented Design of Scientific Workflows, S. Bowers, B. Ludaescher, 24th Intl. Conf. on Conceptual Modeling (ER'05), LNCS 3716, Springer, 2005. http://daks.ucdavis.edu/~sbowers/bowers_SWF_er05.pdf Kepler: An Extensible System for Design and Execution of Scientific Workflows, I. Altintas, C. Berkley, E. Jaeger, M. Jones, B. Ludäscher, S. Mock, system demonstration, 16th Intl. Conf. on Scientific and Statistical Database Management (SSDBM'04), 21-23 June 2004, Santorini Island, Greece. http://www.sdsc.edu/~ludaesch/Paper/ssdbm04kepler.pdf Ptolemy II Frequently Asked Questions: http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm C. Brooks, E.A. Lee, X. Liu, S. Neuendorffer, Y. Zhao, H. Zheng (eds.), "Heterogeneous Concurrent Modeling and Design in Java (Volume 1: Introduction to Ptolemy II)," EECS Department, University of California, Berkeley, UCB/EECS-2008-28, April 1, 2008. http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-28.pdf C. Brooks, E.A. Lee, X. Liu, S. Neuendorffer, Y. Zhao, H. Zheng (eds.), "Heterogeneous Concurrent Modeling and Design in Java (Volume 2: Ptolemy II Software Architecture)," EECS Department, University of California, Berkeley, UCB/EECS-2008-29, April 1, 2008. http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-29.html

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

16

DISEÑO Y CREACIÓN DE UN REPOSITORIO DE MODELOS PARA LA RED DE INFORMACIÓN AMBIENTAL DE ANDALUCÍA

Glosario Computación GRID: Sistema de computación distribuido que permite compartir recursos no centrados geográficamente para resolver problemas de gran escala. Ver en Wikipedia. Darwin Core (DwC): es un estándar diseñado para facilitar el intercambio de información acerca de la ocurrencia geográfica de especies, y la existencia de especímenes en colecciones. Ampliar información. EML (Ecological Metadata Languaje): Es una especificación de metadatos desarrollada para disciplinas relacionadas con la ecología. El lenguaje está implementado como una serie de tipos de documentos XML que se utilizan para documentar datos ecológicos. Ampliar información. GDAL (Geospatial Data Abstraction Library): Librería gratuita de código abierto que facilita la interconversión entre distintos formatos SIG raster (mas de 40). Además de cambios de formato, la librería provee herramientas para procesamientos básicos. Ver en www.gdal.org. GRASS (Geographical Resources Analysis Support System): Software con capacidades SIG utilizado para la captura, procesamiento, almacenamiento y análisis de información geoespacial. Es un proyecto oficial de la Open Source Geospatial Foundation, y se está extendiendo en el ámbito académico y comercial. Es muy versátil y potente, y aunque ha tenido fama de ser poco amigable, esta circunstancia ha cambiado y actualmente supone una competencia importante para otros programas del ramo, como Idrisi. Ampliar información. JNI (Java Native Interface): Permite a un programa escrito en Java interactuar con programas escritos en otros lenguajes. Ver en Wikipedia. Matlab (MATrix LABoratory): Lenguaje de computación numérica y entorno de desarrollo especializado en el cálculo matricial, el modelado de sistemas y la implementación de algoritmos. Está diseñado y producido por la compañía The MathWorks. Es muy utilizado en el ámbito científico y académico, aunque las licencias son muy costosas. R: Lenguaje de programación orientado a objetos y entorno de software para el cálculo estadístico y la composición de gráficos. Soporta una gran cantidad de funciones estadísticas y técnicas numéricas, que son desarrolladas por la comunidad científica y puestas a disposición del público (software libre y gratuíto). Destaca por su flexibilidad y potencia, y es el software libre estadístico de elección en el ámbito académico. Ampliar información. WSDL (Web Services Description Languaje): Es un formato XML que se utiliza para describir servicios Web. Describe los requisitos del protocolo y los formatos de comunicación necesarios para interactuar con el servicio que describe. Ver en Wikipedia.

ANÁLISIS Y EVALUACIÓN DEL SISTEMA KEPLER

17