Robust Workflow Systems Flexible Geoprocessing Services Geo-enabled Model Web? - Geographical Information Systems: Trends and Technologies - page 189

between workfl ow tasks. Similarly, WSDL parsers also offer poor support
for managing complex data type defi nitions as part of geospatial elements
schema (see some examples in Tamayo et al. (2012)). Second, geospatial
workfl ows are often data-intensive and may require long processing times
in execution and retrieving inputs data sets, as well as asynchronous calls.
These and other advanced features are not often part of business workfl ow
engines (Barga and Gannon 2007).
Geoprocessing Services and Scientifi c Workfl ow Systems
This section explores the ability of the aforementioned scientifi c workfl ow
systems to interact with distributed web services in general, and
geoprocessing web services in particular, in compliance with the vision of
geo-enabled scientifi c workfl ows (Altintas et al. 2011).
Kepler-based Geo-enabled Workfl ows
As earlier commented in Section “Scientifi c Workfl ow Systems”, Kepler
provides the concept of actor to enable the addition of any algorithm or
component in a scientifi c workfl ow (Ludäscher et al. 2006). Users select
components, data sources and remote web services via specialized actors
(e.g., Web Service actor for WSDL-based services) to include them in Kepler
workfl ows. In this line, Pratt et al. (2010) explored how Kepler workfl ows
can be exposed as OGC WPS-based services. However, the authors found
several limitations because of the way inputs and output parameters are
declared. For example, Kepler uses the particular Object type for capturing
complex structures, which basically is a fl exible container to allow dynamic
type binding, whereas all of the elements necessary (mime types, schemas,
etc.) to declare the WPS parameter types must be known at design time.
Similarly, Barseghian et al. (2010) suggested the potential integration of
OGC Sensor Web Enablement (SWE) 24 standards within Kepler workfl ows,
so that scientists can benefi t from these sensor web standards and protocols
to access to disparate environmental observations and measurements
(Bröring et al. 2011).
Apart from supporting web services technology, Kepler includes
distributed computing technologies to permit scientists to share their
data and workfl ows with other scientists and to use data and analytical
workfl ows. It is recently expanding to support cloud computing capabilities.
For example Wang et al. (2009) integrated Kepler and Hadoop, 25 an
open-source implementation of MapReduce 26 computation model to
24 http://www.opengeospatial.org/ogc/markets-technologies/swe
25 http://hadoop.apache.org/
26 http://labs.google.com/papers/mapreduce.html