Frequently Asked Questions
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.
WPS is endorsed by the Canadian Geospatial Data Infrastructure (CGDI), which in its tutorial gives some practical, day-to-day reasons for using CGDI-endorsed standards and specifications for geospatial data and services:
- Reduce development costs;
- Hide the complexity of components; and
- Permit GIS practitioners and developers to benefit from "plug and play" components.
Widening the focus, the CGDI also gives the following reasons for supporting standards and specifications:
- Wide-scale interoperability of web services;
- Increased availability, access and sharing of geospatial information;
- Efficient use of digital geospatial information and associated hardware and software systems;
- Seamless chaining of applications, data and services;
- Promotion of existing and evolving Canadian technology and expertise;
- Ensuring compliance of Canadian data products;
- Development of effective partnerships with other spatial data infrastructures; and
- Solutions for global delivery of geospatial information.
Can I use WPS to wrap [insert name of favorite algorithm here] ?
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.
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.
- It supports the OGC GetCapabilities construct, which simplifies its adoption within the geospatial community that has already adopted OGC specs.
- 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.
- It specifies how to determine the status of a process, which enables the support long-running processes.
- It specifies exactly how to package and describe the inputs and outputs, which facilitates the development of reusable software frameworks and clients.
- It specifies how to request storage of process outputs, which facilitates service chaining and subsequent retrieval.
- It specifies how to reference web resources as inputs/outputs, which facilitates service chaining.
- 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.
- 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.
- It facilitates service chaining, since a WPS service can be constructed to call other services, including other WPS services.
- It defines standard error messages, which simplifies the coding of error response handling for multiple processes.
- 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.
Hey, WPS via HTTP GET can be used to change state on the server. Isn't that illegal?
You're absolutely right. WPS Execute requests via HTTP GET can change the state of the WPS server. This violates the rules of the web.
Well... actually... about those rules... they're more like guidelines than actual rules. By convention, GET requests are generally restricted to safe operations. But there's no technical reason why GET requests have to be safe. It's just a convention designed to make security a little easier. Anyone building a WPS is going to have to be pretty technically savvy. Savvy enough to be able to treat a WPS GET request with appropriate care.
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.
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?
Beyond the resources available on this site, you may want to check out the WPS page on the OGC Network.