Skip to content

1. Transactional Profiles and Docker profile

Spacebel sa edited this page Nov 17, 2017 · 16 revisions

The Transactional WPS Extension specification intends to deploy multiple kind of processes: BPEL workflows, Java process, Docker image. The "kind" of process is defined by a Deployment Profile identifier.

Processes are deployed and executed on (local or remote) backend servers/engines. The deployment and execution of the processes on these backends is handled by the specific implementation of the related Deployment Profile.

Use of Deploy Profile

As illustrated on the Deploy schema below, the Deploy operation requires to provide the wps:ProcessOffering document which provides all the information about the deployed application (e.g. inputs, outputs, and any specific information).

It also includes either the wps:Package containing the application itself (e.g. the BPEL document, the Java class or the Docker image binary) or a wps:Reference which contains a link to the application package.

Deploy schema

In the context of OGC Testbed 13 project, the wps:ProcessOffering could alternatively be provided in a OWS Context Atom Feed. The disadvantage of this approach is that the information embedded in that document is lost when a WPS client perform a discovery of the deployed process through a DescribeProcess operation. When OWS context metadata is relevant, we propose to include the information in the ows:Metadata section of the wps:ProcessOffering (globally or for a specific input when relevant).

Docker Profile

In the case of the OGC Testbed 13 project, a demonstrator has been implemented and include a Deployment Profile for deploying and running docker images.

The demonstrator implementation of this Docker profil relies on a single remote Docker engine and SSH access to this Docker host.

The Deployment Profile identifier is (currently) 'http://spacebel.be/profile/docker.xsd'.

Interface to the Dockerized Application

The interface from the WPS to the Dockerized application is based on the following conventions:

  • Any input value is received by the application in an environmnent variable
  • Any input file is received by the application on the file system. The location is provided in an environmnent variable.
  • Any application output (value or file) must be written by the application to a specific location. The location is received in an environmnent variable.
  • The syntax of environmnent variable name is WPS_INPUT_$identifier or WPS_OUTPUT_$identifier ($identifier must be provided in the Process Description as input or output identifier)

Application Package

When creating the Docker Image for a script a binary application, the following steps must be considered:

  1. Choose the application
  2. Select the inputs and outputs which will be exposed on the WPS (other inputs may be predefined parameters for example). These exposed inputs should be read in environmnent variables by the application as describe in section above.
  3. Describe the process in a formal WPS Process Description document (provided during the deploy)
  4. Wrap the application in a Docker project (a Dockerfile is required)
  5. Build the image

Package creation