Performance Test of Asynchronous Process of OGC WPS 2.0: A Case Study for Geo-based Image Processing

1. Introduction

The Open Geospatial Consortium, Inc. (OGC) has developed open standards for geo-based data compatibility and interoperability. OGC-based standards cover technically significant ones such as Web Map

Service (WMS), Web Feature Service (WFS), Web Coverage Service (WCS), and Web Processing Service (WPS) (Open Geospatial Consortium, 2014). The implemented system in compliance with OGC standards shows many advantages in the aspects of information integration and maintenance, information

Performance Test of Asynchronous Process of OGC WPS 2.0:

A Case Study for Geo-based Image Processing

Gooseon Yoon* and Kiwon Lee**

*Department of Information Systems Engineering, Hansung University

**Department of Electronics and Information Engineering, Hansung University

Abstract : Geo-based application services linked with the Open Geospatial Consortium (OGC) Web Processing Service (WPS) protocol have been regarded as an important standardized framework for of digital earth building in the web environments. The WPS protocol provides interface standards for analysis functionalities within geo-spatial processing in web-based service systems. Despite its significance, there is few performance tests of WPS applications. The main motivation in this study is to perform the comparative performance test on WPS standards. Test system, which was composed of WPS servers, WPS framework, data management module, geo-based data processing module and client-sided system, was implemented by fully open source stack. In this system, two kinds of geo-based image processing functions such as cloud detection and gradient magnitude computation were applied. The performance test of different server environments of non-WPS, synchronous WPS 1.0 and asynchronous WPS 2.0 was carried out using 100 threads and 400 threads corresponds client users on a web-based application service. As the result, at 100 threads, performance of three environments was within an adjacent range in the average response time to complete the processing of each thread. At 400 threads, the application case of WPS 2.0 showed the distinguished characteristics for higher performance in the response time than the small threads cases. It is thought that WPS 2.0 contributes to settlement of without performance problems such as time delay or thread accumulation.

Key Words : Cloud computing, Orfeo Toolbox, WPS 1.0, WPS 2.0, ZOO project

Received July 18, 2017; Revised August 16, 2017; Accepted August 17, 2017.

†

Corresponding Author: Kiwon Lee ([email protected])

This is an Open-Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons. org/licenses/by-nc/3.0) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.

Article

sharing and distribution, and quality improvement and consistency in utilization of geo-spatial information (Percival, 2010). Application of standards should be considered as one of the crucial factors to help facilitate interoperable geo-spatial service implementation.

Among lots of OGC standards, the WPS protocol is an interface standard used when designing and implementing a web service system with the main feature of geo-spatial processing. As geo-spatial web services handling multiple types of data and contents are getting popular, remotely distributed systems are more effective than centralized ones for those services.

Furthermore, interoperable geo-spatial data processing functionalities based on WPS standards provide client- side user operations by requesting algorithms or practical functions in external servers without any installation processes of applicable tools for a given task. The WPS 1.0 standard defines how a client-side user requests the execution of a target process, and how the output produced from that process is handled, using three operations: GetCapabilities, DescribeProcess, and Execute. In case of WPS 2.0, total six operations are defined as GetStatus, GetResult and Dismiss, in addition to three ones of WPS 1.0. Two versions of this standard, WPS 1.0 and WPS 2.0, are used in this experiment, and WPS 2.0 is the main focus. In general, these interface standards affect data processing time and system performance, and this issue is one of the important task of web services in the field of remote sensing.

The availability of WPS servers for extension of features regarding scalable geo-processing web was investigated (Lopez-Pellicer et al., 2012). The service- oriented modelling for a service that builds from WPS protocol, showing a hydrology model hosted as a WPS web service was studied (Castronova et al., 2013). An event-driven architecture for geospatial processing in the asynchronous mode to find the most suitable push- based messaging technologies for application with WPS was proposed (Westerholt and Reash, 2014).

There are some WPS compliant open sources such as 52° North, Deegree, GeoServer, PyWPS, and ZOO project and these five kinds of WPS framework were evaluated in the response time and the response size (Poorazizi and Hunter, 2015; Swain et al., 2015).

Brovellia et al.(2016) summarized free and open source software for digital earth supporting openness, sharing, and distributed-collaborative development included OGC standards processing. Among freely available WPS frameworks, we utilized the ZOO project(2017).

It is known the main advantageous points of easy process configuration and native development languages supporting. It provides the practical components to utilize and comprises server, services, appllication programming interface(API), and client for WPS. The WPS interfaces provide methods to build practical functions which developed separately to fulfil user demand on the web, and most geo-based data processing algorithms can be implemented under this scheme. For the geo-spatial processing in this study, two kinds of open source were used: Geospatial Data Abstraction Library (GDAL) for a geo-spatial data input and output processing and the Orfeo ToolBox (OTB) for satellite image processing algorithms. This implemented system provides experiment environment for performance testing and interoperable processing of geo-based image datasets among two or more externally located remote servers.

Giuliani et al.(2013) presented the result of the

server-side performance test using free and open source

software on different WFS and WCS services. As

another case for performance test, Lankinen and

Savolainen(2014) reported performance testing of

WMS and WMTS in the tiling process and Java virtual

machine in EU INSPIRE project. According to Open

Geospatial Consortium(2014), to investigate the

performance and scalability of OGC-compliant

geospatial services was necessary in the use of OGC

data services on the cloud infrastructures, and reported

that WMTS service was more efficient than WMS

service in the imagery searching process. In an elastic parallel OGC WPS service in the vegetation condition index computation using the remote sensing data in a cloud computing environment, Tan et al.(2015) presented the experimental result of execution time to show high performance of both parallel WPS services on physical servers and cloud-based elastic parallel WPS. Recent, WPS 2.0 interfaces in the geo-based application domain have been applied as the main processing components (Yang et al., 2016; Herle and Blankenbach, 2017), but there are a few considerations with respect to performance capabilities

There was an implemented a web-based system for geo-spatial processing functions by using the ZOO project platform to comply with WPS 2.0 in the web framework for the Korean electronic government (Yoon et al., 2016). Performance test was performed five requests of GetCapabilities, DescribeProcess, Execute, GetStatus, GetResult in WPS 2.0 (Yoon and Lee, 2016). This study conducted the feasible performance checks on the asynchronous process of WPS 2.0 in the image processing algorithms to compare performance of non-WPS case and a synchronous case, with the same experiment conditions on the implementation system by fully open source.

2. OGC WPS 2.0 and an Implementation using ZOO Project

1) OGC WPS 2.0

Most OGC standards have had great influence being widely used on both sides of industry and research aspect (Lopez-Pellicer et al., 2011). Among OGC- based standards, WPS is an interface and protocol in which geo-spatial data processing can be applied and accessed on the web, for the compatibility with other geo-spatial web services. If applied this standard, web systems can interact with other remote servers, with the

merit of system reusability improvement. Geo-spatial processing applications on this scheme can enhance interoperability and accessibility of geo-spatial data (Xavier et al., 2015; Yue et al., 2016). WPS 2.0 has been added functionalities for the requirements of new web technologies on the previous version. WPS 2.0 standard supports interfaces to facilitate both synchronous and asynchronous processing. In WPS 1.0, asynchronous processing can be also available by polling method, which means that the host checks the state of clients by active sampling scheme and then communicates with optimal client. The improvement in WPS 2.0 is that server may provide an estimate when the process results will be available and may suggest a polling time for the next status check. WPS clients may implement a better polling policy that implies less polling requests and less time between the end of computing process on the server side and the request for retrieving the results.

The asynchronous processing to conduct web-based

geo-spatial processing service is possible to implement

a system in which a new or the other geo-spatial

processing service can be activated before completion

of any previously performed processing. This protocol

standard has six interface definitions: GetCapabilities,

DescribeProcess, Execute, GetStatus, GetResult and

Dismiss (Mueller and Pross, 2015). GetCapabilities and

DescribeProcess are interfaces to return metadata and

to return detailed information on geo-spatial processing

functions on WPS servers as XML documents,

respectively. Execute is an interface to request

execution of geo-spatial function and it does not need

completion of the execution requested. GetStatus is an

interface that returns progress status to XML

documents. GetResult returns of value regarding geo-

spatial processing function corresponding to a job

identifier. Dismiss is an interface to terminate a process

corresponding to a job identifier.

2) Implementation of the performance test system

Geo-based data processing algorithms within WPS servers can be accessible to general users, and data processing functionalities can be utilized through simple access from multiple external servers.

Additionally, this system can be deployed to construct

a web service system that is distributed by an application server in the virtual machine in a cloud environment. Cloud computing is used owing to the practice of providing computing resources such as the networks or the servers in a dynamic manner on the web.

Fig. 1(a) is a schematic design and its components

Fig. 1. (a) Scheme of the structured WPS interactive process, (b) WPS 2.0 servers mediation.

of the experimental system for the interactive mediating of WPS servers on the virtual machine, which were constructed with the OpenStack cloud environment.

Fig. 1(b) shows that a web service that complies with WPS manages client-side requests and WPS 2.0 servers-side responses to perform geo-based data processing through standard requests between client and those servers. Cloud server was modified for the experiment from the products implemented in the previous works (Yoon and Lee, 2016; Yoon et al., 2016).

The ZOO project is implementation platform that supports WPS interface standards, based on open source. It is composed of four components: ZOO- Kernel, ZOO-Services, ZOO-API and ZOO-Client.

This was used in the experimental application system for WPS performance testing, as a framework to build WPS servers. ZOO-Kernel is for interfaces and communication methods, with requests and responses conforming to the WPS standards. ZOO-Services is to manage and offer geo-spatial processing functions as a web service, composing of configuration files and source codes for the processing execution and interworking with other open sources such as GDAL, OTB, or the Computational Geometry Algorithms Library (CGAL). In the case of services by being separately developed, interoperability with WPS interface standards is necessary across diverse development or operating environments. The main

point of this study is to check performance test of WPS interface standards. Therefore, core components of the ZOO project of ZOO-Kernel and ZOO-Services were used, except two optional components such as ZOO-API and ZOO-Client. Using interfacing and communicating methods defined in WPS can show processing information and build a processing for user interfaces. Process status in real time can be checked after execution request of a process, and functions for killing processes during processing can be implemented, owing to supporting of the asynchronous processing of the WPS 2.0 standard.

Table 1 is the list of open source used to perform the performance test of WPS utilization. The server operating system is Ubuntu, and the web server used the Apache as a web container for web servers. The web system was developed based on the ZOO project to comply with the WPS and WPS of the satellite imagery. The satellite imagery processing process in this implementation utilized GDAL and OTB, as well as GeoServer for managing and distributing satellite images and processing results. OTB is open source core modules, providing lots of practical algorithms.

OpenLayers and jQuery were used for satellite images and user interfaces on the Web.

Fig. 2 is the basic system configuration and flow chart for performing a comparative performance test among non-WPS framework and WPS standards. All experiment cases are basically on the system structure

Table 1. Open source table used for system configuration

Type Name / Version URL

Server

Operating System Ubuntu / 14.04 LTS https://www.ubuntu.com/

Web Server Apache / 2.4.7 https://www.apache.org/

Web Container Tomcat / 7.0.52 http://tomcat.apache.org/

WPS Platform ZOO Project / 1.5 http://www.zoo-project.org/

Geospatial Data I/O Library GDAL / 1.11.2 http://www.gdal.org/

Satellite Image Processing OTB / 5.2.1 https://www.orfeo-toolbox.org/

Geospatial Data Storage Server GeoServer / 2.9 http://geoserver.org/

Client Web Mapping Library OpenLayers / 3.19.1 https://openlayers.org/

Java Script Library jQuery / 3.1.1 https://jquery.com/

to execute geo-based data processing algorithms through a web framework, and then receive the resulting values to the client-side. Fig. 2(a) is the case of a satellite image processing through a common gate interface(CGI) program on a web server without having to apply a WPS. Fig. 2(b) is the case of the application of WPS 1.0, which requests a process and then returns the result. Fig. 2(c) is a case with WPS 2.0, being capable of identifying the satellite images processed asynchronously. In order to check the progress status, the GetStatus request is performed periodically, and the return value of the GetResult request is returned when

‘Succeeded’ as the response is returned.

3. Performance Test and Results

JMeter is a tool for performing performance measurement and load testing of the web system with open source software (JMeter, 2016). This provides a variety of functions for measuring performance, generating responses, responding to requests, and responding to errors. The parameters for the performance test were set as thread status corresponding user in the client-side and properties:

thread generation, number of activated threads, activation time of threads, and duration and ramp-up period of threads. Ramp-up time is the time to get all threads sent for the executing process.

As the experiment conditions applied in this study, the number of threads were two cases of 100 and 400, ramp-up period was 5 seconds. This means 100 users or 400 users in 5 seconds were accessed to the web service and performed the data processing functions provided by that system. In the case of 100 threads, 20 threads, as thread count, in every one second were activated as the concurrent users. In the case of 400 threads, 80 threads in every one second did as the concurrent users. In the duration time of 5 seconds for the target applied processing function, some threads at the early activated are quickly completed, but some threads are proceeded in the next second. As for geo- based data processing function, two kinds of algorithms for optical satellite imagery were applied: cloud detection and gradient magnitude. The cloud detection functor is a chained processing by computation of a spectral angle, multiplication by a gaussian factor and thresholding to get a resultant binary image.

