Loading...
Please wait, while we are loading the content...
Similar Documents
Development of a WPS Process Chaining Tool and Application in a Disaster Management Use Case for Urban Areas
| Content Provider | Semantic Scholar |
|---|---|
| Author | Stollberg, Beate |
| Copyright Year | 2009 |
| Abstract | The recently approved OGC Web Processing Service (WPS) specification defines a generic interface for providing geo-processing functionality in a standardized way. Web Services in general can be composed in service chains for carrying out more complex tasks. This paper presents an approach for offering a chaining tool for WPS processes in a simple as possible way. Basic functionalities can be combined in extensive workflows without touching any source code, just by creating a XML file according to our developed XML schema. A proof of concept is given by applying the developed implementation in a use case of disaster management for urban areas. In conclusion our implementation makes it easy for any GIS user to provide new complex processes by our developed framework. 2 THE OGC WPS INTERFACE The WPS standard is quite open and such a service may provide simple calculations (e.g. the calculation of a buffer) as well as complex computations (e.g. the generation of a climate model). Thus, in principle there are no restrictions on what can be implemented using the WPS interface. There are three mandatory operations that must be performed by a WPS, namely GetCapabilities, DescribeProcess and Execute. When a GetCapabilities request is made to the WPS, it must send back an XML document describing the service capabilities. This XML response must contain metadata about the service itself and the processes it provides. When a DescribeProcess request is made to the WPS, it must reply sending back an XML document describing one or more of the available web processes in detail. The document must specify the input parameters and formats for executing a specific process and the output format of the process result. Finally the process is executed when an Execute request is sent to the service. As the specification allows any kind of geoprocessing functionality it can be applied to a wide variety of domains and tasks. Some examples include disaster management (Stollberg & Zipf 2007), forest fire analysis (Friis-Christensen et al. 2007), generalization (Foerster & Stoter 2006), hydrological models (Diaz et al. 2008), housing market analysis (Stollberg & Zipf 2008), biodiversity research (Graul & Zipf 2008), time series analysis (Gerlach et al. 2008), precision farming (Nash et al. 2008) etc. 3 WEB SERVICE ORCHESTRATION An established standard concerning Web Service Orchestration (WSO) is the use of the Business Process Execution Language (BPEL) which uses the Web Service Description Language (WSDL). WSDL is a standard for the description of a Web Service interface and acts as the link between the Orchestration Engine (OE) and the services involved. The WSDL interface offers the possibility of providing a defined functionality for a client where the underlying implementation is not transparent. As the WPS standard defines the service itself but not the underlying processes provided by the implementation this means in consequence that there is no predefined WSDL description for a WPS. Rather a process developer is forced to define a WSDL description of each process together with a definition of the DescribeProcess document. In the case of a provided WSDL document for a WPS process it is then possible to address this process by means of BPEL and integrate it within a chain of services. This implies that an Orchestration Engine is set up which is able to execute the chain in turn. BPEL and WSDL are mainstream IT standards and not yet well established within the Geographic Information (GI) community. The use of these standards is at the moment burdened with a lot of overhead (defining WSDL documents by hand, setting up and using an OE). For this reason we developed another approach by simple means for the easy chaining of WPS processes within the GI community. 4 DEVELOPMENT OF A SERVICE CHAIN SCHEMA The idea behind our approach is the development of a simple XML schema defining a service chain. Such a service chain can then be presented according to the schema by a single XML document. This document in turn can be interpreted by a suitable implementation which is able to parse it and execute the involved processes in the defined order. For the development of such a schema we made the considerations listed in the following section. It has to be pointed out that a WPS instance is able to provide several processes. For this reason a single service within a chain is synonymous to a WPS process. This means any service equates with any process of any WPS instance. In the following we are speaking of services for simplifying matters. The following considerations were made: − Each service chain consists of several services − Each service has a web address (WPS Server) and an identifier (as a WPS can provide more than a single process) − Each service needs a unique identifier within the service chain − Each service defines any number of inputs and outputs − Each input and output of a service has an identifier − Each input of a service can be a predefined literal value, a predefined web-accessible resource providing complex spatial data (e.g. the address of a Web Feature Service (WFS) layer), a value which is passed within the service chain request or the output of a previously executed service within the chain (in this case the unique identifier of this service in the chain is required besides the corresponding identifier of the output of this service) − The complete service chain consists of any number of outputs − Each output of the service chain has an identifier − Each output of the service chain is the output of a specific executed service within the chain and can be defined by the unique identifier of this service and the identifier of the output of this service Figure 1. The element Service within the developed ServiceChain schema. Figure 2. The element Input within the developed schema. Figure 3. The element OutputServiceChain within the developed schema. 5 EXAMPLE SERVICE CHAIN IN A DISASTERMANAGEMENT USE CASE The WPS ServiceChain implementation can be used in a wide area of applications and independent from a specific domain. Any functionality which is available as a WPS process (on any server instance) can be integrated into a more complex workflow. For proving our concept, we want to give an example in the field of disaster management in urban areas. Apart from this example application we want to emphasize that the concept is not confined to a specific theme but applicable in a wide range of domains. In our use case we assume that a gas leakage was detected in a densely populated area. The toxic gas, which is a threat to human beings, is spreading. Furthermore we assume that there is a shared network of gauging stations available which provides measured values of air pollution within this area. The user in our scenario might be a staff member of the disaster management department of the affected city. He has to initiate further actions and has to answer three specific questions for this purpose: − Are there any gauging stations providing real-time information about air pollution close to the location of the leakage? − Approximately how many people have to be evacuated close to the location of the leakage? − Are there any evacuation shelters close to the affected area where the evacuees can be safely assembled together? All three questions imply several GIS operations and each can be provided as a new complex process. For answering the first question of close-by gauging stations two steps have to be executed. In the first step a buffer operation around the gas leakage location is carried out. This is followed by a polygon-contains-point analysis as a second step. Thereby the result of the first operation presents the input for the second operation within the workflow. The scenario is illustrated in figure 4. The complex process described above can be expressed by means of our ServiceChain schema as presented in figure 5. Figure 4. Finding gauging stations within a specific buffer around a gas leakage location. Figure 5. Service Chain example of finding gauging stations within a specific buffer by means of a XML document according to our developed schema. The complex process consists of two services: Service1 is defined in lines 5-9 within the XML document depicted in figure 5 and Service2 is defined in lines 10-14. Service1 takes two input parameters, namely the InputGeometry which is in our scenario the location of the gas leakage and secondly the desired BufferDistance. Both input parameter will be part of the request which has so be sent in order to execute the complex process. Furthermore Service1 creates one output, namely the BufferedGeometry. Service2 takes again two input parameters, namely PolygonFeatures which is in our scenario the buffered gas leakage location and respectively the output of Service1. For this reason the input parameter is set as ProcessedData. The second input parameter of Service2 is PointFeatures. This is a dataset of all available gauging stations of the city. Furthermore Service2 has one output called JoinedFeatures. These JoinedFeatures, which are the gauging stations located within the buffer of the gas leakage, are also the desired output for the complete complex process. This is expressed within the XML tag OutputServiceChain. After deploying this complex process by means of our developed ServiceChain schema the new WPS process is available within our framework and the user is able to execute the process at any time with the relevant input parameters (gas leakage location, width of the buffer to calculate, location of the gauging stations dataset). It is now not necessary anymore for the user to execute the two separate processes one after another but he has the ability to carry out both steps within one operation. The result is a number of gauging stations within the specified buffer around the gas leakage location. These stations might deliver real-time data about air pollution and give informat |
| File Format | PDF HTM / HTML |
| DOI | 10.1201/9780203869352.ch24 |
| Alternate Webpage(s) | http://koenigstuhl.geog.uni-heidelberg.de/publications/bonn/conference/Paper42-UDMS-StollbergZipf.pdf |
| Alternate Webpage(s) | http://www.geog.uni-heidelberg.de/md/chemgeo/geog/gis/paper42-udms-stollbergzipf.pdf |
| Alternate Webpage(s) | https://doi.org/10.1201/9780203869352.ch24 |
| Language | English |
| Access Restriction | Open |
| Content Type | Text |
| Resource Type | Article |
