Keywords
kepler workflow, web processing service, scientific workflow
Start Date
1-7-2010 12:00 AM
Abstract
The Open Geospatial Consortium (OGC) - Web Processing Service (WPS) providesan interface for distributed geoprocessing: from discovery and description of available processes,description of input and outputs, to execution and retrieval of results. While the integration of variousgeoprocessing libraries into WPS implementations negates the need to redevelop commonalgorithms, authoring of processes for the WPS is still very much in the hands of the softwaredeveloper, rather than the scientist. We propose that by integrating a workflow execution engine(in our case, Kepler) as a WPS processing engine, process content authoring becomes more accessibleto the scientist. Existing geoprocessing framework integration solutions have a large relianceon additional user-generated metadata to properly define capabilities as required by the WPS specification.There may be many different possibilities for integrating Kepler but we are particularlyinterested in solutions that reuse and extend the model markup description already available in theKepler workflow descriptions to make the task of adding new processes less onerous for the user.However, runtime typing in Kepler and mismatch in complex type definition between Kepler andthe WPS have made this difficult. As a result, we have had to define our own input and outputparameter types in a separate file. The proposed Kepler-WPS integration work was inspired by theneed to reuse a process for creating gridded rainfall time-series from point-based measurementsfor ingestion in a rainfall-runoff model.
Exposing the Kepler Scientific Workflow System as an OGC Web Processing Service
The Open Geospatial Consortium (OGC) - Web Processing Service (WPS) providesan interface for distributed geoprocessing: from discovery and description of available processes,description of input and outputs, to execution and retrieval of results. While the integration of variousgeoprocessing libraries into WPS implementations negates the need to redevelop commonalgorithms, authoring of processes for the WPS is still very much in the hands of the softwaredeveloper, rather than the scientist. We propose that by integrating a workflow execution engine(in our case, Kepler) as a WPS processing engine, process content authoring becomes more accessibleto the scientist. Existing geoprocessing framework integration solutions have a large relianceon additional user-generated metadata to properly define capabilities as required by the WPS specification.There may be many different possibilities for integrating Kepler but we are particularlyinterested in solutions that reuse and extend the model markup description already available in theKepler workflow descriptions to make the task of adding new processes less onerous for the user.However, runtime typing in Kepler and mismatch in complex type definition between Kepler andthe WPS have made this difficult. As a result, we have had to define our own input and outputparameter types in a separate file. The proposed Kepler-WPS integration work was inspired by theneed to reuse a process for creating gridded rainfall time-series from point-based measurementsfor ingestion in a rainfall-runoff model.