Computation of gradient magnitude is a common operation to determine object contours or to separate Fig. 2. WPS performance comparison configuration and flow chart: (a) Non-WPS case, (b) synchronous process case of WPS

1.0, and (c) asynchronous process case of WPS 2.0.

homogeneous regions in the data imagery.

1) Cloud detection case

Fig. 3 shows the results of the cloud detection algorithm provided by OTB Development Team(2017).

The horizontal and the vertical axes indicate the number of activated threads and the average response time for thread completion on this algorithm, respectively. In the case in Fig. 3(a) where 100 threads were activated, the average response time between 6,000 and 13,000 milliseconds (ms) was shown in the case of a non- WPS, and it is similar to the results of WPS 1.0.

In WPS 2.0, the average response time was shown

between 5000 and 11,000 ms, showing little better performance than the other two cases. In Fig. 3(b) for 400 threads, the average response time of 400,000 ms was shown after first 100 threads were completed, when the WPS was not applied and the WPS 1.0 was applied. On the contrary, that of WPS 2.0 was gradually lowered, showing the average response time of approximately 15,000 ms, and it reveals a good performance. An asynchronous processing feature of WPS 2.0 contributes to performance improvement.

Fig. 3. Performance comparison of cloud detection processing of synchronous process case of WPS 1.0 and

asynchronous process case of WPS 2.0, besides non-WPS: (a) 100 thread case, (b) 400 thread case.

2) Gradient magnitude case

Fig. 4 represents the results of the gradient magnitude algorithm by OTB Development Team (2017). In the case in Fig. 4(a) where 100 threads in the case of a non-WPS were activated, the average response time between 4,000 to 12,000 ms was shown.

While, the results of WPS 1.0 and WPS 2.0, the average response time was shown from 5000 to 13,000 ms, after first 100 threads were completed, similar to the previous case. In Fig. 4(b) for 400 threads, the

average response time of 400,000 ms in both non-WPS and WPS 1.0 was measured. But, the average response time of WPS 2.0 shows better performance between 50,000 and 120,000 ms than that of previous cases. As the similar trend of performance improvement as the previous case, asynchronous processing works in this experiment.

Fig. 4. Performance comparison of gradient magnitude processing synchronous process case of WPS 1.0 and

asynchronous process case of WPS 2.0, besides non-WPS: (a) 100 thread case, (b) 400 thread case.

4. Concluding Remarks

According to advancing geo-spatial web technologies and their applications, technological consideration for compatibility and interoperability among heterogeneous browsers and platforms is needed. Thus, OGC standards are regarded as core parts of system design and development phase of web- based geo-spatial systems. Especially, WPS should be considered, if application purpose of the web service contains data processing modules. Geo-based application services linked with WPS standard have been regarded as an important theme in web environments for digital earth building. Studies to examine the performance improvement according to asynchronous process of WPS 2.0 in geo-based information processing systems are not presented yet.

By test system implementation based on the open source approach, the performance test of different server environments such as non-WPS, WPS 1.0 and WPS 2.0 were carried out using 100 threads and 400 threads. Web server is operated in the cloud computing environment, and two geo-based data processing functions of cloud detection and gradient magnitude computation were used. Client system and server-side system were also implemented by using various types of open sources including ZOO project for WPS mediation.

As the result, at the small number of threads of 100, three cases were in the similar range in the response time for thread completion. At the large number of threads of 400, WPS 2.0 showed the high performance in the response time. It is thought that the main feature of the asynchronous processing functionality of WPS 2.0 contributes to performance improvement. This is the practical performance test to check the feasibility of WPS standards. Despite this consequence interpretation, there are various kinds of open source supporting WPS 2.0 standard, and implementation

strategy and technological scheme also varies. Thus, these aspects could affect the result of WPS performance. Thus, more experiments and application cases with other geoprocessing functions and server implementations are needed for generalization and development for of the WPS application model. The results of geo-spatial image processing by this system implies further applicability and extensibility of WPS 2.0 on user interfaces for practical applications.

Acknowledgement

This research was financially supported by Hansung University.

References

