From 633cf8ee5c468595746c9408307ed13f7c4a76c6 Mon Sep 17 00:00:00 2001 From: Fabio Sinibaldi Date: Mon, 21 Nov 2022 20:51:21 +0100 Subject: [PATCH] Docs --- geoportal-service/docs/architecture.rst | 30 +++++++++++++++++++------ 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/geoportal-service/docs/architecture.rst b/geoportal-service/docs/architecture.rst index 02997b4..928b9d4 100644 --- a/geoportal-service/docs/architecture.rst +++ b/geoportal-service/docs/architecture.rst @@ -7,19 +7,22 @@ Architecture .. figure :: _static/imgs/architecture.png :alt: CMS Suite overall concept - gCube CMS suite : General Architecture +gCube CMS suite : General Architecture - The conceptual architecture behind gCube CMS Suite is schematized in the figure above. +The conceptual architecture behind gCube CMS Suite is schematized in the figure above. - Here we describe the rationale behind the architecture : +Here we describe the rationale behind the architecture : - * Clients perform both CRUD and Query operations against the service both via using the client library or by directly interacting with the service REST interface. +* Clients perform both CRUD and Query operations against the service both via using the client library or by directly interacting with the service REST interface. +* They interact with the service producing the custom metadata document (stored in a Document Store DB) and registering related Filesets (stored in gCube StorageHub). +* Clients sends steps (pre configured in the collection UCD) requests to the service, which in turn delegate Lifecycle operations to configured implementations. +* Clients may also directly consume materialized projects in ad hoc engines (e.g. SDI or DBMS). For this purpose, the service exposes information needed by the client in order to properly consume the project collection. - * They interact with the service producing the custom metadata document (stored in a Document Store DB) and registering related Filesets (stored in gCube StorageHub). - * Clients sends steps (pre configured in the collection UCD) requests to the service, which in turn delegate Lifecycle operations to configured implementations. +In the figure below we further illustrate the various components involved in the typical execution of Projects' lifecycle - * Clients may also directly consume materialized projects in ad hoc engines (e.g. SDI or DBMS). For this purpose, the service exposes information needed by the client in order to properly consume the project collection. +.. figure :: _static/imgs/execution_schema.png + :alt: Step execution @@ -292,7 +295,20 @@ Following diagram shows the interfaces defined in the framework (package *org.gc Plugin Development support ========================== +In order to facilitate the development of plugins, the following solutions may be of use to the developer : + +* extension of an already provided LifecycleManager in order to override default behaviour (e.g. as per *Concessioni* UCD, see suite module concessioni-lifecycle) + +* extension of *org.gcube.application.cms.plugins.implementations.AbstractPlugin* class in order to leverage on common behaiovur (e.g. configuration management, error handling) + +* extension of *org.gcube.application.cms.caches.AbstractScopedMap* or *org.gcube.application.cms.caches.TimedMap* for easy implementation of caches (respectively by context and global) + +* leverage on module *cms-test-commons* for exploitation of context management, basic plugin testing (both static and in a gCube context) + ************** Client Library ************** + + +