WPS FAQ

Why would I use WPS? I can program this type of thing myself.

The main reason for using a standard or specification such as WPS is interoperability, which facilitates the creation, finding, and binding of web services. By adopting a common standard, geographic information processing becomes easy to access through the Internet.

Can I use WPS to wrap [insert name of favorite algorithm here] ?

Yes.

The slightly longer answer is: Yes, because WPS is designed to be generic, and has no restrictions on the number and type of inputs and outputs.

Of course, just because you can doesn't mean you should. Is someone going to want to search for your service in a registry? Are other people going to want to build clients? Do you need to interoperate with other service providers? Are you going to build other services? Is your process going to run for a long time? If you answered yes to any one of these questions, then WPS might be appropriate.

Benefits 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.

Why shouldn't I just use SOAP and WSDL?

WPS is compatible with both WSDL and SOAP, and definitions for how to use WPS with these standards have been defined in the WPS specification.

SOAP can be used to package WPS requests and responses. SOAP describes a message exchange mechanism which contains an env:body element, but it does not describe the contents of that body, i.e. the payload. WPS describes a message exchange mechanism that can be used if SOAP is not required (for security such as encryption or authentication), but it goes beyond SOAP by specifying what the payload should look like. Elements that are common to all payloads have been generalized in the WPS specification, and this standardization dramatically simplifies the amount of custom coding required to implement an interface for any new service. WPS enables the development of both software frameworks and generic clients. The use of SOAP to wrap WPS requests offers the ability to add security certificates as well as encryption to web-based geoprocessing transactions.

WPS supports WSDL. WSDL identifies how a service should be described, but not what the service interface should look like. WPS describes a significant portion - the common portion - of what any service should look like. WSDL offers a less comprehensive but more widely adopted alternative to the publishing mechanism built in to the WPS interface specification. (WPS offers more documentation than can be published via WSDL, and more sophisticated service chaining capabilities.)

WPS supports the use of WSDL for an individual WPS process, as well as for the entire WPS instance that may include several processes. It is not possible to generate a single generic WSDL document that describes all WPS implementations, since WSDL requires specific binding information that is only found in WPS profiles. It is possible to use WPS without WSDL if dynamic binding to well known service instances (e.g. WPS profiles) is required. WSDL is required in order to facilitate dynamic binding to dynamic services (i.e. WPS instances with unknown profiles).

WPS offers the following advantages to an approach restricted to the current SOAP/WSDL specifications.

1. It supports the OGC GetCapabilities construct, which simplifies its adoption within the geospatial community that has already adopted OGC specs.
2. For a single output, it supports the direct return of that output without any XML wrapper, which allows for REST-like architecture while still enabling publish and find.
3. It specifies how to determine the status of a process, which enables the support long-running processes.
4. It specifies exactly how to package and describe the inputs and outputs, which facilitates the development of reusable software frameworks and clients.
5. It specifies how to request storage of process outputs, which facilitates service chaining and subsequent retrieval.
6. It specifies how to reference web resources as inputs/outputs, which facilitates service chaining.
7. It specifies how to describe and embed complex inputs, which facilitates the development of reusable components to store and extract these inputs from a processing request.
8. It offers a superior service discovery mechanism that can be used without the overhead and complexity of WSDL, while at the same time supporting the option to use WSDL when required to facilitate discovery and binding.
9. It facilitates service chaining, since a WPS service can be constructed to call other services, including other WPS services.
10. It defines standard error messages, which simplifies the coding of error response handling for multiple processes.
11. It enables the client to choose whether to use a REST, POX, or SOAP architectural approach, since it specifies how to support all three architectures from one service implementation.

Do I have to share my WPS services with everyone?

Implementing WPS can be done without sharing services on the Internet - you can select which services you wish to publish. Perhaps the best way to restrict access to your WPS services is to implement them on a dedicated, isolated network, to which access is limited. For example, Agriculture Canada uses WPS to process some sensitive agricultural census data accessible only on its internal network. WPS is used on this network for modelling, and only the aggregated data or results of the modelling are made available to the outside through the external network.

Alternatively, you can implement WPS behind some form of access control mechanism.

How can I provide access to cached outputs?

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 subsequent clients can access cached outputs. 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.

Who uses WPS?

Given the nature of the Internet, it is difficult to tell exactly who uses WPS. A Google search will turn up plenty of references to WPS, and several software implementations, but almost no live service implementations. This is likely due to the fact that most organizations capable of implementing WPS have limited interest in sharing their computing power with the general public. Most WPS implementations appear to be buried inside corporate intranets or housed behind access control layers.

Where can I find out more about WPS?

How can I identify 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.

Who created WPS?