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 Universidad de Granada
Ramón Pérez Red de Información Ambiental
Blas M. Benito 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 para aquellas características necesarias para todas las

disciplinas.
● 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 cliente-

servidor 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~/kepler-
docs/user/app/getting-started-guide.pdf?rev=1.3&content-type=application/pdf
Kepler Actor Reference:
http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/kepler-
docs/user/app/ActorReference.pdf?rev=1.2&content-type=application/pdf
Kepler User Manual: http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/kepler-
docs/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/ssdbm04-
kepler.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