gCubeSystem
/
gcube-cms-suite
14
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Docs

This commit is contained in:
Fabio Sinibaldi 2022-11-21 20:51:21 +01:00
parent a7001b8100
commit 633cf8ee5c
1 changed files with 23 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
geoportal-service/docs/architecture.rst
View File

@ -7,19 +7,22 @@ Architecture
.. figure :: _static/imgs/architecture.png .. figure :: _static/imgs/architecture.png
:alt: CMS Suite overall concept :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 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 Client Library
************** **************