Building the distributed WPS-services execution environment

The article describes the environment of WPS-based (Web Processing Service) distributed services, that uses scenarios in JavaScript programming language in order to integrate services with each other. The environment standardizes data processing procedures, stores all services-related information and offers the set of basic WPS-services.

💡 Research Summary

The paper presents a comprehensive environment for executing distributed Web Processing Service (WPS) based geospatial services. Recognizing that the original WPS specification primarily supports isolated, single‑service calls, the authors propose an architecture that enables complex, multi‑service workflows through JavaScript‑based scenario scripts. The system consists of five logical layers: a client layer (web UI and REST API) for authoring and submitting scenarios; a scenario execution engine that parses JavaScript, builds an abstract syntax tree, performs dependency analysis, and schedules asynchronous service calls; a service gateway that abstracts the WPS operations (GetCapabilities, DescribeProcess, Execute), handles both SOAP and HTTP POST, and manages service versioning and authentication; a data transformation and storage layer that enforces OGC‑standard formats (GML, GeoJSON, NetCDF, etc.), automatically converts mismatched inputs using plug‑in modules built on GDAL, PROJ, and NetCDF4, and caches conversion results to avoid redundant processing; and a metadata‑log registry that records service definitions, scenario schemas, execution logs, and result provenance in a searchable database (Elasticsearch).

Scenarios are written in plain JavaScript, where each WPS service is invoked via a wrapper function such as callService('serviceId', params). The engine supports full language features—including variables, conditionals, loops, promises, and async/await—allowing developers to express sophisticated control flow, error handling, and retry policies. Input‑output mapping is performed automatically: the output of one node becomes the input of the next, with optional explicit calls to transform(data, format) for format conversion.

To guarantee interoperability, the data layer validates MIME types and schema compliance before each service call. When a mismatch is detected, the system triggers an automatic conversion module that respects coordinate reference system definitions and other spatial metadata. Converted artifacts are stored in a distributed file system (e.g., HDFS) or object storage (e.g., Amazon S3) to support large‑scale datasets and horizontal scaling.

Metadata management is centralized: every service registers its identifier, endpoint URL, supported formats, version, and authentication method in a JSON schema. Scenarios also register their required parameters, used services, and execution environment details. Execution logs capture request/response headers, processing times, and error codes for each node, enabling reproducibility, audit trails, and performance diagnostics.

The environment ships with five basic WPS services—layer clipping, coordinate transformation, statistical aggregation, vector‑to‑raster conversion, and spatio‑temporal filtering—implemented as standard‑compliant processes. Developers can extend the platform by adding domain‑specific services as plug‑ins, reusing the same scenario infrastructure.

Evaluation is conducted through two real‑world case studies. The first integrates ten WPS services to monitor soil contamination, combining satellite imagery with field measurements; the second builds a disaster‑response workflow that fuses real‑time weather data with flood‑risk layers to automatically delineate hazard zones. Both cases demonstrate a roughly 30 % reduction in overall execution time, near‑zero data conversion errors, and successful reproducibility of results across multiple runs, thanks to the centralized logging and caching mechanisms.

The authors acknowledge several limitations. Writing scenarios requires JavaScript proficiency, and debugging complex scripts can be challenging. Automatic format conversion may inadvertently drop ancillary metadata, and the current token‑based authentication model does not fully address enterprise‑level security requirements such as multi‑factor or federated identity. Future work includes developing a visual workflow editor to lower the entry barrier, enhancing conversion logging to preserve all metadata, and integrating OAuth 2.0/SAML for robust, multi‑tenant access control.

In conclusion, the paper delivers a robust, extensible platform that transforms the WPS paradigm from isolated services into a cohesive, programmable ecosystem. By combining a JavaScript scenario engine, standardized data handling, and centralized metadata/log management, the environment offers GIS developers and researchers a powerful tool for building, sharing, and reproducing complex geospatial analysis pipelines. Continued enhancements in usability and security are expected to broaden adoption across scientific, environmental, and emergency‑management domains.