forked from deegree/deegree3
-
Notifications
You must be signed in to change notification settings - Fork 2
WorkspaceNG
tfr42 edited this page Aug 17, 2021
·
9 revisions
- Exchanging or adding resources such as a raster file shall not require a complete workspace reload and the resource shall be available immediately (within milliseconds)
- simplify / strengthen of deployment so that 1 webapp (1 container) can serve many services (>500 endpoints)
- automated scaling of services per dataset (microservices)
- Raster data can be provided via drop-in in an existing service, no configuration of Store and TileMatrixSet etc. is required for GeoTIFF files
- Structure of the configuration files
- Possibility to use a data source (e.g. FeatureStore) in different services such asWMS, WFS
- REST interface for configuration
- be more explicit in the configuration, example would be concepts introduced by Cloud Foundry
- be more stateless by getting environment specific information from the environment and not from the deegree workspace (currently state is stored in local filesystem)
- be more micro by splitting deegree heavy weight deployment bundle into a more microservices like self-contained systems using technologies like docker, kubernetes
- support for other formats like YAML, JSON or sources such as a REST-API or databases shall be supported (to store the configuration in a central scalable repository)
- build a deegree Cloud Native infrastructure (deegreeCN)
(see workspace for more information about the current concept).
From the requirements that result from the new OGC API Specs (RESTfull) such as OGC API - features, a fundamental renewal / extension of the deegree workspace concept is necessary. The deegree workspace currently has the following shortcomings:
- A workspace reload can take a very long time if there are many configuration files in the workspace (>100 files, the duration of a reload takes several seconds)
- During the reload of resources, other resources (such as services) are not available (offline)
- the workspace concept is too deeply interwoven with the deegree core (refactoring required)
- 1 workspace is coupled with 1 webapp and therefore several webapps (50+ MB) must be deployed if several workspace configurations are to be operated in parallel on one Tomcat instance.
- configuration files can not be shared across multiple workspaces
Related issues: