GSIP 165 Add isolated workspaces concept to GeoServer
Proposal to add isolated workspaces concept to GeoServer. The main use case for this is to allow the publishing of the same complex feature type in different virtual services (i.e. different workspaces), this is particularity relevant when using App-Schema.
An isolated workspace will be able to reuse a namespace already used by another workspace, but is resources (layers, styles, etc ...) can only be retrieved when using that workspace virtual services and will only show up in those virtual services capabilities documents.
It is only possible to create two or more workspaces with the same namespace in GeoServer if only one of them is non isolated, i.e. isolated workspaces have no restrictions in namespaces usage but the existing restrictions still apply for non isolated workspaces.
The following situation will be valid:
- Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
- Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: true
- Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true
But this one will not be a valid one:
- Prefix: st1 Namespace: http://www.stations.org/1.0 Isolated: false
- Prefix: st2 Namespace: http://www.stations.org/1.0 Isolated: false
- Prefix: st3 Namespace: http://www.stations.org/1.0 Isolated: true
Only one non isolated workspace can use a certain namespace.
Consider the following image which shows to workspaces (st1 and st2) that use the same namespace (http://www.stations.org/1.0) and several layers contained by them:
In the example above st2 is the isolated workspace. Consider the following WFS GetFeature requests:
- http:///geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer2
- http:///geoserver/st2/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer2
- http:///geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st1:layer2
- http:///geoserver/st2/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st2:layer2
- http:///geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=st2:layer2
- http:///geoserver/ows?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=layer5
The first request is targeting WFS global service and requesting layer2, this request will use layer2 contained by workspace st1. The second request is targeting st2 workspace WFS virtual service, layer2 belonging to workspace st2 will be used. Request three and four will use layer2 belonging to workspace, respectively, st1 and st2. The last two requests will fail saying that the feature type was not found, isolated workspaces content is not visible globally.
The rule of thumb is that resources (layers, styles, etc ...) belonging to an isolated workspace can only be retrieved when using that workspaces virtual services and will only show up in those virtual services capabilities documents.
Nuno Oliveira
This proposal is for GeoServer 2.13.
- Setup
- Under Discussion
- In Progress
- Completed
- Rejected
- Deferred
Sometimes we need to map the same complex feature type (App-Schema) in a different way and publish it in different end points (virtual services), currently this can't be done. A complex feature type is associated with a specific namespace which have a one to one relationship with workspaces, hence the only way of publishing the same complex feature type multiple times is to use several GeoServer instances.
Is also worth mentioning that to be compliant with some INSPIRE themes the same complex feature type needs to be published more than once with different mappings, currently users need to have several GeoServer instances running to handle those INSPIRE themes requirements.
The code changes will be relatively isolated. Catalog workspaces and namespaces objects, WorkspaceInfo and NamespaceInfo respectively, will be extended with a boolean attribute specifying if they are isolated or not.
Catalog implementation CatalogImpl validation rule for workspaces and namespaces to take into account isolation, i.e. and isolated workspace has the right to reuse a namespace.
A small change will need to be done in DefaultCatalogFacade in method public NamespaceInfo getNamespaceByURI(String uri), basically we will need to ignore any isolated namespace and return only a non isolated one if available.
To avoid any backward compatibility issue a new interface named CatalogCapabilities will be created allowing catalogs and facades implementations to express the features they support, in this particular case if they support the storage and handling of isolated workspaces.
GeoServer web UI workspaces pages will also be extended, a check-box will allow users to mark an workspace as isolated.
Most of the business code will by implemented in a new catalog facade wrapper named IsolatedCatalogFacade, this will make the implementation code clean and focused and easy to plug \ unplug.
This proposal is fully backward compatible, users will not be affected by this unless they use this functionally and external code depending on GeoServer (third parts modules, etc ...) will not be affected by this either.
Project Steering Committee:
- Alessio Fabiani: +1
- Andrea Aime: +1
- Ben Caradoc-Davies: +1
- Brad Hards: +1
- Christian Mueller:
- Ian Turton: +1
- Jody Garnett: +1
- Jukka Rahkonen: +1
- Kevin Smith:
- Simone Giannecchini: +1