Skip to content

WorkspaceNG

tfr42 edited this page Feb 12, 2021 · 9 revisions

deegree workspace next generation (NG)

Motivation and Aims

  • 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

Things to be kept

  • Structure of the configuration files
  • Possibility to use a data source (e.g. FeatureStore) in several services WMS, WFS
  • REST interface for configuration

Long-term view: Support for cloud-native configuration style

  • 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 (state is stored in local filesystem)
  • be more micro by splitting deegree heavy weight deployment bundle into a more microservices like self-contained system using technologies like docker, kubernetes
  • support for other formats like YAML, JSON or sources such as a REST-API or databases shall be supported.

Known limitations of current workspace 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 (downtime)
  • 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 file can not be shared across multiple workspaces

Related issues:

Clone this wiki locally