Processing on-demand WPS Extension (WPS-G) Specification

Transcription

1 Open Geospatial Consortium Inc. Date: Reference number of this document: Version: (Draft) Category: OGC Discussion Paper Editors: Patrick Jacques, Christophe Noël Processing on-demand WPS Extension (WPS-G) Specification Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. To obtain additional rights of use, visit Warning This document is not an OGC Standard. This is an OGC Discussion Paper and is therefore not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, an OGC Discussion Paper should not be referenced as required or mandatory technology in procurements. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

2 Contents 1 Introduction References WPS-G Operations Operation Specification Modified Operations GetCapabilities Operation Execute Operation DeployProcess Operation UndeployProcess Operation GetStatus Operation Cancel Operation Operation Specification New Operations DeployData Operation Request Response Exceptions UndeployData Operation Request Response Exceptions DescribeData Operation Request Response Exceptions GetAudit Operation Request Response Exceptions Callback Mechanism Appendix A XML Schema Documents Appendix B - Deployment Profile Examples Apache ODE JavaSAGA Appendix C Request and Response Examples GetCapabilities Operation Request Response Execute Operation Request Response DeployProcess Operation Request...45 ii Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

3 9.3.2 Response UneployProcess Operation Request Response GetStatus Operation Request Response Cancel Operation Request Response DeployData Operation Request Response UneployData Operation Request Response DescribeData Operation Request Response GetAudit Operation Request Response Appendix D WSDL Example Bibliography...60 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. iii

4 Figures Figure 1: Multi-Mission Processing Hierarchy Figure 2: WPS-G Operations... 5 Figure 3: GetCapabilities Response... 8 Figure 4: Execute Response... 9 Figure 5: DeployProcess Response Figure 6: UndeployProcess Request Figure 7: UndeployProcess Response Figure 8: GetStatus Request Figure 9: GetStatus Response Figure 10: Cancel Request Figure 11: Cancel Response Figure 12: DeployData Request Figure 13: DeployData Response Figure 14: UndeployData Request Figure 15: UndeployData Response Figure 16: DescribeData Request Figure 17: DescribeData Response Figure 18: GetAudit Request Figure 19: GetAudit Response Figure 20: Short Form Audit Trace Figure 21: Asynchronous Service Figure 22: Apache ODE Deployment Profile Figure 23: JavaSAGA Deployment Profile Tables Table 1: DeployData Exception codes Table 2: UndeployData Exception codes Table 3: DescribeData Exception codes Table 4: GetAudit Exception codes iv Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

5 i. Preface The OGC Web Processing Service specification provides a means to perform distributed Web-based processing on geospatial data. However, the specification does not provide the ability to dynamically deploy and undeploy processes and (auxiliary) data, to steer the execution of processes, and to monitor/audit the executing processes. These features are necessary to support the HMA on-demand processing scenario described later in section 1. Some of the required features have already been proposed as change requests to the WPS 1.0 specification (see [3] and [4]). Whenever possible, these changes are adopted and used as building blocks for this Processing on-demand WPS extension. ii. Document terms and definitions This document uses the standard terms defined in Subclause 5.3 of [2], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word shall (not must ) is the verb form used to indicate a requirement to be strictly followed to conform to this standard. iii. Submitting organizations The following organizations intend to submit this document to the Open Geospatial Consortium Inc. Spacebel European Space Agency (ESA) Flemish Institute for Technological Research (VITO) Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. v

6 iv. Document contributor contact points All questions regarding this document should be directed to the editors or the contributors: Patrick Jacques Name Christophe Noël Spacebel Spacebel Organization v. Revision history Date Release Editor Primary clauses modified P. Jacques, C. Noël Initial Draft Description vi Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

7 OGC Discussion Paper Processing on-demand WPS Extension (WPS-G) Specification 1 Introduction This Processing on-demand WPS extension is the result of an ESA financed project named Grid Enabled Service Support Environment (SSEGrid). One of the main objectives of this project is to contribute to the Heterogeneous Missions Accessibility (HMA) initiative by proposing a standard to address on-demand processing of Earth Observation (EO) data. On-demand processing of EO data is made possible by providing (Grid) processing power close to where the EO data is located. This is to avoid copying huge volumes of EO data to the user s facility and eliminates the need for the user (e.g. scientist) to deploy his own processing infrastructure. The user (also called Principal Investigator or simply PI) should also be able to combine the processing of EO data from multiple missions (multiple remote sensors) located in geographically dispersed data/processing centres (e.g. VITO and ESRIN). Therefore, the processing of EO data is structured according to the following processing hierarchy: (Grid) processes that access local EO data and user supplied auxiliary data 1 Mission workflows that combine the above (Grid) processes Multi-mission workflows that combine the above mission workflows The first two levels of processing can be provided by different users (PIs) as well as by the mission data/processing centre. Therefore, mission workflows designed by a PI can actually combine the following processing forms: (Grid) processes provided by this PI Mission workflows provided by this PI (Grid) processes provided by the data/processing centre Mission workflows provided by the data/processing centre (Grid) processes provided by other PIs Mission workflows provided by other PIs 1 EO data is the data to be processed. However, this processing often requires (non-eo) auxiliary data that must typically be updated on a regular basis. Examples of auxiliary data are climatology data, land cover maps, and atmospheric data. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 1

8 In order to meet the on-demand processing objective presented above, the processing infrastructure should allow the PI to perform the following tasks (e.g. through a Portal): Design workflows (mission and multi-mission) Upload auxiliary data Deploy (Grid) processes Deploy workflows (mission and multi-mission) Execute workflows (mission and multi-mission) Monitor and steer workflows (mission and multi-mission) Download results Discover auxiliary data Discover (Grid) processes Discover workflows (mission and multi-mission) Design workflows (mission and multi-mission) To support the above functionality in an interoperable way, an extension to the WPS standard is required. The extension described in this document takes advantage of the following WPS Change Requests that are to be considered by the WPS 2.0 SWG: OGC Change Request , The transactional WPS extension (WPS-T) [3], and OGC Change Request related to asynchronous processes [4]. 2 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

9 The basic idea is to encapsulate all forms of processing (i.e. workflow engines, Grid environments, etc) with a WPS service extended for on-demand processing 2 as shown in the figure below. User Processing Infrastructure (UPI) Federating Processing Infrastructure (FPI) Mission Processing Infrastructure (MPI) Grid Access Infrastructure (GAI) Grid WPS-G WPS-G Grid Workflow Engine Grid WPS-G Portal Federating Workflow Engine PI WPS-G WPS-G Grid Workflow Engine Grid One per mission Ground Segment Figure 1: Multi-Mission Processing Hierarchy. 2 As the processing on-demand extension is a result of the SSEGrid project where Grids are used to provide the processing power, the short name used in this document for this extension is WPS-G. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 3

10 2 References [1] OGC (2007a). OpenGIS Web Processing Service. OGC Implementation Specification OGC r7, Open Geospatial Consortium. [2] OGC (2007c): OpenGIS Web Services Common Specification. OGC implementation specification, OGC r3, Open Geospatial Consortium. [3] Transactional WPS Extension (WPS-T) Specification. OGC discussion paper, OGC , Open Geospatial Consortium. [4] OGC , WPS Change Request methods for controlling and checking the status of asynchronous processes. 4 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

11 3 WPS-G Operations As described above, the WPS specification has to be extended in order to dynamically deploy and undeploy processes and their auxiliary data and to allow for auditing as shown in Figure 2 as an UML class diagram. «interface» OGCWebService + getcapabilities() : Capabilities «interface» WebProcessingService + describeprocess() : ProcessDescription + execute() : ExecuteResponse «interface» Transactional-WebProcessingService + deployprocess() : DeployProcessResponse + undeployprocess() : UndeployProcessResponse «interface» Asynchronous-WebProcessingServ ice + cancel() : CancelResponse + getstatus() : GetStatusResponse + pause() : PauseResponse + resume() : ResumeResponse «interface» OnDemand-WebProcessingService + deploydata() : DeployDataResponse + describedata() : DataDescription + getaudit() : GetAuditResponse + undeploydata() : UndeployDataResponse Figure 2: WPS-G Operations. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 5

12 The Processing on-demand WPS (WPS-G) actually extends the WPS-T extension [3] with the following new operations: DeployData, UndeployData, DescribeData, and GetAudit. The GetCapabilities is also inherited from the parent WPS-T extension which itself inherits it from WPS standard. The Processing on-demand WPS also adopts (with some modifications) the changes proposed in [4] for controlling and checking the status of an asynchronous process. The modified operations are: GetStatus and Abort (renamed Cancel in this document). Finally, to avoid constant polling (using the GetSatus operation) by workflows acting as WPS clients, a callback mechanism is defined and must be supported by the Processing on-demand WPS. All operations are described in detail in the following sections. 6 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

13 4 Operation Specification Modified Operations 4.1 GetCapabilities Operation As explained above, the WPS-G extension adds four new operations. This requires the modification of the Capabilities document. The new operations are inserted in the <ows:operationmetadata> element as a new <ows:operation> elements as illustrated in the listing below. <ows:operation name="deploydata"> <ows:dcp> <ows:http> <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="undeploydata"> <ows:dcp> <ows:http> <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="describedata"> <ows:dcp> <ows:http> <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="getaudit"> <ows:dcp> <ows:http> <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> Listing 1: WPS-G Capabilities Extension. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 7

14 Also, similar to the Process Offerings, the Capabilities document is extended with Data Offerings which is a list of brief descriptions of the (auxiliary) data offered by the WPS-G service instance. Figure 3: GetCapabilities Response. The DataBrief data structure is very similar to the ProcessBrief data structure. An example of GetCapabilities request and response is given in section Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

15 4.2 Execute Operation As shown in the figure below, the ExecuteResponse is extended with a new optional ProcessInstanceIdentifier element that is needed for asynchronous related operations (e.g. GetStatus, Cancel). Using the identifier of a process instance (e.g. compact UUID) is more convenient than using the statuslocation attribute which is a URL pointing to the status document (updated ExecuteResponse). Figure 4: Execute Response. An example of Execute request and response is given in section 9.2. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 9

16 4.3 DeployProcess Operation As illustrated in the figure below, the DeployProcessResponse is extended with an optional <ows:identifier> process identifier element to avoid having to trace back to the corresponding DeployProcess request to find out about this identifier (the process identifier is provided in the ProcessDescription that is part of the DeployProcess request). Figure 5: DeployProcess Response. An example of DeployProcess request and response is given in section Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

17 4.4 UndeployProcess Operation For consistency, the UndeployProcess request is modified to use the <ows:identifier> element instead of a new <Process> element (with an id attribute) as shown below. Figure 6: UndeployProcess Request. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 11

18 As illustrated in the following figure, the UndeployProcessResponse is extended with an optional <ows:identifier> process identifier element in the same way as for the DeployProcessResponse (see section 4.3 above). Figure 7: UndeployProcess Response. An example of UndeployProcess request and response is given in section Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

19 4.5 GetStatus Operation As shown in the figure below, in the GetStatus request, the ProcessIdentifier (from CR , see [4]) is renamed to ProcessInstanceIdentifier and corresponds to the process instance identifier that is returned in the ExecuteResponse (see section 4.2 above). Figure 8: GetStatus Request. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 13

20 The GetStatusResponse is modified as illustrated below. Figure 9: GetStatus Response. A new StatusDocument type is introduced and is used in both the GetStatusResponse and the CancelResponse. This new type provides the same information as in the ExecuteResponse. Note that the response to a GetStatus request is a GetStatusResponse as opposed to an ExecuteResponse in CR [4]. An example of GetStatus request and response is given in section Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

21 4.6 Cancel Operation For consistency with other OGC standards (e.g. OGC SPS, OGC EO SPS, OGC Ordering) the Abort operation (from CR , see [4]) is renamed to Cancel. Additionally, the Cancel request is modified in the same way as for the GetStatus request (see section 4.5 above). The Cancel request is illustrated below. Figure 10: Cancel Request. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 15

22 As shown in the figure below, the CancelResponse is modified to use the new StatusDocument type also used in the GetStatusResponse (see section 4.5 above). Figure 11: Cancel Response. 16 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

23 Also, an optional ProcessInstanceIdentifier element is added for the same reason (traceability) as the process Identifier is added in the DeployProcessResponse (see section 4.3 above). Finally, the result element is consistent with DeployProcessResponse and UndeployProcessResponse and is the only required element of the response. Note that the success attribute is always true because otherwise an exception report message is returned as specified in [2]. An example of Cancel request and response is given in section 9.6. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 17

24 5 Operation Specification New Operations 5.1 DeployData Operation The DeployData operation shall offer requestors a means to dynamically deploy specified auxiliary data. The XML encoded request shall be sent via HTTP-POST and follows the schema specified in Figure Request The DeployData Request allows clients to dynamically deploy auxiliary data according to the data deployment profile. Figure 12 presents the structure of a DeployData request as a conceptual diagram. After a successful deployment, the data shall be present in the Capabilities <wps:dataofferings> list and be accessible like any other data. Figure 12: DeployData Request. The <DeployData> request is very similar to the <DeployProcessRequest> request of the transactional WPS extension [3]. The DataDescription to be provided is also similar to the ProcessDescription as shown in Figure 17. The data deployment profile allows for two forms of data deployment: the packaged data (Tar or Zipped file) can be delivered as part of the DeployData request or can be obtained by a different mechanism using the provided reference (e.g. URL). 18 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

25 5.1.2 Response The DeployDataResponse indicates if the request has succeeded or not. If the data has been successfully deployed, an XML document shall be returned back in compliance with the following schema: Figure 13: DeployData Response. The optional <ows:identifier> data identifier element is extracted from the DataDescription provided in the DeployData request. In case the data could not be successfully deployed an exception report message should be returned, which is described in the following section. Otherwise, success is set to true. An example of DeployData request and response is given in section 9.7. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 19

26 5.1.3 Exceptions In case a WPS server encounters an error while performing a DeployData operation, an exception report message as specified in [2] and Table 1 will be returned. Table 1: DeployData Exception codes. exceptioncode value OperationNotSupp orted MissingParameter Value InvalidParameterV alue oapplicablecode DeploymentProfile NotSupported Meaning of code Request is for an operation that is not supported by this server Operation request does not include a parameter value, and this server did not declare a default value for that parameter Operation request contains an invalid parameter value No other exceptioncode specified by this service and server applies to this exception The data could no be deployed due to the delivered schema is not supported locator value Name of operation not supported Name of missing parameter Name of parameter with invalid value None, omit locator parameter Name of operation to be deployed unsuccessfully 20 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

27 5.2 UndeployData Operation The UndeployData operation offers requestors a mechanism to undeploy a specified auxiliary data from a WPS. The XML encoded request shall be sent via HTTP-POST and shall follow the schema specified in Figure Request The <UndeployData> element should have exactly one <Identifier> element besides the elements inherited from the <wps:requestbasetype>. The <Identifier> element should have a codespace attribute, which should represent the data id of the data to be undeployed. Figure 14: UndeployData Request. The <UndeployData> request is very similar to the <UndeployProcessRequest> request of the transactional WPS extension [3]. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 21

28 5.2.2 Response The response for the UndeployData request shall be an XML document following the schema indicated in Figure 15. Figure 15: UndeployData Response. The optional <ows:identifier> data identifier element is extracted from the UndeployData request. Analogous to the DeployData result, the <Result> element shall indicate via the boolean success attribute, if the data could be successfully undeployed. A WPS-G shall be able to undeploy all data previously deployed via the DeployData operation. An example of UndeployData request and response is given in section Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

29 5.2.3 Exceptions When a WPS server encounters an error while performing a UndeployData operation, it shall return an exception report message as specified in [2] and Table 4. Table 2: UndeployData Exception codes. exceptioncode value OperationNotSupp orted MissingParameter Value InvalidParameterV alue Meaning of code Request is for an operation that is not supported by this server Operation request does not include a parameter value, and this server did not declare a default value for that parameter Operation request contains an invalid parameter value NoApplicableCode No other exceptioncode specified by this service and server applies to this exception UndeploymentFail The data could no be undeployed. ure locator value Name of operation not supported Name of missing parameter Name of parameter with invalid value None, omit locator parameter Name of operation to be deployed unsuccessfully Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 23

30 5.3 DescribeData Operation The DescribeData operation offers requestors a mechanism to obtain a description of a specified auxiliary data from a WPS. The XML encoded request shall be sent via HTTP- POST and shall follow the schema specified in Figure Request The <DescribeData> element should have exactly one <Identifier> element besides the elements inherited from the <wps:requestbasetype>. The <Identifier> element should have a codespace attribute, which should represent the data id of the data to be described. Figure 16: DescribeData Request. 24 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

31 5.3.2 Response The response for the DescribeData request shall be an XML document following the schema indicated in Figure 17. Figure 17: DescribeData Response. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 25

32 The DataDescription is similar to the ProcessDescription except that it does not contain DataInputs or ProcessOutputs. Instead, the DataDescription contains metadata about the deployed auxiliary data. This metadata shall be in the form of ISO metadata. An example of DescribeData request and response is given in section Exceptions When a WPS server encounters an error while performing a DescribeData operation, it shall return an exception report message as specified in [2] and Table 3. Table 3: DescribeData Exception codes. exceptioncode value OperationNotSupp orted MissingParameter Value InvalidParameterV alue Meaning of code Request is for an operation that is not supported by this server Operation request does not include a parameter value, and this server did not declare a default value for that parameter Operation request contains an invalid parameter value NoApplicableCode No other exceptioncode specified by this service and server applies to this exception locator value Name of operation not supported Name of missing parameter Name of parameter with invalid value None, omit locator parameter 26 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

33 5.4 GetAudit Operation The GetAudit operation offers requestors a mechanism to retrieve the process execution trace of a still running or completed process. This execution trace comes in two forms: Short form: provides the execution processing flow Long form: provides the full execution trace The short form is meant for WPS processes that are workflows that invoke other WPS processes. The long form is applicable to all types of WPS processes. The execution processing flow (short form) provides a trace of all the processes that have been executed (invoked) since the beginning of the execution of the workflow. The short form of the GetAudit operation response shall provide the execution processing history with the following information for each executed process: URL of the WPS-G service instance hosting the process Identifier of the process instance within this WPS-G service instance Timestamp of the process invocation The short form of the GetAudit operation allows for a client (e.g. the Portal) to recursively drill down the execution processing tree that may include several nested workflows. The long form of the GetAudit operation response shall provide the full execution trace with additional information such as the values taken by all the variables during the execution of the process instance. This can also be as simple as a execution log file. The XML encoded GetAudit request shall be sent via HTTP-POST and shall follow the schema specified in Figure 18. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 27

34 5.4.1 Request The <GetAudit> element should have exactly one <ProcessInstanceIdentifier> element besides the elements inherited from the <wps:requestbasetype>. This element should have a instanceid attribute, which should correspond to the process instance identifier that is returned in the ExecuteResponse (see section 4.2 above). Figure 18: GetAudit Request. The shortform attribute is optional and its default value is true. 28 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

35 5.4.2 Response The response for the GetAudit request shall be an XML document following the schema indicated in Figure 19. Figure 19: GetAudit Response. The optional <ProcessInstanceIdentifier> element is extracted from the GetAudit request. Analogous to the DeployData result, the <Result> element shall indicate via the boolean success attribute, if the audit could be successfully obtained. The <AuditTrace> element contains the requested audit trace along with the mandatory shortform attribute. For the long form, the exact content and format of this audit trace is not defined/imposed in this document. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 29

36 For the short form, the audit trace shall be an XML document following the schema indicated in Figure 20. Figure 20: Short Form Audit Trace. The short form audit trace consists of the following mandatory information for each process that has been executed (invoked) since the beginning of the execution of this audited process (workflow): URL of the WPS-G service instance hosting the process Timestamp of the process invocation Identifier of the process instance within this WPS-G service instance Optionally, the ProcessIdentifier of each process instance may also be provided. An example of GetAudit request and response is given in section Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

37 5.4.3 Exceptions When a WPS server encounters an error while performing a GetAudit operation, it shall return an exception report message as specified in [2] and Table 4. Table 4: GetAudit Exception codes. exceptioncode value OperationNotSupp orted MissingParameter Value InvalidParameterV alue Meaning of code Request is for an operation that is not supported by this server Operation request does not include a parameter value, and this server did not declare a default value for that parameter Operation request contains an invalid parameter value NoApplicableCode No other exceptioncode specified by this service and server applies to this exception RemoteComputati onerror An error occurred while obtaining audit information from remote server locator value Name of operation not supported Name of missing parameter Name of parameter with invalid value None, omit locator parameter None Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 31

38 6 Callback Mechanism In order to efficiently build workflows (i.e. without the need for polling), a process completion or failure notification mechanism is needed in the WPS-G service. To this end, we propose to simply make the WPS-G service an asynchronous service i.e. a service that will, upon completion or failure of a process instance, invoke a callback operation to be provided by the client (e.g. in the SOAP header using WS-Addressing) in the Execute operation. This of course implies that the client must be a Web service. Client 1: Execute WPS-G 2: Callback Figure 21: Asynchronous Service. The callback is a one-way operation and consists of an ExecuteResponse message. The following listing shows an example of a WSDL of a client that supports the Processing on-demand WPS extension (WPS-G) callback using SOAP. <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:wsdl=" xmlns:wsa=" xmlns:ns1=" xmlns:wpsg=" xmlns:ows=" xmlns:wsaw=" xmlns:http=" xmlns:xs=" xmlns:mime=" xmlns:soap=" xmlns:soap12=" xmlns:wpsx=" targetnamespace=" <wsdl:types> <xs:schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace=" <xs:include schemalocation="./wps/wpsall.xsd"/> <xs:import namespace=" schemalocation="./wsa/ws-addr.xsd"/> </xs:schema> </wsdl:types> <wsdl:message name="executeresponsecallbackrequest"> <wsdl:part name="parameters" element="wps:executeresponse"/> <wsdl:part name="relatesto" element="wsa:relatesto"/> </wsdl:message> <wsdl:porttype name="callbackwpsgporttype"> <wsdl:operation name="executeresponsecallback"> <wsdl:input message="wpsx:executeresponsecallbackrequest" wsaw:action="urn:executeresponsecallback"/> </wsdl:operation> </wsdl:porttype> 32 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

39 <wsdl:binding name="callbackwpsgsoap11binding" type="wpsx:callbackwpsgporttype"> <soap:binding style="document" transport=" <wsdl:operation name="executeresponsecallback"> <soap:operation soapaction="urn:executeresponsecallback" style="document"/> <wsdl:input> <soap:body parts="parameters" use="literal"/> <soap:header message="wpsx:executeresponsecallbackrequest" part="relatesto" use="literal"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:service name="mpi-workflowcallback"> <wsdl:port name="callbackwpsghttpsoap11endpoint" binding="wpsx:callbackwpsgsoap11binding"> <soap:address location=" </wsdl:port> </wsdl:service> Listing 2: Callback WSDL Example. The Execute request typically contains WS-Addressing information in the SOAP header such as the wsa:replyto element which indicates the callback URL and the wsa:messageid element which is used by the client to correlate the Execute response with the Execute request. The Execute response then contains the wsa:relatesto element filled with the wsa:messageid of the corresponding request. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 33

40 7 Appendix A XML Schema Documents In addition to this document, this discussion paper includes several XML Schema Documents. These XML Schema Documents are bundled in a zip file with the present document. The WPS XML Schema Documents are named: wpsgetcapabilities_request.xsd wpsgetcapabilities_response.xsd wpsexecute_request.xsd wpsexecute_response.xsd wpsdescribeprocess_request.xsd wpsdescribeprocess_response.xsd wpsdeployprocess_request.xsd wpsdeployprocess_response.xsd wpsundeployprocess_request.xsd wpsundeployprocess_response.xsd wpsgetstatus_request.xsd wpsgetstatus_response.xsd wpscancel_request.xsd wpscancel_response.xsd wpsdeploydata_request.xsd wpsdeploydata_response.xsd wpsundeploydata_request.xsd wpsundeploydata_response.xsd wpsdescribedata_request.xsd wpsdescribedata_response.xsd wpsgetaudit_request.xsd wpsgetaudit_response.xsd 34 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

41 The above WPS XML Schema Documents import common schemas that are named: WSDL.xsd ResponseBaseType.xsd RequestBaseType.xsd ProcessVersion.xsd ProcessBriefType.xsd DescriptionType.xsd DeploymentProfiles.xsd StatusDocumentType.xsd DataVersion.xsd DataBriefType.xsd ExtraCapabilities.xsd ProcessInstanceType.xsd ProcessAuditType.xsd All these XML Schema Documents contain documentation of the meaning of each element and attribute. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 35

42 8 Appendix B - Deployment Profile Examples The following section describes the two deployment profiles used in the SSEGrid project. 8.1 Apache ODE The following deployment profile is used when deploying workflows in the Apache ODE BPEL engine. Figure 22: Apache ODE Deployment Profile. The data deployment profile allows for two forms of process deployment: the packaged process (Tar or Zipped archive file) can be delivered as part of the DeployProcess request or can be obtained by a different mechanism using the provided reference (e.g. URL). The archive shall be compliant with the package expected by the Apache ODE Deployment service (deploy operation). 36 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

43 8.2 JavaSAGA The following deployment profile is used when deploying processes on a Grid through an extended JavaSAGA interface. Figure 23: JavaSAGA Deployment Profile. The data deployment profile allows for two forms of process deployment: the packaged process (Tar or Zipped archive file) can be delivered as part of the DeployProcess request or can be obtained by a different mechanism using the provided reference (e.g. URL). The archive shall contain the scripts, libraries, and executables that are needed to implement the WPS process as a Grid application. The JSDL template is used to describe the Grid job that implements the WPS process (job identification, application description, stage-in and stage-out instructions, etc). The template includes substitution variables (such as job identifier, working directory, result directory, WPS inputs, etc) that are evaluated at submission time. Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 37

44 9 Appendix C Request and Response Examples The sections below provide examples of requests and responses for all the WPS operations. 9.1 GetCapabilities Operation Request The following listing shows an example of a GetCapabilities request. <ns:getcapabilities service="wps" language="en-en"> <ns:acceptversions> <ns1:version>1.0.0</ns1:version> </ns:acceptversions> </ns:getcapabilities> Response The following listing shows an example of a GetCapabilities response. <wps:capabilities service="wps" version="1.0.0" xml:lang="en-us" xsi:schemalocation=" updatesequence="1" xmlns:wps=" xmlns:xlink=" xmlns:xsi=" xmlns:ows=" <ows:serviceidentification> <ows:title>52n WPS SSEGRID</ows:Title> <ows:abstract>service based on the 52north implementation of WPS 1.0.0</ows:Abstract> <ows:keywords> <ows:keyword>wps</ows:keyword> <ows:keyword>aafc</ows:keyword> <ows:keyword>geospatial</ows:keyword> <ows:keyword>geoprocessing</ows:keyword> </ows:keywords> <ows:servicetype>wps</ows:servicetype> <ows:servicetypeversion>1.0.0</ows:servicetypeversion> <ows:servicetypeversion>0.4.0</ows:servicetypeversion> <ows:fees>none</ows:fees> <ows:accessconstraints>none</ows:accessconstraints> </ows:serviceidentification> <ows:serviceprovider> <ows:providername>spacebel</ows:providername> <ows:providersite xlink:href=" <ows:servicecontact> <ows:individualname>christophe Noel</ows:IndividualName> <ows:positionname>software engineer</ows:positionname> <ows:contactinfo> <ows:phone> <ows:voice/> <ows:facsimile/> </ows:phone> <ows:address> 38 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

45 <ows:deliverypoint/> <ows:city>angleur</ows:city> <ows:administrativearea/> <ows:postalcode>4031</ows:postalcode> <ows:country>belgium</ows:country> </ows:address> </ows:contactinfo> </ows:servicecontact> </ows:serviceprovider> <ows:operationsmetadata> <ows:operation name="getcapabilities"> <ows:dcp> <ows:http> <ows:get xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="describeprocess"> <ows:dcp> <ows:http> <ows:get xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="execute"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="deployprocess"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="undeployprocess"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="getstatus"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 39

46 <ows:operation name="cancel"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="getaudit"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="deploydata"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="undeploydata"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> <ows:operation name="describedata"> <ows:dcp> <ows:http> <ows:get xlink:href=" <ows:post xlink:href=" </ows:http> </ows:dcp> </ows:operation> </ows:operationsmetadata> <wps:processofferings> <wps:process wps:processversion="2"> <ows:identifier>validationgrid1</ows:identifier> <ows:title>grid Test Process</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>cleanup</ows:identifier> <ows:title>cleanup</ows:title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>compositemodis</ows:identifier> <ows:title>composite MODIS</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>faparmodis</ows:identifier> <ows:title>fapar MODIS</ows:Title> 40 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

47 </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>importmodis</ows:identifier> <ows:title>import MODIS</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>remapmodis</ows:identifier> <ows:title>remap MODIS</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>smacmodis</ows:identifier> <ows:title>smac MODIS</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>publish</ows:identifier> <ows:title>publish</ows:title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>compositevgt</ows:identifier> <ows:title>composite VGT</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>faparvgt</ows:identifier> <ows:title>fapar VGT</ows:Title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>vitocafcollectdata</ows:identifier> <ows:title>vitocafcollectdata</ows:title> </wps:process> <wps:process wps:processversion="1.0"> <ows:identifier>importvgt</ows:identifier> <ows:title>import VGT</ows:Title> </wps:process> <wps:process wps:processversion="2"> <ows:identifier>validationgrid2</ows:identifier> <ows:title>grid Test Process</ows:Title> </wps:process> </wps:processofferings> <wps:languages> <wps:default> <ows:language>en-us</ows:language> </wps:default> <wps:supported> <ows:language>en-us</ows:language> </wps:supported> </wps:languages> <wps:dataofferings> <wps:data wps:dataversion="1.0.0"> <ows:identifier>geodata</ows:identifier> <ows:title>auxiliary geo data library</ows:title> </wps:data> <wps:data wps:dataversion="1.0.0"> <ows:identifier>sealandmask</ows:identifier> <ows:title>sea land mask</ows:title> </wps:data> <wps:data wps:dataversion="1.0.0"> <ows:identifier>smaccoefficients</ows:identifier> Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 41

48 <ows:title>smac coefficients</ows:title> </wps:data> <wps:data wps:dataversion="1.0.0"> <ows:identifier>superdata</ows:identifier> <ows:title>sample Data given as reference</ows:title> </wps:data> </wps:dataofferings> </wps:capabilities> 9.2 Execute Operation Request The following listing shows an example of an Execute request. <Execute language="en" service="wps" version="1.0.0" xmlns=" xmlns:ns=" <ns:identifier>validationgrid2</ns:identifier> <DataInputs> <Input> <ns:identifier>roitopleftlat</ns:identifier> <ns:title>roi Top Left Latitude</ns:Title> <Data> <LiteralData datatype="xs:float">90</literaldata> </Data> </Input> <Input> <ns:identifier>roitopleftlon</ns:identifier> <ns:title>roi Top Left Longitude</ns:Title> <Data> <LiteralData datatype="xs:float">-180</literaldata> </Data> </Input> <Input> <ns:identifier>roibottomrightlat</ns:identifier> <ns:title>roi Bottom Right Latitude</ns:Title> <Data> <LiteralData datatype="xs:float">-90</literaldata> </Data> </Input> <Input> <ns:identifier>roibottomrightlon</ns:identifier> <ns:title>roi Bottom Right Longitude</ns:Title> <Data> <LiteralData datatype="xs:float">180</literaldata> </Data> </Input> <Input> <ns:identifier>numberoftasks</ns:identifier> <ns:title>number of tasks in job</ns:title> <Data> <LiteralData datatype="xs:integer">3</literaldata> </Data> </Input> <Input> <ns:identifier>inputurls</ns:identifier> 42 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

49 <ns:title>list of URLS</ns:Title> <Data> <ComplexData> <ssegrid:urllist xsi:schemalocation=" count="8" xmlns:ssegrid=" xmlns:xsi=" <ssegrid:url> </ssegrid:urllist> </ComplexData> </Data> </Input> </DataInputs> <ResponseForm> <ResponseDocument status="true" storeexecuteresponse="true"> <Output> <ns:identifier>importedlist</ns:identifier> </Output> </ResponseDocument> </ResponseForm> </Execute> Response The following listing shows an example of an Execute response. <ExecuteResponse xmlns=" schemalocation=" serviceinstance=" =WPS" lang="en-us" service="wps" version="1.0.0" statuslocation=" <Process processversion="2"> <Identifier xmlns=" <Title xmlns=" xmlns:xlink=" xmlns:wps=" xmlns:ows=" xmlns:xsi=" Test Process</Title> </Process> <Status creationtime=" t11:47: :00"> <ProcessSucceeded>Process successful</processsucceeded> </Status> <DataInputs> <Input> <Identifier xmlns=" <Title xmlns=" Top Left Latitude</Title> <Data> <LiteralData datatype="xs:float">90</literaldata> </Data> </Input> <Input> <Identifier xmlns=" <Title xmlns=" Top Left Longitude</Title> <Data> <LiteralData datatype="xs:float">-180</literaldata> </Data> </Input> <Input> <Identifier xmlns=" Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 43

50 <Title xmlns=" Bottom Right Latitude</Title> <Data> <LiteralData datatype="xs:float">-90</literaldata> </Data> </Input> <Input> <Identifier xmlns=" <Title xmlns=" Bottom Right Longitude</Title> <Data> <LiteralData datatype="xs:float">180</literaldata> </Data> </Input> <Input> <Identifier xmlns=" <Title xmlns=" of tasks in job</title> <Data> <LiteralData datatype="xs:integer">3</literaldata> </Data> </Input> <Input> <Identifier xmlns=" <Title xmlns=" of URLS</Title> <Data> <ComplexData> <ssegrid:urllist xmlns:ssegrid=" xmlns:xsi=" count="8" xsi:schemalocation=" <ssegrid:url> </ssegrid:urllist> </ComplexData> </Data> </Input> </DataInputs> <ProcessOutputs> <Output> <Identifier xmlns=" <Title xmlns=" xmlns:xlink=" xmlns:wps=" xmlns:ows=" xmlns:xsi=" of Imported Products</Title> <Data> <ComplexData schema=" mimetype="text/xml"> <ssegrid:urllist xmlns:ssegrid=" xmlns:xsi=" count="1" xsi:schemalocation=" <ssegrid:url> with arguments</ssegrid:url> </ssegrid:urllist> </ComplexData> </Data> </Output> </ProcessOutputs> <ProcessInstanceIdentifier instanceid="984113c ac2e-68cad4a82615">984113c ac2e- 68cad4a82615</ProcessInstanceIdentifier> </ExecuteResponse> 44 Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved.

51 9.3 DeployProcess Operation Request The following listing shows an example of a DeployProcess request. <DeployProcess language="en" service="wps" version="1.0.0" xmlns=" xmlns:xsi=" <ProcessDescription wps:processversion="2" storesupported="true" statussupported="true" xmlns:wps=" xmlns:ows=" xmlns:xlink=" <ows:identifier>validationgrid2</ows:identifier> <ows:title>grid Test Process</ows:Title> <ows:abstract>process for validation testing. It only creates outputs including the submitted inputs.</ows:abstract> <DataInputs> <Input minoccurs="0" maxoccurs="1"> <ows:identifier>roitopleftlat</ows:identifier> <ows:title>roi Top Left Latitude</ows:Title> <ows:abstract>north bound latitude. Example: </ows:Abstract> <LiteralData> <ows:datatype ows:reference="xs:float">float</ows:datatype> <ows:allowedvalues> <ows:range> <ows:minimumvalue>-90</ows:minimumvalue> <ows:maximumvalue>90</ows:maximumvalue> </ows:range> </ows:allowedvalues> <DefaultValue>90</DefaultValue> </LiteralData> </Input> <Input minoccurs="0" maxoccurs="1"> <ows:identifier>roitopleftlon</ows:identifier> <ows:title>roi Top Left Longitude</ows:Title> <ows:abstract>west bound longitude. Example: </ows:Abstract> <LiteralData> <ows:datatype ows:reference="xs:float">float</ows:datatype> <ows:allowedvalues> <ows:range> <ows:minimumvalue>-180</ows:minimumvalue> <ows:maximumvalue>180</ows:maximumvalue> </ows:range> </ows:allowedvalues> <DefaultValue>-180</DefaultValue> </LiteralData> </Input> <Input minoccurs="0" maxoccurs="1"> <ows:identifier>roibottomrightlat</ows:identifier> <ows:title>roi Bottom Right Latitude</ows:Title> <ows:abstract>south bound latitude. Example: </ows:Abstract> <LiteralData> <ows:datatype ows:reference="xs:float">float</ows:datatype> <ows:allowedvalues> <ows:range> <ows:minimumvalue>-90</ows:minimumvalue> <ows:maximumvalue>90</ows:maximumvalue> </ows:range> Copyright 2011 Open Geospatial Consortium, Inc. All Rights Reserved. 45