International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Geospatial Standards for Web-enabled Environmental Models Patrick Maué1, Christoph Stasch1, George Athanasopoulos2, Lydia E. Gerharz1 1 Institute for Geoinformatics (ifgi), University of Münster, Weseler Str. 253, 48151, {firstname.surname}@uni-muenster.de 2 Dept. of Informatics & Telecommunications, National & Kapodistrian University of Athens (NKUA), Panepistimiopolis, Ilisia 157 84, Greece, gathanas@di.uoa.gr Abstract Serving geographic information via standardized Web services has been widely accepted as a useful approach. Web-enabled environmental models simulating real-world phenomena are, however, rare. The models predict observations traditionally served by geospatial Web services compliant to well-defined standards. Using standardized Web services could support decoupling of models, comparison of similar models, and the automatic integration into existing geospatial workflows. Modeling experts face several open issues when migrating existing environmental computer models to the Web. The selection of the Web service interface depends on the input parameters required for the successful execution of the computer model. Loosing control over the execution of the models, and consequently also the confidence in model results, can be addressed to a certain extent by using translucent and standardized workflow languages. Mechanisms and open problems for the implementation of geospatial Web service compositions are discussed. Two scenarios about oil spills and the exposure to air pollution illustrate the impact of unconfigured model parameters for standard-compliant spatial data clients. Keywords: Model Web, Environmental Models, Spatial Data Infrastructures, Environmental Observations, Web Service Standards This work is licensed under the Creative Commons Attribution-Noncommercial Works 3.0 License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/3.0/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. DOI: 10.2902/1725-0463.2011.06.arty International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy 1. INTRODUCTION Environmental models facilitate the understanding of changes in the environment, for example, by forecasting the next day’s weather, predicting the distribution of forest fires, or rendering soil maps from core samples. They support decision makers in understanding the impact of real world events and processes in geographic space, and help in evaluating appropriate response measures. Different variations of environmental models exist; simulating environmental systems to study the impact of change of certain parameters is one example. In this research, we limit the definition of environmental models to software implementing mathematical models representing real world processes. These models vary regarding their complexity. Simple mathematical models might interpolate missing values from known sensor observations, while complex models make use of current or historical sensor data to predict future conditions. Computer models are implementations of mathematical models for simulating (and replicating) real world processes. The more complex the computer model, the more parameters and data inputs are typically required for its execution. For example, a hydrodynamic model may only take the river’s discharge as input to predict downstream discharge, whereas more sophisticated solutions consider the terrain and the land cover of adjacent areas (Kurzbach et al., 2009). The ongoing implementation of INSPIRE (DIRECTIVE 2007/2/EC) and initiatives like GMES (“Global Monitoring for Environment and Security”) and SEIS (“Shared Environmental Information System”) call for a migration of environmental models to reusable Spatial Data Services (SDS). This will eventually lead to a large supply of environmental models in the Web. From this set of models, domain experts can select the most appropriate implementations in the context of specific scenarios. Environmental models could then be replaced if certain characteristics such as the result's accuracy do not match the application’s requirements. Reaching this objective relies on environmental models implemented as SDS with well-defined access methods and standardized formats for the consumed and produced data. These standards specify a common encoding and enable support in either local Desktop GIS or large-scale SDIs (“Spatial Data Infrastructures”). The idea of the Model Web (Geller and Melton, 2008) takes this view even further. It envisions interoperable computer models, embedded in a multidisciplinary network of models, data sources, processes, and sensors. It is a proposal for dynamic infrastructures for environmental computer models serving researchers, managers, policy makers, and the general public. Within GEOSS (“Global Earth Observation System of Systems”), the Model Web is defined as one of several approaches addressing current shortcomings for predicting the impact of, for example, the changing environment. GEOSS was established as international collaboration effort for enabling access to earth observations across national and semantic boundaries. The goal is to enhance International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy interoperability of existing models and to make their outputs more accessible. Similar to the conceptual architecture of SDIs, GEOSS implementations focus on modularity and interoperability to achieve “integration-ready” components (Christian, 2005). Despite the existing effort, domain experts are reluctant to move environmental models into the Web. Open issues such as capturing model semantics, communicating uncertainty of the results, and ensuring efficient execution and workflow modelling are (and have been) subject of the research projects ENVISION1, UncertWeb2, GDI-Grid3, SWING4, and SODIUM5. Concerns about trust (the risk of involuntarily sharing data and algorithms) and control (fear of losing control over model definition, execution, and calibration) are only partly discussed in this paper, but have to be considered for Web-enabling environmental models. In this paper we recommend the use of standardized and well-established service interfaces to deploy and invoke environmental models on the Web. We introduce the distinction between pre-configured/non-interactive models and unconfigured/interactive models. This classification derives from the discussion about user expectations (i.e. “what do we expect as result from an environmental model?”) and technical expectations (i.e. “how does a client request and visualize model results?”). This distinction is also exemplified by the two pilot cases which are presented in this paper. In addition, we discuss how existing environmental models running as stand-alone applications are decoupled into individual Web services representing either certain processing parts of the models or their input data. Common process modeling languages can then be used to couple these Web services into service compositions. These compositions support the flexible combination and reuse of the processing parts. In the remainder we refer to environmental models implemented as service compositions as Environmental Process Models (EPM). Granularity has to be considered as an issue for the decomposition of local computer models into Web services. Existing environmental models could either be exposed as one Web service or be split up into several constituent Web services representing the individual steps. Even though this aspect is of importance for the modeling expert, it is irrelevant for the presented architecture. This approach supports both, fine and coarse-grained compositions. The EPM can comprise one or many Web services coupled through a process modeling language. The resulting composition is exposed as a Web service compliant to the standards set by the Open Geospatial Consortium (OGC). The standards ensure the seamless integration of the models into existing geospatial workflows. The introduction of the architecture for this 1 2 3 4 5 European research project (FP7): European research project (FP7): German research project (BMBF): European research project (FP6): European research project (FP6): http://www.envision-project.eu http://www.uncertweb.org/ http://purl.org/ifgi/projects/gdi-grid http://purl.org/ifgi/projects/swing http://www.atc.gr/sodium International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy approach and the discussion of the reasons for selecting the appropriate OGC standards should be considered as the main contribution of this paper. The paper also lists some of the unique aspects of geospatial workflows in general. For example, geospatial applications are traditionally dealing with large amounts of data. This complicates concerns such as scalability and performance of the execution. An example implementation further illustrates that existing and wellestablished standards can be simply applied to model and invoke geospatial workflows. In the following Section 2, the relevant standards and specifications from the OGC are introduced. In Section 3, we discuss user expectations for environmental models, the notion of workflows, the distinction between pre- and unconfigured models, and suggest appropriate service interfaces. Section 4 lists two scenarios to further illustrate this distinction and to highlight current research on uncertainty and semantics for geospatial workflows. The efficient execution of model workflows is explained in detail in section 5, followed by an example illustrating how the scenario could be implemented. In section 6 the presented approach is evaluated in relation to results of past and ongoing research projects. The conclusion in section 7 provides an outlook into future research, and summarizes the main findings of the paper. 2. STANDARDS FOR ENVIRONMENTAL MODELS Spatial Data Services (SDSs) manage the access to geographic information. They are embedded in SDIs, which build the foundation for standardized and interoperable exchange of spatial data. Publishing EPMs as SDS has been recognized as useful (Mineter et al., 2003, Granell et al., 2010) to improve acceptance of model results and collaboration between environmental experts. Embedding EPMs in SDIs relies on interoperable components. This requires standards which are presented in this section. 2.1. Standards for Spatial Data Services EPMs usually result in spatial and/or temporal data, e.g. field-based predictions or time series. Elements of spatio-temporal data can be modeled as vector-based features, raster-based coverages, or sensor observations. Depending on the data model, commonly used and often standardized encodings exist. Typical formats for vector-based features are the OGC Geography Markup Language (GML) (Vretanos, 2005), or the ESRI Shapefile. GeoTIFF or NetCDF are popular choices for raster-based data. The OGC standard Observations & Measurements (O&M) defines an encoding for sensor observations delivered as time series (Cox, 2007). Sensor metadata is described in SensorML, the Sensor Model Language (Botts and Robin, 2007). International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Specialized Web service interfaces have been specified by the OGC for accessing the different forms of spatial data. The OGC Web Feature Service (WFS) defines methods to retrieve vector-based geographic features encoded in GML. The Web Coverage Service (WCS) specifies access to raster-based data (Whiteside and Evans, 2007). However, temporal filtering of the retrieved environmental observations is not sufficiently supported by the WCS and WFS standards. The Sensor Observation Service (SOS) provides temporal filtering for observation time-series encoded in O&M. The benefits of standards have also been recognized for the processing of spatial data. Geoprocessing methods such as transforming or merging of geospatial data are managed by the Web Processing Service (WPS). The WPS interface provides operations to retrieve detailed information about the available processes, their parameters and their execution (Schut, 2007). All OGC Web service interfaces also include methods to retrieve metadata required for evaluating the usefulness of the offered spatial data or processes for the client’s application. Common encodings and access methods enable generic spatial data clients to directly reuse SDS for common tasks such as geospatial analysis and decision-making. The EPM Web service interface and the encodings of the model results should comply with the introduced standards to enable the desired integration. 2.2. Standards for Web service compositions Decomposing the complex legacy models into Web services enables separation of input data and model algorithms. These Web services can then be reused in other scenarios (e.g. the model algorithm can be applied for another region using different data as input). The ISO 19119 standard defines coupling of (OGC) services as service chaining. Service workflows and service compositions are also commonly used and are considered equivalent for this research6. By far the most widely-used standard for the encoding of Web service process models is the Business Process Execution Language (BPEL) (Diane and Evdemon, 2007). BPEL is a declarative language that supports the description of either abstract or executable service processes. It provides high-level constructs (inherited from workflow languages) which enable the design of service workflows by domain experts. A wide range of tools exists for both, the composition of existing Web services into more complex workflows and the subsequent execution with a runtime engine. BPEL provides the necessary means to realize process models as computerexecutable models accessible over the Web. The idea of coupling existing SDS to sophisticated service compositions is still not more than a vision. Semantic conflicts, insufficient means to describe spatial data quality, over-complicated composition tools, and execution performance significantly impair widespread 6 Their slight difference is not relevant for the work introduced in this paper. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy acceptance. These problems are relevant, but are not unique to spatial data. For the presented work, we assume they will be eventually solved. The authors have addressed some of these topics already in their recent work (Tsalgatidou et al. 2008, Maué et al. 2009, Athanasopoulos et al. 2010) 3. BRINGING MODELS INTO THE WEB In the following discussion we assume that environmental models predict or interpolate environmental observations. We explain which OGC standards should be selected for environmental models and how to use BPEL to implement these models. The distinction between pre- and unconfigured models is crucial for the workflow invocation and accordingly for the presented architecture. 3.1. Environmental Process Models as OGC Services EPMs simulate real world phenomena occurring in geographic space. Exposing EPMs as Web services depends on the definition of its interface. Using an OGC standard as interface (as long as the implementations comply with the specifications and match in versions) enables: Coupling models: One of OGC’s self-claimed goals is to enable geoprocessing technologies to “plug and play”. A streamflow model (for predicting the amounts of water transported by a river) might rely on real-time information about the river’s water level. It expects a collection of sensor observations from river gauges. This data may come as well from a water runoff model predicting water levels by looking at real-time precipitation data in the river’s catchment area. Standards ideally allow for simply chaining various models to create more sophisticated models (which, in the end, are needed to approximate the complexity of reality) or to overcome data sparseness. Standard interfaces do not only support the coupling and integration of environmental models as such, but also the replacement of the individual modules with equivalent services. But this implies, besides syntactic and structural interoperability, also a sound understanding of service semantics. Comparing models: Environmental models have an impact on decisions of public authorities. The predictions of UK’s National Weather service about the spread of the ash cloud caused by the 2010 eruption of Eyjafjallajökull volcano lead air traffic controls to close down large parts of the European airspace. This decision was followed by critical claims of over-reaction and doubts about confidence in the model results. Making not only the results but also the model algorithms and the data sources available as Web services supports verification. Furthermore, the availability of different models for predicting similar phenomena supports identification of significant differences (and accordingly uncertainty of the predictions). International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Integrating models: Using standardized interfaces supports integration into common spatial data applications like GIS software. This allows easy integration of models into existing scientific (or enterprise) workflows, supporting reuse and acceptance within the modelling community. Unfortunately, these points do represent not the reality, but the potential of standards. A plethora of different versions across implementations, different and sometimes conflicting understandings of how to implement specifications, and the trend of making standards too complex, impair the envisioned seamless integration. Nonetheless, we believe that OGC standards can help to ensure a certain level of interoperability. The listed benefits explain why common OGC standards should be used for environmental models. In the next section, we propose one particular OGC standard for encoding the output of EPMs. 3.2. Environmental Process Models as Virtual Sensors Physical sensors serve environmental observations such as measurements for precipitation or the concentration of pollutants in the air. The EPMs considered here provide approximations of these observations, e.g. by interpolating precipitation samples to assess weather conditions at not observed locations. Sgroi et al. (2005) define virtual sensors as ”objects that perform abstractly the same task as simple sensors in the sense that they provide data upon an external request but consist in general of a number of different components”. We argue that, if we consider EPMs to be such virtual sensors, they should also produce results comparable to physical sensors. Observations of physical sensors are made accessible using the OGC Sensor Observation Service (SOS) for the service interface and O&M for the encoding. Hence, we propose to wrap the output of EPMs using O&M. The O&M observation contains informative metadata and a reference to the resulting data. The latter, e.g. a coverage representing temperature variation, is delivered in one of the accepted spatial data formats such as GeoTIFF. Metadata about the EPM is included in the SensorML description referenced from the O&M document. Quality information can be directly nested in O&M using ISO 19115 or other more specific encodings such as the Uncertainty Markup Language (UncertML) (Williams et al., 2009). Following this proposal, the SOS would be the most apparent choice for exposing EPMs. This could enable seamless access for generic SOS clients. However, this is problematic not only from a conceptual point of view. A SOS is meant to deliver observations and not to execute environmental models. In addition, models usually require specific input parameters which have to be provided by a human user (the unconfigured models discussed in the next section). The SOS does not support model-specific input and thus cannot be used here. Our architecture presents a solution which manages to keep support for SOS clients and exposes the EPMs as OGC Web Processing Services. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy 3.3. Pre-configured vs. Unconfigured Environmental Process Models Making EPMs accessible to a greater public requires means to let anyone invoke the composition without the need to understand the underlying (often very complex) configuration. The EPMs deliver, as suggested before, O&M documents with a reference to a SDS serving the actual data. Hence, EPMs are on first sight best exposed as SOS to enable the integration of generic SOS clients. Pre-configured EPMs do not depend on any user interaction for their invocation. Input data is delivered by other Web services, whose location is preconfigured in the EPM. Calling this model will then fetch the data covering the requested time and area from the configured source. In addition, the standard SOS query parameters (e.g. to specify a bounding box for the desired coverage) are supported and bound to the internal variables of the EPM. Purpose and semantics of these parameters are specified in the SOS standard. Only in this case, service requests can be automatically generated by the SOS client software. A pre-configured EPM can be simply invoked by existing SOScompliant clients if they rely only on standard SOS query parameters. Clients requesting this EPM don't have to be manually adapted. Many environmental models, however, depend on input parameters. These parameters have to be provided by human users using specially adapted client software. In this case, we refer to the environmental models as being unconfigured. Some of the input parameters cannot be defined internally in the EPM; they have to be manually specified by the end user. Invoking the model without giving this additional information results in an error. A SOS, however, only accepts a limited set of parameters (i.e. spatial and temporal coverage or a sensor id). The WPS provides a more generic solution for migrating models into the Web. This flexibility comes with a serious limitation: whereas the SOS can be simply used in existing applications, the WPS almost always requires specially adapted clients due to its flexibility regarding the input parameters. Still, it is the only option for transforming unconfigured EPMs into OGC Web services. Similar to the proposal for pre-configured EPMs, the execution via a WPS interface results in an O&M document containing the modeled observations or a reference to a WFS/WCS serving large data sets. As EPMs are often quite complex and may require some time to be executed, manual invocation requires asynchronous communication for the model execution. The WPS specification includes extensions for the asynchronous communication to request the workflow execution state. The SOS is not meant to execute any processes; asynchronous data exchange is not specified for this service interface. As conclusion we argue that pre-configured EPMs should be accessible through an OGC SOS interface to enable support by generic SOS clients. However, all International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy EPMs, regardless of their need for manually specified input parameters, should be implemented as WPS to support, for example, model-specific input parameters and asynchronous communication. Access via the SOS interface is managed by a SOS proxy which mediates client requests for pre-configured models from generic clients to the WPS implementation (see Section 3.6). 3.4. Environmental Models as Workflows We presented the approach for migrating environmental models to the Web in a workshop with modeling experts (Urvois and Berre, 2009). The domain experts were mineral resource specialists from the French Geological Survey BRGM, who are responsible for the acquisition, compilation, and publication of geological data. GIS software is used for these tasks and the experts acquired in-depth knowledge about required data and processes. Moving their tasks into the Web has been recognized as useful at the workshop. But the idea of moving the whole workflow (acquisition, compilation, publication) was considered to be problematic. Without knowing what is going on inside the workflows, the users felt being “remotely controlled”. They considered models as “Web-based black box”, which made it difficult to be confident about the EPM results (Urvois and Berre, 2009). Making information about the EPM execution available is crucial to build up confidence. Inspecting the model's behavior with respect to changes of the input data is therefore one key requirement for modeling experts. We distinguish between two options to publish computer models as services. Existing computer models can either be simply migrated as a whole into the Web. The configuration is then hard-coded into the implementation. Alternatively, they are partitioned into individual components (representing either data sources or model processes), with each module being exposed as Web service separately. EPMs represent the original model workflow and are themselves accessible as Web service. The first approach contradicts with the modularity and flexibility recommended for the GEOSS and INSPIRE architectures. The environmental model is bound to one specific scenario with a predefined spatial and temporal coverage. Being able to adapt environmental models requires loosely-coupled workflows. EPMs are configured under certain assumptions derived from the model builder’s context. Loosely-coupled BPEL workflows have the possibility of being translucent. ISO 19119 includes a distinction between transparent, translucent, and opaque model workflows (Percivall, 2002). Transparent workflows are configured and executed by humans. Translucent (or white-box) compositions are managed by workflow execution environments, but the users are still aware of the individual services. In the case of opaque (or black-box) models, the workflow’s inner structure is hidden from the user (Einspanier et al., 2003). Translucent models can be easily communicated to the end user. They are able to reconstruct the model execution International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy by inspecting the performed steps and derive information about the provenance. The use of standardized workflow languages like BPEL helps to communicate the model structure and configuration. However, it does not answer which concrete parameter values were used. Information about the model execution is required here. This could be, for example, as simple as providing log files with the result. Letting users retrace the decisions taken during execution and inspect the content of flowing data requires a more sophisticated approach. The Open Provenance Model (OPM) is a mature standard for encoding and communicating lineage of computer models (Moreau et al., 2008). Hiding the model’s structure and execution details from the user can sometimes be appropriate, too. For example, security constrains may force data providers to limit access to the workflows. 3.5. Architecture In the preceding sections, we highlighted requirements for accessing and implementing EPMs on the Web. In the following, we specify the architecture which supports seamless integration with generic SOS clients, while using the WPS for the actual execution of the environmental model. Figure 1 summarizes the different points raised in this section. The OGC Frontend to the Workflow Engine is a service which exposes one or more EPMs as Web services. The models are implemented using the BPEL language and are deployed to and managed by the Workflow Engine. A generic client, for example a web-based map viewer, invokes the EPM by requesting environmental observations for a certain region and time using the SOS interface. If the observations are present in the database for the requested time and area, an O&M document with model metadata and the reference to a SDS (WFS or WCS) is returned. The O&M-compliant client then simply fetches the data from the SDS. If the observations are not present, a simple feature of the underlying HTTP protocol is used. The SOS responds with a HTTP code 303 (“See other”) with a pointer to the WPS responsible for executing the workflow producing the required spatial data. All input parameters from the original SOS request are forwarded to the WPS. In the case of a pre-configured model, the workflow expects only the usual SOS parameters as input. It is automatically executed; the response is either a HTTP code 202 (“Accepted, but not completed”) if the output is not ready yet, or the O&M document with the requested information. For unconfigured models, further input parameters are required. Hence, the request with SOS parameters only results in an exception listing the missing parameters. It is then in the responsibility of the client to let the user specify these parameters and re-execute the WPS with all required inputs. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Figure 1: OGC-compliant frontend to the Workflow Engine 4. SCENARIOS In the following section, we are going to present computer models for two real world scenarios. The first illustrates how preconfigured models for air pollution benefit from Web services. The second introduces a computer model for oil spills (and response actions) as example for unconfigured models. 4.1. Modeling exposure to air pollutants The raised awareness of the effects of air pollutants on human health lead to policies like the European directive on ambient air quality and cleaner air for Europe (DIRECTIVE 2008/50/EC). Determining air pollutant exposure to citizens is a challenging and unsolved task. The scenario described in this section introduces an environmental model addressing this issue. Parts of this scenario are also included in the Air Quality Health scenarios of the third GEOSS Architecture Implementation Pilot Phase 3 (AIP-3). A non-ICT expert wants to explore the exposure of his children to air pollutants on the way to school and back. He decided to equip his children with GPS receivers. The resulting tracks are used to estimate their exposure to air pollutants. Figure 2 shows the workflow of this scenario. GPS data containing the tracks of the children to school and back home is first requested from a SOS. The International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy availability of air quality information for the observed locations is checked next. A SOS providing air quality measurements extracted from the AirBase database of the European Environmental Agency (EEA) is used in this step. If concentration measurements are available for the requested positions, the workflow is finished and the concentrations are returned. If not, the workflow is split up into two subworkflows: (i) including interpolation of the EEA rural background air pollutant measurements and (ii) estimating additional urban concentrations from local emission sources through an air pollutant dispersion model service. By adding the two service responses, total air pollutant concentration estimates can be calculated for the requested GPS positions. Figure 2: Workflow of the Air Quality Scenario sd Air Quality Model Positions «Processing Serv ice» Request Positions «Data Service» GPS Tracks «Data Service» Air Quality Data «Processing Serv ice» Check Positions Positions with Air Quality Data Observations at GPS positions Observations at nearby positions Concentration available? No Positions «Processing Serv ice» Interpolate Observ ations «Processing Serv ice» Estimate Urban Concentrations Interpolated Raster Estimated Concentrations «Processing Serv ice» Ov erlay Render Concentration at GPS locations The complete workflow is encapsulated by a WPS. One of its internal Web services executes the AUSTAL2000 model, a local air pollution dispersion model developed for Germany. A second WPS offers interpolation functionality for the background concentration of air pollution. Its implementation, the INTAMAP interpolation service (Pebesma et al., 2009), relies on air quality observations for the respective time period. All sources for the input data, including the SOS reference to the tracks of the children, are predefined in this EPM. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy 4.2. Modeling the impact of oil spills on cod populations An early response is crucial to minimize the impact of oil spills on the ecosystem. Knowing how to fight the oil relies on computer models predicting the oil drift (and when it will reach the coastline). Accurate models of oil spill effects on the environment rely on additional information about the spill. This includes, amongst others, data about the nature of the oil spill (for example an oil well blow-out or a damaged ship loosing fuel), the spill location, the type of the spilled oil, the water’s temperature, salinity, and depth of the spill, direction and strength of wind and water currents, and others. A computer model already configured for one oil spill cannot be applied to another spill. It has to be reconfigured to accommodate the different conditions of the new event. The OSCAR (Oil Spill Contingency and Response) model supports the objective assessment of oil spill response strategies (Reed, 1995). In the ENVISION project we are searching for means to move parts of OSCAR into the Web. The scenario is concerned about the impact of oil spills on cod populations. It consists of two models: Predict Oil Drift models the oil distribution in a three-dimensional water body. An oil weathering model is then included to assess the impact of current weather and sea conditions on the oil’s chemical composition and accordingly its behavior in seawater. Its output is required to predict the trajectory of the oil cover to assess when the oil cover reaches the coastline and eventually protected areas. The second model Predict Cod Effects estimates the toxicity (and subsequent lethality) for cod populations. The results of the oil drift prediction serve as input for modeling the uptake of oil components by cod eggs and larvae. Forecast data about sea and weather conditions is served by OGC-compliant Web services. The oil drift prediction model requires additional input parameters defining the chemical composition of the oil (crude oil, for example, behaves different in sea water then refined oil), the location of the incident, and the amount of oil discharge. This information cannot be sensed automatically, but has to be manually defined before executing the model. Hence, this scenario serves as an example of an unconfigured model that has to be adapted before being used in the decision-making process. Users have to manually specify certain input parameters in the client software before running the model (e.g. using a portal-based solution with map viewer as it is developed in ENVISION). International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Figure 3: Workflow of the Oil Spill Model act Oil Spill Model «Input Parameters» Location, Date, Discharge, Oil Type «Data Service» Weather and Sea Observ ations «Data Service» Bathymetry Configure Oil Spill Model «Data Service» Cod Population Data Render Cod Effects «Processing Serv ice» Predict Oil Drift «Processing Serv ice» Predict Cod Effects Oil Drift Predictions Cod Effect Predictions «Data Service» Coastline Figure 3 depicts the workflow of the introduced oil spill scenario. We can distinguish between three types of Web services delivering either near real-time data streams of (modeled) sensor observations (SOS), traditional spatial data sets (WFS, WCS), and processing capabilities (WPS). Additional parameters such as oil spill rate or oil type are provided by the application invoking the workflow, e.g. a web-mapping client. 5. DEPLOYING MODELS IMPLEMENTED AS WORKFLOWS A BPEL workflow is a composition of activities, and/or other processes, with groundings for each activity through partner links. These links point to external services performing the activity tasks. The BPEL workflow itself is exposed as Web service again. Despite its widespread use, BPEL received substantial criticism mainly due to its strong link to WSDL (Christensen et al., 2001). Partner services are required to have a WSDL- based description according to the specification. However, OGC Web services (and also, for example, RESTful services) usually do not provide WSDL descriptions of their functionality. A workflow engine (as depicted in the architecture in Figure 1) is required for BPEL execution. A plethora of engines, either commercial (e.g. Oracle BPEL Process Manager7) or open source (e.g. Apache ODE8), are available. BPEL Workflow Engines were designed for executing business process models. Their support for other process model types, e.g. scientific process models, lags behind. In the 7 8 Oracle BPEL Process Manager: http://www.oracle.com/appserver/bpel_home.html Apache ODE: http://ode.apache.org/ International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy following section, we list some of the requirements of environmental models which contemporary workflow engines still lack support of. 5.1. Environmental Process Requirements Environmental process models pose significant requirements to the workflow engine, which are listed below:  Compliance to standards: BPEL requires a definition of a WSDL Web service interface that is used to invoke the workflow. Integrating the workflows into existing spatial applications based on OGC standards requires an OGC WPS interface to the Workflow Engine (see Fehler! Verweisquelle konnte nicht gefunden werden.). The presented architecture acts as bridge between the WPS and the WSDL interface exposed by the workflow engine.  Loosely-coupled processes: Environmental process models comprise spatial data and processes offered by distinct providers. The interactions between the process model and the data or processing services have to be performed in a peer-to-peer manner supporting loose coupling of the individual activities. Both, the process model and the providers, remain autonomous during the performed interactions.  Scalability in terms of supported process instances and data volume: Deploying environmental process models largely increases the number of process instances. Process models work with information ranging from simple text to raster images and extensive feature collections. Existing spatial data services already struggle to deal with voluminous data, processing the data across many running instances poses a significant scalability concern for the deployment infrastructure.  Transfer of spatial data: Due to bandwidth and/or network throughput limitations, the exchange of voluminous data delays process model execution. Filtering may enable to limit the exchanged data and therefore network load to a certain extent.  Environmental model performance: Clients loading environmental model results into a map view expect fast visualization of the results. The complexity of the spatial operations performed by the partner services, as well as the exchange of voluminous data, sets significant performance requirements on the deployment infrastructure.  Use of multiple types of services: Environmental process models comprise interactions with different processing and data providing partners. Those are International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy accessible using distinct types of services. For example, processing functionality may be offered through either W3C- or OGC-compliant services. Some of these issues are addressed neither by BPEL nor by the contemporary BPEL engines. Web-enablement and peer-to-peer interaction are inherently supported by BPEL engines. The interaction between engine and partner services is performed in a point-to-point manner. Scalability, transfer, performance, and the use of multiple service types remain challenging. BPEL has been primarily conceived as a mechanism facilitating the provision of business processes. Here, the exchange of voluminous data or varying service types was not considered relevant. Scalability, transfer, and performance are mainly related to the architecture, e.g. choosing a distributed or centralized system, and the deployment infrastructure, e.g. support for multithreaded and/or parallel execution. The other issues are related to the BPEL specification, in particular the support of different service types. This can be achieved either through extending BPEL as proposed by Karastoyanova et al. (2008). Tsalgatidou et al. (2008) suggest to use appropriate WSDL bindings for the additional services types. OGC services have to be supported for environmental models. This can be natively addressed by BPEL using the WSDL HTTP binding mechanism. 5.2. Oil Spill BPEL Process Model The oil spill model is an unconfigured environmental process model depending on additional parameters for its invocation. The location and time of the oil spill as well as the amount and type of the oil have to be specified by the modeling expert. The result of the workflow (as depicted in Figure 3) contains predictions of the oil spill’s effect on cod populations. We mentioned that unconfigured models have to be exposed as WPS processes. The following Listing 1 is a simplified WSDL example of the oil spill workflow (in this case we assume that one WSDL file is created for each process). The WSDL example does not specify concrete bindings to a service instance. Details such as namespaces, mandatory attributes, or operations like the getCapabilities-method have been left out as well9. 9 The source code of this example is part of the ENVISION project, and can be found in its source code repository at http://kenai.com/projects/envision. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Listing 1: Excerpt of the WSDL interface for the Predict Oil Drift-Model At line 32, the operation execute() is implemented according to the WPS specification. The input of this operation (l.33) has one part (l.24) which is further defined in the section of WSDL Types (l.5-12). Here, the mandatory input parameters are specified. This example illustrates how unconfigured models are mapped to WSDL interfaces. The mandatory information for executing unconfigured models are linked to WSDL input parameters, whilst the model result is mapped to the output type of the operation. In this case, the result would be a Feature Collection. Similarly, pre-configured models can be mapped to operations without input parameters. The WSDL file presented here is the service description exposed by the workflow engine. The OGC Frontend offers access to the traditional OGC-compliant service capabilities. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Listing 2: Simplified Example of the BPEL process for the Predict Oil Drift-Model OGC services rely on HTTP-based (e.g. HTTP GET or HTTP POST) interaction patterns. Using the appropriate WSDL binding type is crucial for their integration in BPEL processes. BPEL editors support the transformation of graphical models as in Figure 3 into executable BPEL process specifications such as the one presented in Listing 2. In this simplified sequence, a remote WFS (representing an input data source) and a WPS (representing the model process) are invoked. The incoming request (l.4) is using the execute operation defined in the WSDL file (the PartnerLink ExposedWPS maps to the WSDL file in Listing 1). The input variable Model_Input includes the mandatory parameters which are copied into the request for the remote WPS (l.7-13). The same happens for the WFS whose response for the getFeature operation is copied into the variable RemoteResponse (l.15-20). The WPS providing the model process is invoked International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy with all input data (l.24-27) and its result is returned as result of the whole workflow (l.31-33). 6. EVALUATION Various related work addresses the question how to integrate and task models. Klopfer and Simonis (2009) implemented, for example, an interpolation Web service. Similar to the presented approach, they understand the model as a virtual sensor and publish it as Sensor Planning Service (SPS) (Simonis, 2007). However, in our experience, the WPS offers all functionality needed to execute environmental models and the WPS is already established for providing processing functionality in SDIs. A service-based application for alpine run-off models has been introduced by Granell et al. (2010). It consists of a portal application, a service layer, and a data layer. The portal application allows for the discovery of available services, the visualization of its data, and the orchestration of services within environmental models. The models themselves are executed by the portal application. The service layer provides means to integrate external SDS. This enables access to several data sources (in the data layer) like maps, coverages or feature-based spatial data. The presented approach goes beyond the related research by combining standards for the Sensor Web with already well-established geospatial services like the WPS, WCS, or WFS. We applied a WPS-based approach for publishing environmental models in the projects GDI-Grid, SWING, and INTAMAP. User requirements are crucial to understand the choice for SOS/WPS coupled with a WFS or WCS. Even though technically simple to implement and adapt, the WPS standard is rather vague regarding its output and input. Implementations are prone to have conflicting interfaces. Seamless integration into scientific workflows by coupling and comparing the models is nearly impossible to achieve if the WPS interface is used without further constraints (for example through profiling). Since models are supposed to approximate observations of a (usually future) reality, we argued that clients best deal with environmental models in the same way as (virtual) sensors. In some cases, though, environmental process models rely on input parameter which cannot be retrieved automatically. Here, the WPS is the most appropriate choice10 . We have also evaluated different approaches for executing environmental process models: In SWING, we have taken an approach based on abstract state machines. Its performance did unfortunately not match the user requirements; one execution took around four minutes. In addition, this approach was too complex and required specific knowledge about the chosen composition 10 Initially the SPS was considered here, but was later discarded. The WPS largely overlaps with the SPS and is more established in the geospatial community. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy language to adapt the workflows for different scenarios. In the GDI-Grid project, we investigated the use of parallel processing using grid technology to enhance performance of the workflow execution. Kurzbach et al. (2009) deployed numeric flood models and Lanig et al. (2008) investigated the use of the WPS for processing digital terrain models. In the GDI-Grid and the SODIUM project, BPEL and BPEL-like languages respectively have been successfully tested. Tsalgatidou et al (2006) suggest that BPEL-like declarative languages can easily support the provision of scientific processes comprising heterogeneous types of services. Moreover, BPEL and BPEL-like languages provide the necessary level of abstraction which supports the deployment of scientific processes over advanced platforms. In the ENVISION project we are combine these results to enable efficient execution of service compositions. The discussed issues about semantics arose (and have partly been dealt with) in GDI-Grid and SWING. The approach based on semantic annotations has been successfully tested for the discovery of Web services and the validation of service compositions. Within the INTAMAP project, interpolation algorithms were served through a WPS interface (Pebesma et al., 2009). The developed XML language for encoding uncertainty, UncertML, has been proven to be appropriate to encode data quality aspect within the metadata of spatial data. Further integration of uncertainty into workflows in the Model Web is the subject of the UncertWeb project. The concerns of end users about the lack of confidence in results of opaque models have been recognized and are also addressed in ENVISION and UncertWeb. 7. CONCLUSION Standards for the Web-enablement of environmental models were discussed. Some of these models can be considered to be virtual sensors offering estimated measurements for physical phenomena in the real world. The OGC standards for encoding sensor observations enable the integration of environmental process models into existing SDIs. Workflow examples for two scenarios from the domain of air quality and oil spills were presented. The former serves as example for a non-interactive and pre-configured model. The latter is an unconfigured model due to the dependency on manually defined input parameters. The subprocesses of the model workflows, e.g. interpolation, numeric prediction, or topological operations, are each encapsulated as OGC WPS. The complete workflows are published as services again to ensure reusability. Standardized workflow languages support translucent models to let users study the model’s inner workings. Since environmental models are considered to be virtual sensors, their results are encoded using the O&M format. This has the following advantages: (i) O&M provides a common element to describe the procedure that has produced the observation’s (or in our case model’s) result. Hence, model metadata can be referenced from the model output in a common way. (ii) O&M provides common International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy elements to describe the quality of results. The INTAMAP project already successfully explored how to integrate uncertainty information into this model. (iii) By explicitly distinguishing observation metadata and observation result, it is possible to provide the model results through the best-suited formats and service interfaces (e.g. NetCDF and WCS for model results which are coverages) together with a common way to describe the metadata (see (i) and (ii)). This can be achieved by returning the model outputs as observations and referencing the data services like WCS and WFS from these observations. However, the general O&M model is quite generic and defines a lot of optional elements or elements without type restrictions. Thus, the definition of domain specific profiles like hydrology or meteorology might further increase interoperability. The WPS is the best choice for the execution of environmental models. It offers common ways to define parameters needed for the execution and a common way for asynchronous communication. Integrating a generic WPS into existing applications is difficult. Calling a WPS almost always requires some sort of clientside implementation which contradicts the presented vision of seamless integration of environmental models. This is supported by the SOS, which should be selected for accessing pre-configured environmental models. It helps to avoid the complexity of invoking environmental models, but still gives the user the opportunity to inspect the model structure. The workflows are encoded using the established BPEL standard and can be executed using generic BPEL execution engines. The presented approach should be considered as compromise. The lack of an OGC service specification covering the needs of unconfigured models should be on the agenda of future OGC efforts. The present interoperability technology can only cover a small part of the existing desktop-based environmental models. Climate models, for example, are far too complex to be deployed in Web service architectures. The number and variability of the input parameters, their often unforeseeable impact on the model results, and the expertise required to understand and re-trace this impact requires highly interactive and specialized applications. Only certain steps of the models may be migrated to benefit from Web-enablement, e.g. to support faster execution through distributed computing. The Model Web is still under development and can be brought forward only by deploying models on the Web. Several other open issues have to be further investigated to enable seamless migration of existing environmental models. One important fact is the communication of semantics and uncertainty to ensure interoperability and extensibility of environmental models. Ontologies that capture the dynamics of geographic space can establish a link between sensors observing real-world geoprocesses and environmental models simulating these sensors with the ultimate goal to seamlessly switch between both. The quality of the resulting information, in particular its uncertainty, has to be considered before integrating models in potentially critical applications. And in the end, the user has International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy to be aware of the model concept, its uncertainty, and the underlying assumptions. A user should be able to evaluate the resulting data, including selected data sources and parameters, a description of the applied algorithm, and the quality of produced result. The proposed standards in this paper support the communication of such model aspects and are therefore the best choice to expose environmental models as Web service. ACKNOWLEDGEMENTS The presented research has been funded by the European projects UncertWeb (FP7-248488, see http://www.uncertweb.org) and ENVISION (FP7-249170, see http://www.envision-project.eu). REFERENCES Athanasopoulos, G., Fox, E., Ioannidis, Y., Kakaletris, G., Manola, N., Meghini, C., Rauber, A. and D. Soergel (2010). “A Functionality Perspective on Digital Library Interoperability”, Proceedings of 14th European Conference on Research and Advanced Technology for Digital Libraries (ECDL2010), Sept 6-8, Glasgow, UK. Botts, M. and A. Robin (2007). OpenGIS Sensor Model Language, OGC 07-000, Open Geospatial Consortium, Inc. Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana (2001). Web Services Description Language (WSDL) 1.1, World Wide Web Consortium (W3C) Note, 15 Mar. 2001, at: http://www.w3.org/TR/wsdl [accessed 15 February 2011] Christian, E. (2005). Planning for the Global Earth Observation System of Systems (GEOSS), Space Policy 21 (2), pp 105–109. Cox, S. (2007). Observations and Measurements Part 1 - Observation Schema, OGC 07-022r1, Open Geospatial Consortium, Inc. Diane, J. and J. Evdemon (2007). Web Services Business Process Execution Language Version 2.0, OASIS Standard. Einspanier, U., Lutz, M., Senkler, K., Simonis, I. and A. Sliwinski (2003). “Toward a Process model for GI Service Composition”, Proceedings of GI-Days 2003, June 26-27 2003, IFGI, Münster, Germany. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Frigg, R. and S. Harmann (2006). Models in Science, at http://plato.stanford.edu/entries/models-science/, [accessed 14 June 2010]. Geller, G. N. and F. Melton (2008). Looking Forward: Applying an Ecological Model Web to assess impacts of climate change, Biodiversity 9 (3&4). Granell, C., L. Díaz and M. Gould (2010), Service-oriented Applications for Environmental Models: Reusable Geospatial Services, Environmental Modelling & Software 25 (2): pp. 182–198. Highland, H. J. (1973). A taxonomy of models, ACM SIGSIM Simulation Digest 4 (2) pp. 10–17. Karastoyanova, D., Van Lessen, T., Leymann, F., Nitzsche, J. and D. Wutk(2008). WS-BPEL Extension for Semantic Web Services (BPEL4SWS) Version 1.0. Klopfer, M. and I. Simonis (2009). SANY - An Open Service Architecture for Sensor Networks, SANY Consortium. Kurzbach, S., Pasche, E., Lanig, S. and A. Zipf (2009). Benefits of Grid Computing for Flood Modeling in Service-oriented Spatial Data Infrastructures, GIS.Science, 3/2009: pp. 89-97. Lanig, S., Schilling, A., Stollberg, B. and A. Zipf (2008). “Towards StandardsBased Processing of Digital Elevation Models for Grid Comput- ing through Web Processing Service (WPS)”, ICCSA ’08: Proceedings of the International Conference on Computational Science and Its Applications, Part II, Springer, Berlin, Heidelberg, pp. 191–203. Maué, P. and S. Schade (2009). Data Integration in the Geospatial Semantic Web, Cases on Semantic Interoperability for Information Systems Integration: Practices and Applications, 11 (4): pp. 100–122. Mineter, M., Jarvis, C. and S. Dowers (2003). From Stand-alone Programs Towards Grid-aware Services and Components: A Case Study in Agricultural Modelling with Interpolated Climate Data, Environmental Modelling & Software, 18 (4): pp. 379–391. Na, A. and M. Priest (2007). OGC Sensor Observation Service Implementation Specification, OGC 06-009r6, Open Geospatial Consortium, Inc. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Pebesma, E., Cornford, D., Dubois, G., Heuvelink, G., Hristopoulos, D., Pilz, J., Stoehlker, U. and J. Skoien (2009). “INTAMAP: An Interoperable Automated Interpolation Web Service”, Proceedings of StatGIS 2009, June 16-18 2009, Milos, Greece. Percivall, G. (2002). “ISO 19119 and OGC Service Architecture”, Proceedings of FIG XXII International Congress, Washington D.C., USA. Reed, M. (1995). Quantitative Analysis of Alternate Oil Spill Response Strategies using OSCAR, Spill Science & Technology Bulletin 2 (1): pp. 67–74. Schut, P. (2007). OGC Web Processing Service Implementation Specification, OGC 05-007r7. Sgroi, M., Wolisz, A., Sangiovanni-Vincentelli, A. and J. Rabaey (2005). “A Service-Based Universal Application Interface for Ad Hoc Wireless Sensor and Actuator Networks”, in: W. Weber, J. Rabaey, E. Aarts (Eds.), Ambient Intelligence, Springer. Simonis, I. (2007). OpenGIS Sensor Planning Service Implementation Specification, OGC 07-014r3, Open Geospatial Consortium, Inc. Tsalgatidou, A., Athanasopoulos, G., Pantazoglou, M., Pautasso, C., Heinis, T., Grønmo, R. , Hoff, H., Berre, A., Glittum, M. and S. Topouzidou (2006). Developing Scientific Workflows from Heterogeneous Services, SIGMOD Rec. 35 (2): pp. 22–28. Tsalgatidou, A., Athanasopoulos, G. and M. Pantazoglou (2008). Interoperability Among Heterogeneous Services: The Case of Integration of P2P Services with Web Services., International Journal of Web Service Research 5 (4): pp. 79–110. Urvois, M. and A. J. Berre (2009). D1.3 - Experience Report, SWING Project Deliverable. Vretanos, P. (2005). Web Feature Service Implementation Specification, OGC Implementation Specification, OGC 04-094Open Geospatial Consortium, Inc. Whiteside, A. and Evans, J. (2007). Web Coverage Service (WCS) Implementation Standard. OGC 07-067r5, Open Geospatial Consortium, Inc. International Journal of Spatial Data Infrastructures Research, 2011, Vol.6, xx-yy Williams, M., Conford, D., Bastin, L. and E. Pebesma (2009). Uncertainty Markup Language (UncertML), OGC 08-122r2, Open Geospatial Consortium, Inc.