OGC Testbed-13: Cloud ER

The following requirements are to be addressed in this ER:

Current cloud computing architectures have advanced from virtual hypervisors and shared compute resources to include containerization using Docker. As cloud computing continues to evolve, the scientific community seeks to achieve a more efficient process for deploying, processing, and retrieving data results. It is true that today, acquiring shared computing resources is easier than ever. However significant effort is still required in order to stage computing resources, determine compute requirements, deploy software libraries, and general administrative tasks more suited to information Technology (IT) administrators before processing of scientific data can occur. Furthermore, efficient use of compute resources when not being utilized needs to be accounted for through scalable solutions.

This engineering report seeks to document the Testbed 13 cloud implementations in which OGC web service specifications are used in conjunction with software containers (i.e. Docker) to establish a process flow and retrieve results for data processing functions. The goal is to reduce the amount of administrative work required to stage compute resources and process data, and simplify data retrieval, specifically for earth observation data which can vary depending on data size or volume.

The Working Group identified for the review of this engineering report is the Big Data Domain Working Group (DWG). The Big Data DWG’s current purpose statement defines their scope of work to include Big Data interoperability and especially analytics. However, key members of the DWG are interested in expanding the scope to include cloud in their discussions. Particularly, at least one member of the DWG is also working on multi-cloud discovery and access to Earth Observation data within cloud compute architectures.

The work of the EOC thread aligns with the Big Data DWG interests due to the use of earth observation data storage and processing of this data using OGC WPS standards in a dynamic cloud deployment for interoperable ease of access for scientific study. The goal of this effort is to improve the way EO data is disseminated, processed, stored, and searched without scientists needing to understand how to administer cloud computing resources. This engineering report describes future architectures and deployment methods for cloud architectures utilizing OGC WPS. The use of these architectures may assist in future developments of data processing including use cases such as big data processing. Other OGC W*S services may be considered as future follow-on effort.

All questions regarding this document should be directed to the editor or the contributors:

The work contained herein may lead toward future interoperability tests across private-public cloud implementations. Future developments in cloud computing technology and container technology may lead to future work in interoperability research. The recommended future work on this topic includes the following:

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

A virtualized computing resource which provides functionality needed to execute an operating system. A hypervisor is used for native execution to share and manage hardware, allowing for multiple environments which are isolated from one another, yet exist on the same physical machine.

Two separate implementations have been developed by Computer Research Institute of Montréal (CRIM) and George Mason University (GMU), respectively, to support the testbed experiments. Each implementation has been developed independently using various software tools and specifications to achieve the same implementations goals and capabilities as follows:

Based on the architectures described earlier, the overview architecture can be expanded to describe additional components within each category as shown in Figure 2 below. The WPS Client may also include a graphical user interface and security functions. The WPS Server may include synchronous or asynchronous monitoring such as a polling function to get status of a running process. The VMs may contain Docker (see Section Docker Containers) containers and the RSTB processes to process EO data and produce a result. Additionally, a Docker Registry may be used for distributing the Docker images. Data may be accessed in external clouds, and the resulting data may be shared across shared cloud storage.

In general, the location of the WPS server is agnostic from the cloud environment and can be contained as a separate server or within a cloud server. While the WPS may not be represented within a cloud environment in Figure 1, the actual deployment may be within the same or separate cloud environment. However, it is important to note that the cloud environments are able to retrieve data (i.e., RADARSAT-2 Samples) via an external cloud. In this combined expanded architecture, the WPS client contains multiple functions such as application execution and monitoring functions. The virtual machines deployed in the cloud architectures contain application containers using Docker. Both architecture implementation follow this expanded architecture with various differences in how each configures their Docker deployments and VM provisioning.

The development process for the cloud environments were broken out into a Work Breakdown Structure as shown in Figure 3. This structure was developed and agreed upon by all participants to ensure all implementation aspects of the cloud environment were considered.

The engineering report describes the architecutre, configuration, execution, test, and demonstration of the component implementations as follows:

GMU has established an architecture framework as seen in Figure 4 below. The framework is divided into four layers: Client, OGC Web Services, Cloud environment, and Internet (i.e., external network). The client consists of a browser-based application dashboard containing stored WPS requests, virtual host locations, and additional features such as priority and resource allocation functions.

All the capabilities of the WPS server and cloud environment are performed via the WPS interface. In other words, WPS is the only exposed interface for users to access the cloud and Docker container functionality. The user (i.e., Actor) can perform WPS request functions through the client to an OGC WPS 2.0 implementation which also resides in the cloud. Job requests/responses with the cloud are managed by Secure Shell (SSH) using the Docker command-line interface (CLI). The WPS server RSTB processes requests using the Docker CLI by deploying Docker containers in a Virtual Machine (VM) (i.e., cloud instance). The processes contained within each job request publishes the final products via an OGC Web Coverage Service (WCS) service. The final product is returned through OGC WCS. The WPS client receives reference URL to the WCS containing the results.

Additionally, the WPS and cloud environment can interact over the Amazon Elastic Compute Cloud (EC2) API which can manage the deployment and scalability of VM instances using the Amazon Cloud Management Server. The cloud is capable of communicating with other cloud blocks to exchange data or call geospatial functions from different sources hosted externally to the local cloud environment. It should be noted that while there is a good compatibility guide to the OpenStack implementation of the EC2 API, many commands are not supported [EC2].

The CRIM High Level Architecture contains a WPS built on the open-source PyWPS 4.0.0, an OGC WPS 1.0 specification. Since PyWPS uses Python as its code-base, several software applications and libraries adopted for this implementation are also Python based. The current solution targets Python 2.7, in part because PyWPS 4.0 still exhibits input/output issues with Python 3.6. Python 2.7 is currently being phased out of CRIM’s research infrastructure, in favor of Python 3.6. The cloud environment is developed using OpenStack Juno, a free and open source cloud operating system that controls compute, storage, and networking resources in a data center. Docker 1.10 is used as an application package containing user’s process and pulled on demand from the Docker registry, but also as a way to bundle and deploy all other required components of the system. More details regarding each software package utilized can be found in Appendix C - Software Packages. The CRIM High Level Architecture is represented in Figure 5 below.

In this architecture view, the WPS 1.0 Client/Application Manager interacts with a WPS 1.0 Server. The server contains a job manager that splits jobs into tasks. A request containing parameters for processes, cloud, and application registry can be sent to the WPS server to manage the distribution of tasks across one to many task queues within multiple cloud environments. An elasticity manager monitors the tasks queues and automatically triggers the deployment of new VMs when predefined system load thresholds are met. The elasticity manager has been developed by CRIM and has been in operation for the last 3 years in a software research platform called VESTA (http://vesta.crim.ca/index_en.html). Additionally, the input and output parameters of the Docker application packages, as well as execution status, are passed via the task queue. The data results are stored on a shared fileserver and can be accessed either in their raw form or as WCS 1.0 or Web Map Service (WMS) 1.1.1 layers implemented using GeoServer. Once the results are computed, the WPS receives the output in the form of a reference URL to the WMS Server where the user can retrieve the image.

The introduction of Docker containers for packaging software opens up the possibility of using Docker Compose to define and run multi-container Docker applications. Compose works in all environments: production, staging, development, testing, as well as continuous integration workflows. With Compose, one can use a YAML file to configure your application’s services. Then, with a single command, create and start all the services from the configuration. Docker Compose does not provision VMs, but once the cloud hosts are provisioned, Docker Compose can be used to "script" the deployment of Docker images to the cloud environment. This is the preferred solution over use of Amazon CloudForms and OpenStack Heat due to the interoperability of deployments using software containers. The scalability based on Docker containers also depends on the method of monitoring, deploying, instantiating, and destroying docker containers.

The EO data accessed by the cloud environments first begin by fetching the data from the external data source and storing it in local shared storage. In general, the deployments of each VM follows the same hierarchy: VM → Operating System → Docker → Sentinel Application Platform (SNAP) → Graph Processing Tool (GPT).

In the GMU environment (see Figure 15), the data is stored in a local shared storage which is mounted to the VM where it can be accessed by multiple Docker containers. A process in the Docker container is responsible for managing the SNAP GPT processes and transferring the resulting data to a VM containing the WMS/WCS components running in MapServer 6.4.1.

In the CRIM environment (see Figure 16), the data is also fetched and stored in local shared storage, however this data store is shared across all VMs using a fileserver. The shared storage is mounted to each VM using Network File System (NFS) mount, and then accessed by the Docker container. Each VM is configured with only one Docker, which manages the SNAP GPT processes and transfers the result to an external GeoServer 2.10.04 using the Geoserver API.

Two Radarsat-2 data packages, rs2_nwt.tar and rs2_vernon.tar, were provided by the sponsor for use in the OGC Testbed 13. Both data packages contained the following:

rs2_nwt.tar contains:

Radarsat-2 Sample data is also publicly available at http://mdacorporation.com/geospatial/international/satellites/RADARSAT-2/sample-data. The Vancouver dataset offers the end-user the chance to evaluate RADARSAT-2 products from many of the modes available on RADARSAT-2 and for a variety of different applications that include urban mapping, marine surveillance, agricultural mapping, and infrastructure mapping. This geographic location offers varied terrain from the rugged mountains to the north of Vancouver, to the flat, agricultural lands of the Fraser River Delta.

The Vancouver data set includes:

NRCan Grid and NRCan DEM are available via FTP: http://ftp.geogratis.gc.ca/pub/nrcan_rncan/elevation/cdem_mnec/index/cdem_index_250k.kml http://ftp.geogratis.gc.ca/pub/nrcan_rncan/elevation/cdem_mnec/

CRIM collects metrics on task execution through an Open Source component named Flower, deployed as a Docker container. Flower collects and exposes the statistics and commands of a particular Message Broker. As shown in Figure 17, the Dashboard displays all workers that are subscribed to tasks queues hosted by the broker. Flower tracks every task received and keeps count of their states (active, processed, failed, succeeded, retried) acknowledged by the workers. It also presents the load average on the worker’s host, which is a standard Unix-like feature.

Also part of CRIM monitoring tools, Portainer enables real-time control and supervision of Docker containers on a host. Just like Flower, it is deployed as a Docker container and has privileged access to the Docker Daemon running on its host. Through its Dashboard, a user can inspect and modify the execution state (stop, pause, start, restart, etc.) of all containers and can connect to their standard outputs. CRIM uses Portainer mostly for the management of static system components (WMS and WPS servers, databases, security components, etc.). Portainer could also be used to debug and monitor execution of transient applications on elastic VMs.

GMU uses tools built into Apache CloudStack for monitoring and capturing cloud usage statistics. Figure 19 shows the metrics captured from the Apache CloudStack dashboard describing the resources, CPU usage, memory usage, network usage, and disk usage of each instance used by GeoBrain Cloud.

There are three sets of parameters that are input into the WPS:

The CRIM WPS client uses "by reference" parameters which maps Cloud resources and their ACL. Parameters are set by the worker into the Docker container environment variables. These parameters are in turn mapped to the defined executable entry point of the Docker container, in our case a script called ogc_processing.py. Below is a list of potential input parameters to describe the process.

Input:

Geocoding parameters:

Output:

A detailed description for CRIM polarimetric SAR processing of Radarsat-2 Images can be found in [AppendixF].

Parameters can be defined dynamically in the Graph’s xml file ($file, $target, etc.). For more information, see doc on GPT (http://corp.array.ca/nest-web/help/general/commandLineReference.html). An example use for batch processing can be found in the following excerpt. In that scenario, input parameters received at application-level (Docker) can be mapped directly to GPT by command-line. Additional examples of GPT Process files can be found in Appendix E - WPS Process Descriptions.

The GMU WPS wraps the GPTGraphProcess as the process for calling GPT within the graph XML file on earth observation data in WPS 2.0 standard interface. The input parameters of the GPTGraphProcess are InputData and GraphXML. The output parameter of the GPTGraphProcess is Result.

Input:

Output:

The following section describes the preferred methodology for the sponsor, Natural Resources Canada (NRCan), for a Single Sign-On solution using the Distributed Access Control System (DACS). It was primarily written with integration of applications into Canada’s National Forest Information System (NFIS) managed by Natural Resources Canada. Detailed implementations will not be discussed nor will other aspects of the Single Sign-On system (such as LDAP and the user interface).

The Single Sign-On system implemented on the NFIS relies on a key piece of software called the DACS, an open source software located at https://dacs.dss.ca. DACS is a module created for the Apache web server. It can be turned “on” for specific hosts and URLs in the web server. Once DACS is turned “on”, it will deny everyone from that host or URL until configured otherwise. DACS has been tested on several OGC testbeds and is used to control access to OGC Web services on NFIS. In order for an application to make use of DACS as part of a Single Sign-On solution, the application must be protected behind one of the URLs or Hosts for which DACS is turned “on”. Having done this, there are four options for further implementation of the application, as described in this document.

CRIM reviewed the Distributed Access Control System (DACS) documentation provided by the sponsor, but did not attempt to install or test it. The approach proposed by CRIM, depicted in Figure 29 are in part overlapping with those presented previously, but substantial differences subsists. Just like DACS, an encrypted cookie is passed to the client’s browser once authenticated. CRIM’s HTTPS security proxy plays a similar filtering role as the Apache server in DACS, effectively rejecting requests that do not match criteria. The proxy currently does not reject requests based on a user’s IP, only on the validity of the cookie and authorization checks against the ACL. In CRIM’s solution, all access to data and services are made against the secured proxy. In no case can a user access the servers directly. As the AuthZ/AuthN Service can be accessed by administrator either through a UI or REST calls, no edition to configuration files or restarting of servers is required.

Pyramid Web Framework was selected for implementation in the CRIM cloud environment. This module constitutes a Policy Enforcement Point (PEP). A user session starts by obtaining this authentication token. Therefore, the user must first log in, either locally by providing a username/password saved in a local database or via an external provider such as OpenID or GitHub. When a user sends a request to access any type of resource, it needs to include an authentication token that will be decrypted by Pyramid to authenticate the user and the groups he belongs to. Once authenticated, Pyramid will authorize this user to access the resource by checking in a database the permissions this user has on that resource. If the login is successful, Pyramid provides an authentication token which is valid for a limited period. CRIM combined two dedicated libraries, Ziggurat-Foundations and Authomatic, to build a complete RESTful web service for AuthN/AuthZ to manage users, groups, resources, permissions and login along with the Pyramid framework.

CRIM considers that Test 3 constitutes valid deployability test. A worker listening to a queue receives a request containing: a docker image name and version number; the URL of a docker registry; a dictionary. The content of the dictionary is saved to a text file "env" with the syntax OGC_INPUT_key = value. The worker generates a docker-compose.yml file based on a template, where placeholders for docker image name and version are replaced by values from the request object. The worker launches the script docker-compose while passing "env" as an environment file and mounting volumes as needed. The selected docker image is started and has access to environment variables as defined in the "env" file. Once processing is done and the launched container is stopped, the output result from docker-compose is retrieved, as well as data stored in the mounted volumes.

The request is emitted as follows:

The execution trace is shown below:

CRIM considers that Tests 3 and 4 constitutes valid reproducibility tests because of their support of Docker images, Docker-compose and cloud-init configuration files.

GMU provides an easy-to-use solution to deploy Cloud WPS. Cloud WPS is disseminated through VM template in qcow2 format which is a general VM format compatible with different cloud platforms including OpenStack, CloudStack, and AWS. Moreover, GMU offers the extendable solution that allow user extending the computing capability of Cloud WPS. When user deploy multiple VMs reproduced by the given template, the computing capability of Cloud WPS will be extended.

The template example could be accessed at: http://cloud.csiss.gmu.edu/testbed/13/template/testbed13-wps-template.qcow2. After downloading the template file, user can upload the template to the private or public cloud platforms. Each time the template has been deployed, a new VM would be created. At least one VM in the cloud is supposed to be set as the gateway when the dashboard portal opens to users. This step could be set in the Apache config file located in the cloud management server. The example code to expose the GMU WPS dashboard portal in apache2.conf is shown as below:

CRIM considers that Test 2 constitutes a valid hybrid cloud interoperability test through the use of a shared task queue. Test 1 is considered a valid WPS interoperability test.

In this Test, we send a WPS request to a PyWPS server, which will transform that request in a task that will be a put in a Celery queue. Then, an available Celery worker will fetch the task from the queue and execute it. For example, a simple "sleep" request keeps the worker busy for 10 sec. If we send the request again immediately, another worker will fetch that new task and execute it. This experiment demonstrates that different tasks can be done in parallel thanks to a multiple workers listening to the same queue. Below is an example of request: 

System scalability is conducted through Test 4. Initial approach for Test 4 involves the launch of a pre-configured VM snapshot on OpenStack. In order to better support configurability and other clouds support, we elected to instead use an initiation file. Using the OpenStack command line client (CLI), we launch an OpenStack instance using a cloud-init file including the required steps to: install the required packages (python-celery, docker, etc.); setup required environment variables for the worker; download the code of worker; start the worker. The instance ID returned by OpenStack is tracked. When the worker is not required anymore, we delete it using the OpenStack CLI. In this example, we have a rabbitMQ server available at 192.168.201.96. We then launch one or multiple instances that will run a simple Hello World worker.

Below is a cloud-init configuration file that we save as user_data.worker:

We then launch a new instance using the user-data.worker file. The following example is meant to be ran at CRIM’s internal R&D tenant:

The elapsed time before the worker is ready and accepting jobs is 75 seconds. The OpenStack CLI will return a result similar to this:

In order to remove the newly create VM (to scale down), we need take note of the id of the VM and we emit the following command on OpenStack’s CLI:

Figure 36 depicts the hybrid cloud demonstration between BorealCloud and CRIM. BorealCloud is NRCan’s high performance cloud infrastructure based on OpenStack technology at the Pacific Forestry Centre in Victoria, BC. Individual hosts VMs are identified by dashed boxes, while services/servers are plain boxes and assumes different ports. Inter-cloud access are depicted by arrows. In this scenario, three separate clouds are used. A master cloud is deployed on CRIM RD_ext tenant where all resources can be made available to the outside world. It contains the Docker Registry, a HTTPS fileserver, OWS services and Job Management components. All credentials to CRIM’s resources are set once at configuration-time on slave clouds.

Slave clouds are both on internal tenants; access to their resources from external hosts either difficult or impossible. Therefore, all accesses from slave clouds are outbound towards the master cloud. In this setup, Boreal’s elasticity manager monitors the state of a Task Queue on CRIM’s master cloud. It then creates (and tears down) processing VMs as required. Those processing VMs fetch a task, fetch the Docker App package, process the task and put the results on the fileserver and WMS server. CRIM’s elasticity manager on the slave cloud will do the same, so both clouds will work together.

Lack of interoperability and portability of cloud computing architectures causes difficulty (migration, storage transference, quantifying metrics, billing and invoices, etc.). The sponsor would like to take advantage of elastic computing while accessing the vast amounts of earth observation data stored in various locations. The goal was to develop a way for scientists to acquire, process, and consume earth observation data without needing to administer computing cloud resources. The prescribed solution in this ER is to use the OGC WPS to simplify use of Cloud Computing through a single service interface. The following table shows the results summary for the problems and solutions from Testbed 13.

The goals of the implementation of the solution were as follows:

Two component implementations were developed by Computer Research Institute of Montreal and George Mason University Center for Spatial Information Science and Systems. Each developed a WPS and cloud environment to deploy, operate, process, monitor, and provide a result based on EO data via OGC Web Service interfaces.

One of the major lessons learned was the use of Docker for interoperability across cloud environments. Docker provides an agnostic way to deploy software applications into Containers. Application Packages can be described in a WPS Process using WPS 2.0 which can handle both synchronous & asynchronous processes for job control, process execution and job monitoring. Clouds can be utilized with VMs while separating processes within Docker containers. Scalability based on Docker containers depends on the method of monitoring, deploying, instantiating, and destroying Docker containers.

The EOC thread consists of separate sub-threads including the NRCan Cloud and ESA Cloud. The following figure shows a high level comparison between ESA and NRCan architectures. It can be seen that both are identical to a large extent. The NRCan architecture identifies the App Management WPS as the key component an application consumer would work with. This component can be compared with the App Management Client in the ESA architecture. ESA has a dedicated App deployment and Execution Service, which is shown below as a logical component in the NRCan part.

In the EOC thread, OpenSearch was used to identify data collections which have associated hosted processing services. ESA is participating in a parallel activity to define how this link between collections and services has to be encoded in GeoJSON and it has been decided to use the OWS-Context offerings field. If for a WMS it is clear what kind of information to put in offerings, that is the layers representing the data, it is not so straightforward for a WPS. In fact, there are different possibilities. One is to put the getCapabilities end point, which may be sufficient for the use case presented in the testbed, but it could also be necessary to have a sort of filter to identify all the operations in the WPS which take as input the products in the collection. An input from the testbed on this topic was requested in order to finalize the specification and the implementation of a GeoJSON-based interface.

The recommended future work on this topic includes the following:

(RS2_OK79000_PK698380_DK627316_FQ9W_20160907_013548_HH_VV_HV_VH_SLC)

(RS2_OK79000_PK698380_DK627316_FQ9W_20160907_013546_HH_VV_HV_VH_SLC)

(RS2_OK77397_PK685920_DK616065_SQ13W_20160711_013038_HH_VV_HV_VH_SLC)

(RS2_OK77397_PK685921_DK616066_SQ13W_20160711_013042_HH_VV_HV_VH_SLC)

T=[T_ii] (as described above)

S0= (T_11 + T_22 + T_33)/2 - Im(T_23) = Span / 2 - Im(T_23)

S1 Re(T_12) - Im(T_13)=

S2 Re(T_13) + Im(T_12)=

S4= Im(T_23) - (T_22 + T_33 - T_11) / 2

band1: S_hh Re(S_hh) + jIm(S_hh)=

band2: S_hv

band3: S_vh (same as S_hv)

band4: S_vv

For example:

S0= (|S_hh|^2+2|S_hv|2+|S_vv|^2)/2 - Im(ShhShv ^-SvvS_hv) = (i_hh^2 + q_hh^2 +2*(i_hv^2 + q_hv^2) + i_vv^2 + q_vv^2)/2 - ((q_hh-q_vv)*i_hv-(i_hh-i_vv)*q_hv)

S1 = Re(T_12) - Im(T_13) = (i_hh^2 + q_hh^2 - (i_vv^2 + q_vv^2))/2 - ((q_hh+q_vv)*i_hv-(i_hh+i_vv)*q_hv)

S2 = Re(T_13) + Im(T_12) = ((i_hh+i_vv)*i_hv+(q_hh+q_vv)*q_hv) - (q_hh*i_vv-i_hh*q_vv)

S4 = Im(T_23) - (T_22 + T_33 - T_11) / 2 = q_hh-q_vv)*i_hv-(i_hh-i_vv)*q_hv) - (i_hv^2 + q_hv^2 - (i_hh*i_vv + q_hh*qvv

% Convert a CP Stockes format to its Raney decomposition

% data [S0 S1 S2 S3 S4]=

% Ref: (Chen,2009) Unsupervised classification for Compact Pol

raney=zeros(size(data,1),size(data,2),2);

raney(:,:,1)=sqrt(data(:,:,2).^{2+data(:,:,3).}2+data(:,:,4).^2)./data(:,:,1); %-- m

%raney(:,:,2)=atan(data(:,:,4)./data(:,:,3));

raney(:,:,2)=atan2(data(:,:,4),data(:,:,3)); %-- delta

raney(:,:,3) 0.5*asin(data(:,:,4)./data(:,:,1)); %-- Chi=

Conda (4.3) - Conda is a cross-platform, language-agnostic binary package manager. It is the package manager used by Anaconda installations, but it may be used for other systems as well. Conda makes environments first-class citizens, making it easy to create independent environments even for C libraries. Conda is written entirely in Python, and is BSD licensed open source.

Docker Engine (1.10) - Software container platform used to run and manage applications in parallel to achieve greater compute density. Containers package software in a format that can run isolated on a shared operating system. Unlike VMs, containers do not bundle a full operating system, and only libraries and settings required to make the software run are needed. This makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it’s deployed.

Docker Registry - A stateless, highly scalable server-side application that stores and allows the distribution of Docker images. The Docker Registry is open-source, under the permissive Apache license.

Docker Hub - A web-based repository of software packages for use with docker. Docker Registry is contained in this repository.

PyWPS (4.0.0) - PyWPS is an implementation of the Web Processing Service standard from the Open Geospatial Consortium written in Python. PyWPS enables integration, publishing and execution of Python processes via the WPS standard. PyWPS is Open Source and released under an MIT license.

gunicorn (19.1.0) - 'Green Unicorn' is a Python WSGI HTTP Server for UNIX. It’s a pre-fork worker model. The Gunicorn server is broadly compatible with various web frameworks, simply implemented, light on server resources, and fairly speedy.

Python (2.7) - Python is developed under an OSI-approved open source license, making it freely usable and distributable, even for commercial use. Python’s license is administered by the Python Software Foundation.

Nginx (1.10.1) - NGINX is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. NGINX is known for its high performance, stability, rich feature set, simple configuration, and low resource consumption.

Supervisor (3.3.1) - Supervisor is a client/server system that allows its users to monitor and control a number of processes on UNIX-like operating systems.

SNAP 5.0 In EOC thread, it is imperative to use the Array Systems Computing RadarSat-2 Toolbox (RSTB) to process Radarsat-2 or other SAR and optical images. The RSTB is integrated in Sentinel Application Platform (SNAP) which could be executed by Graph Processing Framework (GPF) that allowing the user to create processing graphs for batch processing and customized processing chains. GMUWPS wraps some of operators (e.g. GPTWrite) and provides the capability to receive the GPT configuration XML file as the input of WPS request.

Docker CE 17.07 Docker provides the capability of manage containers in VMs. In the cloud infrastructure, Docker adds an additional layer between system level and application level, which makes applications deployed in the container isolate with each other. In addition, Docker images are lightweight. That is, compared to the VM template, the size of a Docker image is much smaller.

JDK 1.7.21 The Java Development Kit (JDK) is an implementation of either one of the Java Platform, Standard Edition, Java Platform, Enterprise Edition, or Java Platform, Micro Edition platforms[1] released by Oracle Corporation in the form of a binary product aimed at Java developers on Solaris, Linux, macOS or Windows.

Tomcat 6 The Apache Tomcat® software is an open source implementation of the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies. The Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket specifications are developed under the Java Community Process.

Client - GMU WPS Dashboard To support OGC Testbed 13 Earth Observation Cloud (EOC) thread, a web-based GMU WPS Dashboard tool was developed. The demonstration version of GMUWPS Dashboard could be accessed at: http://cloud.csiss.gmu.edu/GMUWPS/. The tool provides an interface to send a request and get a response from WPS operations including GetCapabilities, DescribeProcess, Execute, GetStatus, and GetResult. Optimized for the EOC thread, the tool displays cloud information such as Job Splitting, Job Priority, Cloud VM Usage, and Docker Usage.

GetCapabilities Request Example:

GetCapabilities Response Example: