OGC Testbed-13: Application Deployment and Execution Service ER

Publication Date: 2018-01-11

Approval Date: 2017-12-07

Posted Date: 2017-11-14

Reference number of this document: OGC 17-024

Reference URL for this document: http://www.opengis.net/doc/PER/t13-ES002

Category: Public Engineering Report

Editor: Pedro Gonçalves

Title: OGC Testbed-13: Application Deployment and Execution Service ER

OGC Engineering Report

COPYRIGHT

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is 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, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Table of Contents

1. Summary
2. References
3. Terms and definitions
4. Abbreviated terms
5. Overview
- 5.1. Scenario
6. Implementation
7. Alternative approach
Appendix A: Revision History
Appendix B: Bibliography

1. Summary

The Testbed-13 Earth Observation Clouds (EOC) effort supports the development of ESA’s Thematic Exploitation Platforms (TEP) by exercising envisioned workflows for data integration and processing that are deployed in multiple clouds. The Application Deployment & Execution Service OGC Engineering Report (ER) identifies the Application Programming Interface (API) for delivering all functionality provided to realize the testbed scenario.

This ER will list the requirements fulfilled by Cloud APIs in order to allow an automation of the application package deployment and execution workflow and capture implementation process experiences.

1.1. Requirements

This ER will document the automation of the application package deployment taking in consideration an application package defining:

Identify the application to which it refers
Describe the required execution environment for the application
Identify how to deploy and launch the application
Describe the input data collections
Describe additional input parameters

1.2. Key Findings and Prior-After Comparison

The serialization and deployment of applications behind an OGC Web Processing Service (WPS) service was the subject of several discussions at OGC Standards Working Group (SWG) and Domain Working Group (DWG) in the past. A diverse number of issues were identified but the main barriers were due to the diversity of runtime environment to support and the respective technology maturity hampered its feasibility.

The advance in container technology together with the concept of federation of Clouds presents new opportunities to address this issue. Previously the constraints imposed in describing the runtime environments (e.g. Linux, Java VM, Perl, Python) and the respective application installation would create a considerable amount of information needed for the application package information model outside the OGC aegis. With containers most of these requirements are addressed at their respective level with configuration and software elements packaged into isolated elements.

This ER will capture implementation process experiences for Exploitation Platform (EP) Application Packages and their deployment in multiple clouds.

1.3. What does this ER mean for the Working Group and OGC in general

This ER is relevant to the WPS SWG because it lists the requirements fulfilled by Cloud APIs in order to allow WPS-supported automation of application package deployment and execution.

1.4. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name	Organization
Pedro Gonçalves	Terradue
Peter Vretanos	CubeWerx
Patrick Jacques	Spacebel
Christophe Noël	Spacebel
Paulo Sacramento	Solenix

1.5. Future Work

Future OGC testbeds should look to develop draft WPS profiles for Cloud application deployment and execution. It may also be necessary to develop extensions to the WPS standard, for example using interfaces based on Representational State Transfer (REST) to support Cloud application deployment and execution.

1.6. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following normative documents are referenced in this document.

NOTE: Only normative standards are referenced here, e.g. OGC, ISO or other SDO standards. All other references are listed in the bibliography. Example:

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.

3.1. Area Of Interest

An Area of Interest is a geographic area that is significant to a user.

3.2. Context Document

A Context Document is a document describing the set of services and their configuration, and ancillary information (area of interest etc) that defines the information representation of a common operating picture.

3.3. Dockerfile

A text document that contains all the commands a user could call on the command line to assemble an image.

3.4. Container

A lightweight and configurable virtual machine with a simulated version of an operating system and its hardware, which allow software developers to share their computational environments.

3.5. Infrastructure as a Service (IaaS)

A standardized, highly automated offering, where compute resources, complemented by storage and networking capabilities are owned and hosted by a service provider and offered to customers on-demand. Customers are typically able to self-provision this infrastructure, using a Web-based graphical user interface that serves as an IT operations management console for the overall environment. API access to the infrastructure may also be offered as an option.

3.6. Resource

A resource is a configured set of information that is uniquely identifiable to a user. Can be realized as in-line content or by one or more configured web services.

3.7. Virtual Machine Image

A virtual machine image is a template for creating new instances. An image can offer plain operating systems or can have software installed on them, such as databases, application servers, or other applications.

3.8. Thematic Exploitation Platform (TEP)

A "Thematic Exploitation Platform" refers to an environment providing a user community interested in a common Theme with a set of services such as very fast access to (i) large volume of data (EO/non-space data), (ii) computing resources (iii) processing software (e.g. toolboxes, RTMs, retrieval baselines, visualization routines), and (iv) general platform capabilities (e.g. user management and access control, accounting, information portal, collaborative tools, social networks etc.). The platforms thus provide a complete work environment for its' users, enabling them to effectively perform data-intensive research and data exploitation by running dedicated processing software close to the data.

4. Abbreviated terms

ADES Application Deployment and Execution Service
AMC Application Management Client
API Application Programming Interface
EOC Earth Observation Clouds
IdP Identity Provider
JSF JavaServer Faces
PEP Policy Enforcement Point
SAML Security Assertion Markup Language
STS Security Token Service
TEP Thematic Exploitation Platform
WPS Web Processing Service

5. Overview

This ER reports the implementation experiments for the deployment of applications built in the context of the European Space Agency (ESA) initiative to build an ecosystem of Thematic Exploitation Platforms (TEP). A TEP refers to a computing platform that follows a given set of scenarios for users, data and ICT (Information and Communications Technology) provision aggregated around an Earth Science thematic area. The TEPs define three canonical user scenarios covering the EO data exploitation (users discover and manipulate data), new EO service development (users deploy a new processor) and new EO product development (users publish new results). The TEPs implement these canonical scenarios and move the processing to the data, rather than the data to the users, thereby enabling ultra-fast data access and processing.

Algorithms are initially developed by a third-party developer and subsequently deployed in a TEP. An application package document that contains all the information necessary to allow applications (implementing said algorithms) to be specified and deployed in federated resource providers is one of the main outcomes of this effort.

The application package encoding conveys all the information needed for encapsulating user applications and enabling their automatic management (upload, deploy, run) in diverse platforms. The consensus reached in the Testbed-13 EOC thread was to use the OGC Web Services (OWS) Context document to convey the information model. This document is used as an input parameter to a dedicated WPS service that will create and deploy it in a new WPS instance. An alternative approach is also proposed that uses the WPS description document to directly embed the OWS Context Document in an existing WPS Transactional Service.

This ER focuses on both technical approaches, with two sections that describe the different applications and their respective deployment and execution processes. Both approaches follow a common scenario described below.

5.1. Scenario

The application package will allow the developer (e.g. Markus) to register an application that will be deployed in a given ICT provider. The application is first built and registered in a third-party Application Hub (e.g. DockerHub). The developer will then directly interact with the Application Management Client (AMC) that will register the application on the Application Deployment and Execution Service (ADES).

The sequence of actions is described in the following image.

Figure 1. Sequence of Deploy and Register Steps

With the application registered, a user (e.g. Jim) can directly interact with the AMC that will allow the execution of the application on the ADES.

The sequence of actions for the execution is described in the following image.

Figure 2. Sequence of Execution Steps

The overall components and respective flow is presented below.

Figure 3. Overview of Deploy, Register and Execution Scenario

6. Implementation

6.1. Overview

The Application Package targets applications built by third party developers and contains all the information necessary for their deployment in different infrastructures. It uses an ATOM OWS Context document as the document encoding and WPS as the execution interface. This chapter will address several implementation issues discussed by the EOC thread with particular focus on the approaches to application packaging, application execution and data access.

6.2. Application Package

The application package encoding conveys all the information needed for encapsulating user applications and enabling their automatic management (upload, deploy, run) in diverse platforms. It uses the OWS Context document encoding to convey the necessary information model as an input parameter to a dedicated WPS service that creates and deploys it in a new WPS instance. The requirements and respective encoding are described on the other Testbed-13 EOC ER (OGC 17-023) [2] dedicated to reporting of the Application Package

6.3. Data Fetching

The ADES provides a framework to deal with the data management tasks regarding the input file access and the registration of the output files. This is provided by two abstract functions that deal with the data staging and stage out that is executed by the application.

For data staging the convention is to map a file location from a URL (e.g. S3, FTP, Atom feed) to a local copy. The actual operation performed depends on the deployed infrastructure and data access mechanisms and it should be transparent for the application. It can consist of a simple string transformation based on previous knowledge about the data storage or to an actual data transfer mechanism that will provide the file data stream to the local processing.

staging https://iptpoland.pl/store/S1A_IW_RAW__0SDV_20170720…1D5B8_1722.zip
> /mounted/S1/S1A_IW_RAW__0SDV_20170720T091638_20170720T091710_017553_01D5B8_1722.zip

Equivalently, for the data stage out, the infrastructure will make available a specific convention. This operation will map a specific resulting file into the infrastructure publish mechanism guaranteeing the file safeguard and the subsequent access by the WPS client.

stageout FloodMap_20170504_max.tif
> https://store.terradue.com/production/097321986198678956-W/FloodMap_20170504_max.tif

6.3.1. Data Discovery

The application clients are expected to access EO catalogues using OpenSearch with Geo, Time and EO extensions that allows standardized and harmonized access to metadata of satellite Earth observation data. This provides the necessary information for discovery (i.e. search) and retrieval (i.e. access) of EO data in the different providers. A major issue detected was the need to register each collection multiple times for each data provider. As such, each collection needed to be identified not only by the type of data but also the origin of the storage. For example, Sentinel-2 in the IPT provider was identified in the FedEO catalogue explicitly as EOP:IPT:Sentinel2, whereas the same data in Amazon, was identified as EOP:SENTINEL-HUB:Sentinel2. This implies that the same collection needs to have two different OpenSearch endpoints. When directing the processing to the resources in IPT Poland it is thus necessary to also provide a specific OpenSearch Description as:

http://geo.spacebel.be/opensearch/request?httpAccept=application/atom%2Bxml&parentIdentifier=EOP:IPT:Sentinel2

While in processing in Amazon, the same collection is discovered using

http://geo.spacebel.be/opensearch/request/?httpAccept=application/atom%2Bxml&parentIdentifier=EOP:SENTINEL-HUB:Sentinel2

To overcome this issue, the thread analyzed the possibility to define an optional OpenSearch parameter that would make the intended download location a query item of the search. This parameter defined in the EO extension with the template:

	...&from={eop:accessedFrom}

The parameter value would be a string identifying the location from which the resource will be accessed. Catalogue services that support this extension would then be able to return the download location in the enclosure atom link according to the requested processing location access service or, if possible, the real data address. For example, when processing in IPT Poland, one would add the parameter:

	...&from=eocloud.eu

And would obtain a file directly the corresponding access URL:

	file:///eodata/Sentinel-2/MSI/L1C/2017/11/03/S2B_MSIL1C_20171102T235229_N0206_R130_T57KUQ_20171103T005600.SAFE

If processed in AMAZON, the parameter would have the value:

	...&from=amazonws

and would obtain the value in the s3 format such as:

s3://sentinel-s2-l1c/tiles/23/M/QM/2017/11/13/0

When the client does not provide an indication of the intended access, catalogue should return their default location:

     http://scihub.copernicus.eu/apihub/Products('0f1ed8d7-eb6e-51aa-a617-7f632e8df960')/$value

Catalogue services are also recommended to provide the list of suggested parameters values in the OpenSearch Description Document. As such, catalogues should return a Parameter element as the example below:

<param:Parameter name="from" value="{eop:accessedFrom?}" minimum="0"
    title="A string identifying the location from where the download will be initiated. The response includes the best download location in the enclosure atom link (rel=’enclosure’) taking in consideration the value of the parameter." >
      <param:Option value="eocloud.eu" label="IPT Poland Cloud" />
      <param:Option value="amazonws" label="Amazon Cloud" />
      <param:Option value="PSNC" label=" EVER-EST VRE" />
</param:Parameter>

Terradue did an experimental implementation of this issue and the findings will be proposed as Change Request for the 13-026r8 Document to be discussed on the EO Product Metadata and OpenSearch SWG.

6.4. Application Parameters

The ADES provides a framework to deal with correct assignment of the application parameters. This is provided by one abstract function that provides the application a method for accessing the parameters values. For that the application uses a function for accessing the request parameters that from the command line would behave like:

$ getparam AreaOfInterest
> POLYGON(78427,321478321786, 391267841236 …. )
$ getparam inputcat
> https://catalog.terradue.com//sentinel1/search?format=atom&uid=S1A_IW_RAW__0SDV_20170720T091638_20170720T091710_017553_01D5B8_1722

An alternative solution using the environmental variable approach is also described in the next chapter.

6.5. Application Management Client

6.5.1. Solenix implementation

Introduction

This clause describes the implementation of the Solenix AMC. The section refers to fictitious users Marco and Jim.

The Solenix AMC provides two main GUIs, a Management GUI (e.g. for Marco) and a User GUI (e.g. for Jim).

The Management GUI implements three basic functionalities:

Browse Applications: that Marco can use to get a list of applications previously registered in one of the available ADES implementations
Register New Application: that Marco can use to upload an Application Package in OWS Context format for registration in one of the available ADES implementations
Unregister Application: that Marco can use to unregister an application previously registered in one of the available ADES implementations

The User GUI instead implements the following functionality:

Execution Listing: that Jim can use to list previously launched application executions, see their statuses and results
Application Selection: that Jim can use to select one of the applications previously registered in one of the available ADES implementations. This triggers the dynamic and automated generation of user input fields
Application Usage: highly dependent on the specific application, it allows Jim to provide all the inputs expected by the application, if necessary allowing him to perform catalogue searches in order to fill-in some of the inputs

Main GUI Screens

The Figure below shows the main screen of the Solenix AMC. From it, the user (Marco or Jim) can choose the Management (for Marco) or User GUI (for Jim):

Figure 4. Main screen of Solenix AMC

Management GUI

Once on the Management GUI, Marco can choose to browse registered applications, register a new application or unregister an application:

Figure 5. Solenix AMC Management GUI: Main screen

By clicking on 'Browse Applications', Marco is able to select the specific ADES implementation and list the applications registered in it. This triggers a WPS GetCapabilities on the selected ADES:

Figure 6. Solenix AMC Management GUI: Browse Applications

By clicking on 'Register New Application', and after choosing the desired server (an implementation of the ADES exposing a WPS endpoint), Marco will be able to upload an Application Package - an instance of OWS Context according to the format agreed in OGC Testbed-13 (see Exploitation Platform Application Package Engineering Report [2] ):

Figure 7. Solenix AMC Management GUI: Register New Application

Once this is done, some summary information about the AP will be shown and Marco will be able to confirm registration in the selected endpoint. This will trigger a WPS Execute operation on the DeployProcess process exposed by the selected ADES:

Figure 8. Solenix AMC Management GUI: Register New Application, After AP upload

User GUI

Coming back to the main screen and selecting the User GUI, Jim will see the following main screen, which allows choosing between a list of previous executions and issuing a new execution:

Figure 9. Solenix AMC User GUI: Main screen

The 'List Executions' page lists previously launched WPS Executions in any of the known ADES implementations:

Figure 10. Solenix AMC User GUI: List of Executions

The 'New Execution' page allows launching new WPS requests on one of the known ADES implementations and previously registered applications - input fields per application are dynamically discovered and shown:

Figure 11. Solenix AMC User GUI: New Execution

6.6. Application Deployment and Execution Service

6.6.1. Introduction

This clause describes the two implementations of the ADES by CubeWerx and Terradue.

Both ADES implements the WPS standard (versions 1 & 2). The CubeWerx implementation is part of CubeSERV which is a component of the CubeWerx Suite while the Terradue implementation is part of the Terradue Cloud Platform.

6.6.2. Deploy

When initially deployed, both ADES offer two processes, DeployProcess and UndeployProcess. These processes, in turn, allow application developers to then add additional processes, each described by an application package (see OGC 17-023).

These methods are designed to emulate the DeployProcess and UndeployProcess requests defined in the Transactional WPS Extension (see OGC 13-071r1). The primary benefits of taking this approach, as opposed to implementing OGC 13-071r1, are:

Any version of the WPS standard can deploy these methods
Existing WPS clients are able to interact with these methods as they do with any other WPS processes.

The following tables, describe the parameters of the DeployProcess and UndeployProcess process offerings.

Table 2. Deploy Process Parameters
Parameter Name	O/M	In/Out	Description
applicationPackage	M	In	An ATOM-encoded OWS context document (see OGC 12-084r2) describing the application to be deployed
deployResult	M	Out	The format of the response to the operation

Table 3. Undeploy Process Parameters
Parameter Name	O/M	In/Out	Description
processIdentifier	M	In	The identifier of the process to undeploy
undeployResult	M	Out	The format of the response to the operation

Note	Only processes added using the DeployProcess method may be undeployed.

Note	The UndeployProcess implementation does not implement the keepExecutionUnit parameter from OGC 13-071.

Note

At the moment, the ADES uses the application identifier specified in the application package. This means that there is the possibility of duplicate identifiers. The CubeWerx server checks for this and throws an exception if the specified identifier is a duplicate, while the Terradue implementation replaces the application. An alternative approach could be for the server to ignore the process identifier specified in the application package and simply generate a new, unique identifier.

The following XML fragment is generated from both implementations WPS server and describe the DeployProcess and UndeployProcess processes:

   <ProcessOffering processVersion="1.0.0">
      <Process xml:lang="en">
         <ows:Identifier codeSpace="http://www.opengis.net/tb13/eoc">DeployProcess</ows:Identifier>
         <ows:Title>Deploy Process</ows:Title>
         <ows:Abstract>This method will deploy an application encapsulated within a Docker container as a process accessible through the WPS interface.</ows:Abstract>
         <Input minOccurs="1">
            <ows:Identifier codeSpace="http://www.opengis.net/tb13/eoc">applicationPackage</ows:Identifier>
            <ows:Title>Application Package</ows:Title>
            <ows:Abstract>An application package, encoded as an ATOM-encoded OWS context document, describing the details of the application.</ows:Abstract>
            <ComplexData>
               <Format mimeType="application/atom+xml" default="true"/>
            </ComplexData>
         </Input>
         <Output>
            <ows:Identifier codeSpace="http://www.opengis.net/tb13/eoc">deployResult</ows:Identifier>
            <ows:Title>Deploy Result</ows:Title>
            <ows:Abstract>The server's response to deploying a process.  A successful response will contain a summary of the deployed process.</ows:Abstract>
            <ComplexData>
               <Format mimeType="text/xml" default="true"/>
            </ComplexData>
         </Output>
      </Process>
   </ProcessOffering>
   <ProcessOffering processVersion="1.0.0">
      <Process xml:lang="en">
         <ows:Identifier codeSpace="http://www.opengis.net/tb13/eoc">UndeployProcess</ows:Identifier>
         <ows:Title>Undeploy Process</ows:Title>
         <ows:Abstract>This method removes a previously deployed process from the WPS.</ows:Abstract>
         <Input minOccurs="1">
            <ows:Identifier codeSpace="http://www.opengis.net/tb13/eoc">processIdentifier</ows:Identifier>
            <ows:Title>Process Identifier</ows:Title>
            <ows:Abstract>The identifier of the process to remove from the WPS.</ows:Abstract>
            <LiteralData>
               <Format mimeType="text/plain" default="true"/>
               <LiteralDataDomain>
                  <AnyValue/>
                  <ows:DataType
                     ows:reference="http://www.w3.org/TR/xmlschema-2/#anyURI">anyURI</ows:DataType>
               </LiteralDataDomain>
            </LiteralData>
         </Input>
         <Output>
            <ows:Identifier codeSpace="http://www.opengis.net/tb13/eoc">undeployResult</ows:Identifier>
            <ows:Title>Undeploy Result</ows:Title>
            <ows:Abstract>This is the server's response when undeploying a process.  A successful response will contain the identifier of the undeployed process.</ows:Abstract>
            <ComplexData>
               <Format mimeType="text/xml" default="true"/>
            </ComplexData>
         </Output>
      </Process>
   </ProcessOffering>

The following XML schema fragments define the response elements for the DeployProcess and UndeployProcess methods:

   <element name="DeployResult" type="wps:DeployResultType">
      <annotation>
         <documentation>DeployProcess result.</documentation>
      </annotation>
   </element>
   <complexType name="DeployResultType">
      <sequence>
         <element name="DeploymentDone" type="boolean"/>
         <choice>
            <element name="ProcessSummary" type="wps:ProcessSummaryType"
                     minOccurs="0">
               <annotation>
                  <documentation>If DeploymentDone = true</documentation>
               </annotation>
            </element>
            <element name="FailureReason" type="xs:string">
               <annotation>
                  <documentation>If DeploymentDone = false</documentation>
               </annotation>
            </element>
         </choice>
      </sequence>
   </complexType>
   <element name="UndeployResult" type="wps:UndeployResultType">
      <annotation>
         <documentation>UndeployProcess result.</documentation>
      </annotation>
   </element>
   <complexType name="UndeployResultType">
      <sequence>
         <element name="UndeploymentDone" type="boolean"/>
         <choice>
            <sequence>
               <annotation>
                  <documentation>If UndeploymentDone = true</documentation>
               </annotation>
               <element ref="ows:Identifier" minOccurs="0">
                  <annotation>
                     <documentation>Identifier of the undeployed process.</documentation>
                  </annotation>
               </element>
               <element ref="wps:Capabilities" minOccurs="0">
                  <annotation>
                     <documentation>Updated Capabilities document.</documentation>
                  </annotation>
               </element>
            </sequence>
            <element name="FailureReason" type="xs:string">
               <annotation>
                  <documentation>If UndeploymentDone = false</documentation>
               </annotation>
            </element>
         </choice>
      </sequence>
   </complexType>

These elements may be returned as bare elements or embedded within a WPS response document depending on the response form (i.e. response="raw" or response="document").

The Terradue implementation provides a graphical user interface allowing deployment directly from the web browser for authorized users.