Inputs processing chaining

docs/processing/ades.md

@@ -1,29 +1,43 @@
-# ADES [TODO]
+# ADES
 
-==[To be completed by Terradue]==
+## Description
 
-> The purpose of this section is to identify the building-block, its role in the architecture, and its relationship to the other building-blocks expressed through the interfaces it provides and consumes. The idea is to provide a singular entrypoint to the EOEPCA building-blocks.<br>
-> In the first instant, gather relevant information from existing docs/wikis where it exists, and collate here.<br>
-> Use dedicated markdown files to separate the sub-section content if needed.<br>
-> Use diagrams where useful.
+The Application Deployment & Execution Service (ADES) forms a critical component within the Earth Observation Exploitation Platform Common Architecture (EOEPCA) functioning as a hosted execution engine, empowering users to initiate and manage processing jobs efficiently. By enabling the use of applications either self-developed or sourced from the platform community, ADES serves as a versatile tool for data processing and management.
 
-## Description
+Within the broader EOEPCA ecosystem, ADES plays a pivotal role. It aligns with the overarching goal of the EOEPCA to facilitate advanced Earth observation technologies and data exploitation. By providing a robust and user-friendly platform for deploying and executing applications, ADES enhances the capacity of users to process, analyze, and utilize Earth observation data effectively. This alignment with the EOEPCA's objectives underscores the importance of ADES in advancing Earth observation technology and its applications.
+
+The ADES utilizes the Common Workflow Language (CWL) to describe and manage EO application packages. CWL offers a standardized, flexible way to define and execute workflows across various computational environments. 
+In ADES, CWL is used to create detailed blueprints of EO applications, outlining parameters, dependencies, and required computational steps. This approach ensures that EO applications, whether written in Python, R, Java, or other programming languages, are packaged and executed consistently and reproducibly across different platforms. The use of CWL in ADES simplifies the process of deploying complex workflows and ensures that these workflows are portable and adaptable to various execution contexts, such as local machines, cloud resources, or high-performance computing environments.
+
+## Functionalities 
+
+The ADES has two distinct functionalities, one for deployment and another for execution that work in tandem to provide a streamlined process for deploying and executing EO applications. 
+
+* Deployment: Used for deploying EO applications by handling the submission of application packages, which are described using CWL. This involves specifying parameters, software items, executables, dependencies, and metadata. The deployment interface is responsible for setting up these applications in the ADES environment, ensuring they are ready for execution.
+
+* Execution: Once the applications are deployed, the execution is used to initiate and manage the processing jobs. Users interact with this functionality to execute the deployed EO applications, providing necessary input parameters and initiating the processing tasks. The execution interface manages the running of these applications, handling task scheduling, monitoring, and the retrieval of outputs.
 
-> Description to include:
-> 
-> * role in the architecture
-> * functional capabilities
 
 ## Interfaces
 
-> Specification of interfaces provided by the component.<br>
-> Link to external specifications if applicable.
+OGC API - Processes Part 1 and Part 2 are critical components of the Open Geospatial Consortium (OGC) standards, providing guidelines for the execution and deployment of computational processes in geospatial and EO applications. While OGC API Processes Part 1 addresses the execution of processes, Part 2 delves into the deployment of these processes. This includes the standards and protocols for uploading and managing process descriptions, setting up new processes, and configuring process environments within a service like ADES. By defining a consistent and interoperable approach, Part 2 ensures that the deployment of processing tasks in geospatial and Earth Observation contexts is streamlined, efficient, and compatible across different platforms and services.
+
+The ADES follows specific standards for its deployment and execution interfaces as defined by the OGC API Processes:
+
+* Deployment Interface: The ADES deployment interface is defined in the OGC API Processes Part 2. This part of the standard outlines the protocols and methods for deploying Earth Observation applications within the ADES framework.
+
+* Execution Interface: The execution interface of ADES is aligned with the guidelines set in OGC API Processes Part 1. This section specifies the standards for executing the deployed applications, detailing how users can initiate and manage processing jobs within the ADES environment.
+
 
 ## Dependencies
 
-> Describe links with other eoepca components - e.g. interfaces consumed.
+The ADES can interact with other EOEPCA building blocks but has no dependencies 
 
 ## Additional Information
 
-> Include descriptions of anything that is relevant to help users of the component.<br>
-> Links to other relevant information.
+* [Zoo-Project](https://www.zoo-project.org/)
+* ZooCalrissianRunner:
+  * [Software Repository](https://github.com/EOEPCA/zoo-calrissian-runner)
+  * [Documentation](https://eoepca.github.io/zoo-calrissian-runner/)
+* [Default processing service template](https://github.com/EOEPCA/proc-service-template)
+

docs/processing/application-hub.md

@@ -1,70 +1,34 @@
-# Application Hub [TODO]
-
-==[To be completed by Terradue]==
-
-> The purpose of this section is to identify the building-block, its role in the architecture, and its relationship to the other building-blocks expressed through the interfaces it provides and consumes. The idea is to provide a singular entrypoint to the EOEPCA building-blocks.<br>
-> In the first instant, gather relevant information from existing docs/wikis where it exists, and collate here.<br>
-> Use dedicated markdown files to separate the sub-section content if needed.<br>
-> Use diagrams where useful.
+# Application Hub
 
 The Application Hub provides integrated web tooling to perform interactive analysis, to develop, test & package apps for ADES execution, and to provide a user-extensible capability for interactive dashboards. This includes a web IDE (Code Server) that provides an environment that seeks to replicate the conditions an application experiences when running in the ADES on a platform.
 
 ## Description
 
-> Description to include:
-> 
-> * role in the architecture
-> * functional capabilities
-
-==THE CONTENT BELOW WAS WRITTEN FOR THE PDE AND NEEDS TO BE REPLACED BY A DESCRIPTION OF THE APPLICATION HUB. IT IS LEFT HERE IN CASE IT ACTS AS A USEFUL STARTING POINT...==
-
-The PDE comprises two main parts:
-
-* **JupyterHub Instance**<br>
-  Provides the multi-user entrypoint through which the user logs-in and from where their interactive environment is spawned.
-* **PDE Container**<br>
-  Provides the interactive environment, an instance of which is spawned for each authenticated user.
-
-### JupyterHub
-
-The entry-point to the PDE service is provided through an instance of [JupyterHub](https://jupyter.org/hub) - as described at [https://jupyterhub.readthedocs.io/en/stable/](https://jupyterhub.readthedocs.io/en/stable/).
-
-For EOEPCA, the PDE is designed for deployment to Kubernetes via the [PDE helm chart](https://github.com/EOEPCA/helm-charts/tree/main/charts/pde-jupyterhub), that is based upon the ['Zero to JupyterHub with Kubernetes'](https://zero-to-jupyterhub.readthedocs.io/en/latest/) distribution that is provided at [https://zero-to-jupyterhub.readthedocs.io/en/latest/](https://zero-to-jupyterhub.readthedocs.io/en/latest/).
-
-At the core of the distribution is the JupyterHub `jupyterhub/jupyterhub` container image - see DockerHub [https://hub.docker.com/r/jupyterhub/jupyterhub](https://hub.docker.com/r/jupyterhub/jupyterhub). In the `jupyterhub/jupyterhub` image, the JupyterHub service is configured via the file `/srv/jupyterhub/jupyterhub_config.py`.
+The Application Hub is a comprehensive and modular platform delivering SaaS products, designed to cater to the diverse and multifaceted needs of the EO community. It is crafted to support a wide array of stakeholders, from developers and service providers integrating cutting-edge algorithms to researchers harnessing computational power, and analysts requiring clear and concise visualizations. At the heart of the Application Hub is the ability to manage the delivery of work environments and tools for a wide range of user tasks, such as develop, host, execute, and perform exploratory analysis of EO applications, all managed within a single, unified Cloud infrastructure.
 
-JupyterHub spawns a service instance for each user that logs in to the hub. Instances can be spawned as containers using the `DockerSpawner` or `KubeSpawner`. In the case of EOEPCA the `KubeSpawner` is used. The spawner is configured via the `jupyterhub_config.py` file.
-
-Access to the spawned 'single-user servers' is proxied via the JupyterHub entry-point. Thus, all access to the hub and the associated user PDE sessions is made through the hub and its proxy.
-
-More details regarding the [JupyterHub architecture](https://jupyterhub.readthedocs.io/en/stable/reference/technical-overview.html) are available at [https://jupyterhub.readthedocs.io/en/stable/reference/technical-overview.html](https://jupyterhub.readthedocs.io/en/stable/reference/technical-overview.html).
-
-### PDE Container
-
-The PDE container is an implementation of the so-called 'single-user notbook servers' that are designed to be spawned by JupyterHub for each authenticated user. Typically these single-user-servers are based-upon a JupyterLab instance. For the PDE a base JupyterLab container is enriched to provide additional tooling - for example the Theia IDE.
+The Application Hub, leveraging Kubernetes and JupyterHub, creates a robust, scalable, and user-centric platform for Earth Observation (EO) applications and analytics. Kubernetes ensures scalable operation of containerized applications by managing deployment, operation, and traffic distribution, while JupyterHub orchestrates the launching, scaling, and management of application instances, acting as the primary gateway for user requests. The Hub uses dedicated namespaces for each application pod, ensuring organization, security, and isolation. It also dynamically configures application pods based on the task, and personalizes the experience based on user profiles through Kube Spawner. This design ensures the Application Hub remains modular, scalable, and capable of catering to the dynamic requirements of EO tasks.
 
+Typically, the Application Hub provides access to platforms and web apps in a Software-as-a-Service mode. Users can engage with containerized Interactive Graphical Applications (IGAs), specialized geospatial data exploration web apps, and customizable dashboards. This allows users not only to explore and analyze results but also to execute new applications or analyses and customize their computing experiences, all accessed from the same integrated Hub interface. Ultimately, this enhances user experience, optimizes software usage costs, and promotes ease of use, making it more accessible to the broader EO community.
 
 ## Interfaces
 
-> Specification of interfaces provided by the component.<br>
-> Link to external specifications if applicable.
-
-### JupyterHub Configuration
-
-The JupyterHub service is configured via the file `/srv/jupyterhub/jupyterhub_config.py`:
-
-* **Basics:** [https://jupyterhub.readthedocs.io/en/stable/getting-started/config-basics.html](https://jupyterhub.readthedocs.io/en/stable/getting-started/config-basics.html)
-* **Detailed:** [https://jupyterhub.readthedocs.io/en/stable/reference/](https://jupyterhub.readthedocs.io/en/stable/reference/)
-
-### PDE Container Configuration
-
-> TODO
+The ApplicationHub configuration is documented [https://eoepca.github.io/application-hub-context/](https://eoepca.github.io/application-hub-context/)
 
 ## Dependencies
 
-> Describe links with other eoepca components - e.g. interfaces consumed.
+The ApplicationHub can interact with other EOEPCA building blocks but has no dependencies.
 
 ## Additional Information
 
-> Include descriptions of anything that is relevant to help users of the component.<br>
-> Links to other relevant information.
+* Application-Hub-Context: 
+  * [Software Repository](https://github.com/EOEPCA/application-hub-context)
+  * [Documentation](https://eoepca.github.io/application-hub-context/)
+
+* Apps:
+  * [PDE with Code Server](https://github.com/EOEPCA/pde-code-server)
+  * [JupyterLab](https://github.com/EOEPCA/iat-jupyterlab)
+  * [Linux Remote Desktop](https://github.com/EOEPCA/iga-remote-desktop)
+  * [QGIS on Remote Desktop](https://github.com/EOEPCA/iga-remote-desktop-qgis)
+  * [SNAP on Remote Desktop](https://github.com/EOEPCA/iga-remote-desktop-snap)
+  * [STAC Browser](https://github.com/EOEPCA/iga-stac-browser)
+  * [Dashboard using Streamlit - demo](https://github.com/EOEPCA/iga-streamlit-demo)