Overview

This page presents a comparison of the OGC API Processes and how processes are handled by OpenEO.

API description

Neither OAPIP nor OpenEO define a specific resource for retrieving the OpenAPI definition of the API. However, OAPIP requires that a link (rel=service-doc) be listed in the metadata that points to a location from which the document can be retrieved. Furthermore, for legacy reasons, it is common practice in OGC to offer the OpenAPI document at the /api endpoint.

Authenication

OpenEO

OpenEO, offers several endpoints (/credentials/oidc, /credentials/basic and /me) from which authentication metadata may be retrieved.

OAPIP

OAPIP completely relies on OpenAPI for describing the authentication requirements of the endpoint.

Processes Discovery

Overview

Both OAPIP and OpenEO offer a list of processes at the /processes endpoint.

OpenEO

OpenEO provides the full description of each built-in processes at the /processes endpoint.

OpenEO distinguishes between built-in processes and user-defined processes. User-defined processes can be listed at the /process_graphs endpoint.

OPAIP

At the /processes endpoint, OAPIP offers a list of summary descriptions of each processes offered by a deployment. The full description for each process can be obtained from the /processes/{processID} endpoint.

In OAPIP all processes, regardless of how they happen to find their way to the service, are listed at the /processes endpoint. Built-in processes are distinguished from dynamically added processes in metadata using a flag named mutable.

User Defined Processes / Workflows

OpenEO

OpenEO defines a language (process graphs) for defining workflows. Processes added as user-defined processes are managed through the separate /process_graphs resource.

OAPIP

OPAIP is still in the process of defining its chaining and workflow capability but persistent workflows would be materialized like any other process. That is they would listed and executed through the /processes resource.

User Defined Functions

OpenEO

OpenEO also has the concept of user-defined functions. User defined functions are execution units that can be executed on the server (using the run_udf built-in process) or externally from the server (using the run_udf_externally). User-defined function that are meant to be executed on the server must have execution units expressed in Python or R. Externally executed user-defined functions can be anything.

OAPIP

OAPIP is still developing its capability for adding processes to a server. The current approach is to POST a description of the process to the /processes endpoint. The description of the process is called an "application package". An application package contains metadata about the process, the execution unit and resource requirements to execute the process. The execution unit can be a Docker container, in which case the application package is a reference to the Docker container. However, services are also free to implement other runtimes (e.g. Python, R, etc.) in which case the execution unit would be the source code of the process for the target runtime.

Process Execution and Job Control

Overview

This section compares how OpenEO and OAPIP execute and manage jobs differently.

OpenEO Execution and Job Control

  • In OpenEO a process is executed synchronously using the POST method at the /result endpoint. The body of the request is a process graph.

  • In OpenEO a process is executed asynchronously by first submitting a new job using the POST method at the /jobs endpoint. The body of the request is a process graph.

  • Once submitted, the job can be modified at the /jobs/{jobID} endpoint using the PATCH and DELETE methods.

  • The POST method is used at the /jobs/{jobID}/results endpoint to queue a process for execution. The body is empty.

  • Process execution can be cancelled using the DELETE method at the /jobs/{jobID}/results endpoint.

  • Once execution is completed, the processing result can be retrieved using the GET method at the /jobs/{jobID}/results endpoint.

OAPIP Execution and Job Control

  • In OAPIP process execution is initiated at the /processes/{processID}/execution endpoint using the POST method. The body contains a JSON-encoded execute request.

  • Whether a processes is executed synchronously or asynchronously is controlled by the definition of the process and a negotiation between the client and the server using the Prefer header.

  • Jobs creation in OAPIP is implicit. Executing a process asynchronously implicitly creates a job. Executing a process synchronously may create a job.

  • Once created a job can cancelled (if it is running) or removed (if it had completed execution) using the DELETE method at the /jobs/{jobID} endpoint.

  • Processsing results for a completed job can be retrieved using the GET method at the /jobs/{jobID}/results endpoint.

Resource Trees

[expand all] [collapse all]

OAPIP Resource Tree

    • /api [GET: Get the API description.]
    • /conformance [GET: Get the list of implemented conformance classes for this OGC API deployment.]
        • /execution [POST: Execute the process.]

OpenEO Resource Tree

    • /file_formats [GET: Get the supported file formats.]
    • /conformance [GET: Get the list of implemented conformance classes for this OGC API deployment.]
    • /udf_runtimes [GET: Get the list of supported UDF runtimes.]
    • /service_types [GET: Get the list of supported secondary web service protocols.]
    • /me [GET: Get information about the authenticated user.]
      • /{collectionID} [GET: Get information about this collection.]
    • /processes [GET: Get the list of available predefined processes.]
    • /validation [POST: Validate a user-defined process graph.]
    • /result [POST: Execute a process and get result (synchronous).]
        • /estimate [GET: Get a cost estimate of this batch job.]
        • /logs [GET: Get a logs for this batch job.]
        • /results [GET: Get the results of this batch job.] [POST: Start processing this batch job (ASYNC).] [DELETE: Cancel processing of this batch job.]
Copyright © 1997-2020 CubeWerx Inc.