Brovellia, M. A., M. Minghini, R. Moreno-Sanchez, and R. Oliveira, 2016. Free and open source software for geospatial applications (FOSS4G) to support Future Earth, International Journal of Digital Earth, 9(10): 386-404.

Castronova, A., J. L. Goodall, and M. M. Elag, 2013.

Models as web services using the Open Geospatial Consortium(OGC) Web Processing Service(WPS) standard, Environmental Modelling & Software, 41(3): 72-83.

Poorazizi, E. and A. J. S. Hunter, 2015. Evaluation of Web Processing Service Frameworks, OSGEO Journal, 14(1): 29-42.

Herle, S. and J. Blankenbach, 2017. Enhancing the OGC WPS interface with GeoPipes support for real-time geoprocessing, International Journal of Digital Earth, 10(5): 1-16.

Giuliani, G., A. Dubois, and P. Lacroix, 2013. Testing

OGC Web Feature and Coverage Service

performance: Towards efficient delivery of

geospatial data, Journal of Spatial Information

Science, 7: 1-23.

JMeter, 2016. Apache JMeter Overview, http://jmeter.

apache.org.

Lankinen, M. and S. Savolainen, 2014. Performance testing of INSPIRE and OGC services, http://

inspire.ec.europa.eu/events/conferences/inspire _2014/pdfs/19.06_5_09.00_Sampo_Savolainen.

pdf.

Lopez-Pellicer, F. J., W. Renteria-Agualimpia, R. Béjar, A. J. Florczyk, P. R. Muro-Medrano, and F. J.

Zarazaga-Soria, 2012. Availability of the OGC geoprocessing standard: March 2011 reality check, Computer & Geoscicnecs, 47(8): 13-19.

Mueller, M. and B. Pross, 2015. OGC WPS 2.0 Interface Standard, Open Geospatial Consortium Inc., p. 133.

Open Geospatial Consortium, 2014. Testbed 10 Performance of OGC® Services in the Cloud:

The WMS, WMTS, and WPS cases, OGC 14- 028r1, 47p.

OTB Development Team, 2017. The ORFEO Tool Box Software Guide Updated for OTB-6.0.0, https://www.orfeo-toolbox.org/packages/OTB SoftwareGuide.pdf.

Percivall, G., 2010. The application of open standards to enhance the interoperability of geoscience information, International Journal of Digital Earth, 3(4): 14-30.

Swain, N. R., K. Latu, S. D. Christensen, N. L. Jones, E. J. Nelson, D. P. Ames, and G. P. Williams, 2015. A review of open source software solutions for developing water resources web applications, Environmental Modelling

& Software, 67(5): 108-117.

Tan, X., L. Di, M. Deng, J. Fu, G. Shao, M. Gao, Z.

Sun, X. Ye, Z. Sha, and B. Jin, 2015. Building

an Elastic Parallel OGC Web Processing Service on a Cloud-Based Cluster: A Case Study of Remote Sensing Data Processing Service, Sustainability, 7(10): 14245-14258.

Westerholt, R. and B. Resch, 2014. Asynchronous Geospatial Processing: An Event-Driven Push- Based Architecture for the OGC Web Processing Service, Transactions in GIS, 19(3): 455-479.

Xavier, E. M. A., F. J. Ariza-Lopez, and M. A. Urena- Camara, 2015. Web Service for Positional Quality Assessment: The WPS TIER, ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information, II-3/W5: 257-262.

Yang, C., Z. Xie, and Z. Xu, 2016. An asynchronous Geoprocessing Workflow and its application to an Antarctic ozone monitoring and mapping service, International Journal of Digital Earth, 9(2): 156-170.

Yoon, G. and K. Lee, 2016. Application of OGC WPS 2.0 to Geo-Spatial Web Services, Journal of the Korean Association of Geographic Information Studies, 19(3): 16-28. (in Korean with English abstract)

Yoon, G., K. Kim, and K. Lee, 2016. Performance Testing of Satellite Image Processing based on OGC WPS 2.0 in the OpenStack Cloud Environment, Korean Journal of Remote Sensing, 32(6): 617-627. (in Korean with English abstract)

Yoon, G., K. Kim, and K. Lee, 2017. Linkage of OGC WPS 2.0 to the e-Government Standard Framework in Korea: An Implementation Case for Geo-Spatial Image Processing, ISPRS International Journal of Geo-Information, 6(1):

25-38.

ZOO-Project. 2017. http://www.zoo-project.org.