deegree workspace next generation (NG)

deegree's workspace concept introduced with line 3.x is based on a XML configuration files stored in a local file system. To add support for new environments a further development of the basics of deegree`s workspace concept is needed. This page covers the first ideas about this.

Known limitations of current workspace concept (deegree 3)

(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 reload of resources all 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 operated in parallel on a single Tomcat instance.
• configuration files can not be shared across multiple workspaces

Related issues:

• https://github.com/deegree/deegree3/issues/853
• https://github.com/deegree/deegree3/issues/982

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 deployments so that 1 webapp (1 container) can serve many services (>500 endpoints)
• automated scaling of services per dataset (microservices)
• raster data can be published via drop-in in an existing service configuration, no configuration of Store or TileMatrixSet etc. is required

Things to be kept

• structure of the configuration files
• possibility to use a data source (e.g. FeatureStore) in different services such as 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 (currently state is stored in local filesystem)
• be more micro by splitting deegree heavyweight deployment bundle into a more microservices like self-contained systems supporting technologies like docker, kubernetes
• support for other formats like YAML, JSON or sources such as a REST-API or databases, to store the configuration in a central scalable repository
• build a deegree Cloud Native infrastructure (deegreeCN)