What is WPS?
The Web Processing Service (WPS) offers a simple web-based method of finding, accessing, and using all kinds of calculations and models.
WPS is an OGC standard that defines how to implement geographic calculations or models (i.e. "processes") as a web service. WPS defines a standardized interface that facilitates the publishing of geospatial processes, and the discovery of and binding to those processes by clients.
Processes can include any algorithm, calculation or model that operates on spatially referenced data.
Publishing means making available machine-readable binding information as well as human-readable metadata that allows service discovery and use.
The WPS interface standardizes the way processes and their inputs/outputs are described, how a client can request the execution of a process, and how the output from a process is handled. WPS uses standard HTTP and XML (eXtensible Markup Language) as a mechanism for describing processes and the data to be exchanged.
What kind of calculations can a WPS do?
WPS does not specify the kind of processes that could be implemented as a web service. Instead, it specifies a generic mechanism that can be used to describe and web-enable any sort of geospatial process.
A WPS can be configured to offer any sort of GIS functionality to clients across a network, including access to pre-programmed calculations and/or computation models that operate on spatially referenced data. The calculation can be extremely simple or highly complex, with any number of data inputs and outputs.
A WPS may offer calculations as simple as subtracting one set of spatially referenced numbers from another (e.g., determining the difference in influenza cases between two different seasons), or as complicated as a global climate change model.
How does WPS work?
Each implementation of WPS defines the processes that it supports, as well as their associated inputs and outputs. WPS can be thought of as an abstract model of a web service, for which profiles need to be developed to support use, and standardized to support interoperability. As with the other OGC specifications GML and CAT, it is the development, publication, and adoption of profiles which define the specific uses of this specification.
WPS discovery and binding mechanisms follow the OGC model set by WMS and WFS, in that WPS defines a GetCapabilities operation, and requests are based on HTTP Get and Post. WPS does more than just describe the service interface, in that it specifies a request/response interface that defines how to:
- encode requests for process execution
- encode responses from process execution
- embed data and metadata in process execution inputs/outputs
- reference web-accessible data inputs/outputs
- support long-running processes
- return process status information
- return processing errors
- request storage of process outputs
- create a service chain.
What kind of data can WPS use?
WPS is targeted at processes that involve geospatial data (vector and/or raster), but can also be applied to non-spatial processes.
The data required by the WPS can be delivered across a network, or available at the server.
WPS does not define or restrict the type of data required or output by a process. Instead, it identifies a generic mechanism to describe the data inputs required and produced. Thus data can include image data formats such as GeoTIFF, or data exchange standards such as GML. Data inputs can also be legitimate calls to OGC web services. For example, a data input for an intersection operation could be a polygon delivered in response to a WFS request, in which case the WPS data input would be the WFS query string.
WPS defines three types of data.
- Complex Data includes such things as imagery, XML, CSV, and custom or proprietary data structures.
- Literal Data includes single numerical values or text strings.
- Bounding Box Data includes geographic coordinates for a rectangular area.
Advantages of WPS
The main advantage of WPS is interoperability of network-enabled data processing. It allows organizations to deliver calculations to users independent of the underlying software. This independence helps to ensure the longevity of code.
WPS has many other advantages:
- Supports multiple web service approaches. It defines equivalent KVP Get, XML Post, and SOAP interfaces, allowing the user to choose the most appropriate interface.
- Exploits the power of distributed computing. WPS is designed to enable distributed processing of geospatial data located anywhere on the Internet.
- Fast, reliable access to "near real-time" calculations. Because WPS makes calculations available as web services, the most up-to-date data can be accessed directly from the source organization responsible for its maintenance.
- Reusability. Exposing processes through WPS allows organizations to reuse the same process (and code!) in multiple applications.
- Flexibility. Exposing processes through WPS allows organizations to change their underlying software without impacting users and client applications.
- Scalability. WPS is scalable, both in terms of the potential for unlimited parallel interfaces, and through the exposure of gridded, cloud, or super-computers through a simple middleware interface.
- Security. Access to WPS processes can be restricted using a variety of standard web service security mechanisms such as firewalls and HTTPS.
Types of WPS applications
WPS allows several different approaches for executing a process:
Returning raw outputs
The simplest approach is only applicable when the WPS produces only one output. In this case, the output can be returned directly to the users in its raw form. For example, a request to buffer a feature could return an image of the buffered feature encoded in a png file.
Returning outputs embedded in XML.
One response to an Execute request is an XML document that includes metadata about the request, as well as the outputs from the process encoded and wrapped in the XML response. This form of response is recommended when the output size is less than a few megabytes in size, and the user requires metadata found in the wrapper.
A WPS may allow a user to request storage of the outputs. In this case, the XML document returned to the client will again contain metadata, but instead of the outputs themselves, it will contain references to web-accessible locations from which the outputs can be downloaded.
Finally, if an Execute request triggers a long-running process, the WPS will return a response containing references to the outputs as indicated aboved. Also included will be a reference to a location where the Execute response document is stored. The WPS will periodically update the status indicator found in this document until processing is complete.
Providing access to data produced by a WPS
The outputs from a WPS are available to the client that initiated the Execute operation. The specification does not address the archival, cataloguing, discovery, or retrieval of WPS outputs, so that other clients can access them.
There are several ways in which such access could be provided:
- Email. Email the Execute response or the specific WPS output locations.
- Create a server index. Have the WPS create an index of status documents created by the service.
- Create a client index. Have the WPS client create an index of status documents created by the service.
- Register the outputs. Have the WPS server or client add the outputs to a Registry.
For a simple registry of XML documents, check out the OpenRegistry specification.
Identifying identical processes
The WPS specification includes the concept of an Application Profile. Processes that are advertised as compliant with the same Application Profile are intended to provide identical functionality.
An Application Profile is essentially the same as the ProcessDescription document that is returned in response to a DescribeProcess request.
Service Chaining with WPS
A WPS process is normally an atomic function that performs a specific geospatial calculation. Chaining of WPS processes facilitates the creation of repeatable workflows. WPS processes can be incorporated into service chains in a number of ways:
- A BPEL engine can be used to orchestrate a service chain that includes one or more WPS processes.
- A WPS process can be designed to call a sequence of web services including other WPS processes, thus acting as the service chaining engine.
- Simple service chains can be encoded as part of the execute query. Such cascading service chains can be executed even via the GET interface.
WPS has been under development since 2004. It was the subject of an OGC interoperability experiment that finished in 2006. In 2007 it was released to the public as version 1.0. Since that time, WPS-Simple 1.0 has been defined, and the specification of WPS 2.0 has started.
WPS 2.0 is likely to include an equivalent to WPS-Simple, and the ability to Pause, Resume, or Abort a long-running operation.