[Geoserver-devel] Isolated Workspaces

Hi all,

A few months ago I started a thread [1] about allowing the definition of several workspaces with the same namespace in GeoServer.
The main (root) use case for this is to allow the publishing of the same complex feature type in GeoServer multiple times in different
workspaces. I finally had time to restart this work and can now give a more concrete answers to some of the comments.

The workspace and namespaces relationship boils down to how things are grouped together and stored in GeoServer catalog and the
ability to retrieve them. Let’s say that we have an arbitrary resource in GeoServer (layer, style, feature type, etc …), that resource
can be retrieved like this:

  1. getResourceByName(“layer1”, ResourceType.class)
  2. getResourceByName(“workspace:layer1”, ResourceType.class)
  3. getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)
    The three ways above (there is more ways of doing this) are all valid ways of referencing the same resource. The workspace name
    and the workspace namespace are used interchangeably, this works fine because there is a one to one relationship between them.
    Some business code tend to use the workspace name, and other code like WFS tend to use the namespace to reference a catalog
    resource.

The concept of isolated workspaces (or namespaces) allow us to define multiple workspaces with the same namespaces. The
resources of an isolated workspace can only be accessed in the context of the virtual service of that workspace. Consider that
we have two workspaces with the same namespace:

  1. Prefix: ws1, URI: http://www.gs.com, Isolated: false
  2. Prefix: ws2, URI: http://www.gs.com, Isolated: true
    And consider also that both workspaces have a feature type name complex_feature. In the catalog point of view all this invocations
    will return the feature_type belonging to first workspace:
  • getResourceByName(“complex_feature”, FeatureType.class)
  • getResourceByName(“ws1:complex_feature”, FeatureType.class)
  • getResourceByName(“{http://www.gs.com}:complex_feature”, FeatureType.class)

Only this invocation will retrieve the feature type belonging to the isolated workspace (second one):

  • getResourceByName(“ws2:complex_feature”, FeatureType.class)
    If a resource is identified by its namespace URI the catalog will never be able to find that resource if it belongs to an isolated
    workspace, since the same namespace may be used by another workspace. That’s why we can only retrieve the content of an
    isolated workspace from is virtual service, because if we are in the context of a certain virtual service we can automatically
    convert the namespace URI in a specific workspace name \ prefix.

The catalog machinery is quite complex [1] with several wrappers and different catalog facades. To support workspaces isolation
we had to bring the concept of workspace isolation to the catalog facade implementations and implement the necessary handling
in the local catalog wrapper.

The changes in the facade are really simple, only one line of code was changed in DefaultCatalogFacadeImpl, we just need to make
sure that when we search a NameSpaceInfo by its URI namespaces that are tied to an isolated workspace are ignored. The issue is that
if a particular catalog facade implementation doesn’t do this change isolated workspaces are not correctly supported.

To avoid backward compatibility issues I introduced the concept of CatalogCapabilities (similar to Query capabilities in GeoTools), unless
a catalog facade or catalog implementation says explicitly that isolated workspaces are supported this functionality will be disabled. This
can be reused to support the introduction of new catalog features and avoiding breaking existing implementations.

The changes to support isolated workspaces are isolated int he catalog machinery and transparent to all the other business code. This
is backward compatible and will not break existing implementations, of curse if someone is using its own catalog facade implementation
isolated workspace will be disabled unless they implement the required business code.

I have made some preliminary tests with WMS and WFS operations and everything seems to be working as expected.

I hope this clarifies some of the doubts \ questions that were asked before.

Cheers,

[1] http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html
[2] https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing

···
-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Thanks Nuno, sorry we were a bit overrun when you emailed.

I had some questions in today’s meeting, mostly around the relationship with global workspace. Andrea was able to clarify the user story, and that makes sense to me.
Is there any reason to make this a separate setting? Would “turning off” global be enough to enable this functionality?

I am not too sure about CatalogCapabilities, I understand that the it is a common design we use to allow implementations to negotiate what functionality they support. It always makes me uncomfortable, breaking encapsulation and forcing the use of conditional code. Is there a possibility of better defining a method to avoid introducing this new class?

···

On 31 October 2017 at 02:29, Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

Hi all,

A few months ago I started a thread [1] about allowing the definition of several workspaces with the same namespace in GeoServer.
The main (root) use case for this is to allow the publishing of the same complex feature type in GeoServer multiple times in different
workspaces. I finally had time to restart this work and can now give a more concrete answers to some of the comments.

The workspace and namespaces relationship boils down to how things are grouped together and stored in GeoServer catalog and the
ability to retrieve them. Let’s say that we have an arbitrary resource in GeoServer (layer, style, feature type, etc …), that resource
can be retrieved like this:

  1. getResourceByName(“layer1”, ResourceType.class)
  2. getResourceByName(“workspace:layer1”, ResourceType.class)
  3. getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)
    The three ways above (there is more ways of doing this) are all valid ways of referencing the same resource. The workspace name
    and the workspace namespace are used interchangeably, this works fine because there is a one to one relationship between them.
    Some business code tend to use the workspace name, and other code like WFS tend to use the namespace to reference a catalog
    resource.

The concept of isolated workspaces (or namespaces) allow us to define multiple workspaces with the same namespaces. The
resources of an isolated workspace can only be accessed in the context of the virtual service of that workspace. Consider that
we have two workspaces with the same namespace:

  1. Prefix: ws1, URI: http://www.gs.com, Isolated: false
  2. Prefix: ws2, URI: http://www.gs.com, Isolated: true
    And consider also that both workspaces have a feature type name complex_feature. In the catalog point of view all this invocations
    will return the feature_type belonging to first workspace:
  • getResourceByName(“complex_feature”, FeatureType.class)
  • getResourceByName(“ws1:complex_feature”, FeatureType.class)
  • getResourceByName(“{http://www.gs.com}:complex_feature”, FeatureType.class)

Only this invocation will retrieve the feature type belonging to the isolated workspace (second one):

  • getResourceByName(“ws2:complex_feature”, FeatureType.class)
    If a resource is identified by its namespace URI the catalog will never be able to find that resource if it belongs to an isolated
    workspace, since the same namespace may be used by another workspace. That’s why we can only retrieve the content of an
    isolated workspace from is virtual service, because if we are in the context of a certain virtual service we can automatically
    convert the namespace URI in a specific workspace name \ prefix.

The catalog machinery is quite complex [1] with several wrappers and different catalog facades. To support workspaces isolation
we had to bring the concept of workspace isolation to the catalog facade implementations and implement the necessary handling
in the local catalog wrapper.

The changes in the facade are really simple, only one line of code was changed in DefaultCatalogFacadeImpl, we just need to make
sure that when we search a NameSpaceInfo by its URI namespaces that are tied to an isolated workspace are ignored. The issue is that
if a particular catalog facade implementation doesn’t do this change isolated workspaces are not correctly supported.

To avoid backward compatibility issues I introduced the concept of CatalogCapabilities (similar to Query capabilities in GeoTools), unless
a catalog facade or catalog implementation says explicitly that isolated workspaces are supported this functionality will be disabled. This
can be reused to support the introduction of new catalog features and avoiding breaking existing implementations.

The changes to support isolated workspaces are isolated int he catalog machinery and transparent to all the other business code. This
is backward compatible and will not break existing implementations, of curse if someone is using its own catalog facade implementation
isolated workspace will be disabled unless they implement the required business code.

I have made some preliminary tests with WMS and WFS operations and everything seems to be working as expected.

I hope this clarifies some of the doubts \ questions that were asked before.

Cheers,

[1] http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html
[2] https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

Hello Nuno,

For the most part, the functionality described seems like a feasible addition.

I do have a few questions about implementation:

  1. What sort of configuration object(s) will these isolated workspaces be? NamespaceInfo + WorkspaceInfo, or something different?

  2. How is an isolated workspace defined? Or in other words, what distinguishes an isolated workspace from a regular workspace?

  3. How is an isolated workspace identified in the UI? In the REST API?

And some questions about edge-cases:

  1. How does the WMS with a virtual workspace works with isolated works

  2. What happens if you try to set an isolated workspace as the default workspace?

  3. Assuming you have a regular workspace and an isolated workspace with the same namespace, if you delete the regular workspace what happens to the isolated workspace? Is it still an isolated workspace?

Torben

···

On Tue, Nov 14, 2017 at 10:44 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks Nuno, sorry we were a bit overrun when you emailed.

I had some questions in today’s meeting, mostly around the relationship with global workspace. Andrea was able to clarify the user story, and that makes sense to me.
Is there any reason to make this a separate setting? Would “turning off” global be enough to enable this functionality?

I am not too sure about CatalogCapabilities, I understand that the it is a common design we use to allow implementations to negotiate what functionality they support. It always makes me uncomfortable, breaking encapsulation and forcing the use of conditional code. Is there a possibility of better defining a method to avoid introducing this new class?


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

On 31 October 2017 at 02:29, Nuno Oliveira <nuno.oliveira@anonymised.comit> wrote:

Hi all,

A few months ago I started a thread [1] about allowing the definition of several workspaces with the same namespace in GeoServer.
The main (root) use case for this is to allow the publishing of the same complex feature type in GeoServer multiple times in different
workspaces. I finally had time to restart this work and can now give a more concrete answers to some of the comments.

The workspace and namespaces relationship boils down to how things are grouped together and stored in GeoServer catalog and the
ability to retrieve them. Let’s say that we have an arbitrary resource in GeoServer (layer, style, feature type, etc …), that resource
can be retrieved like this:

  1. getResourceByName(“layer1”, ResourceType.class)
  2. getResourceByName(“workspace:layer1”, ResourceType.class)
  3. getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)
    The three ways above (there is more ways of doing this) are all valid ways of referencing the same resource. The workspace name
    and the workspace namespace are used interchangeably, this works fine because there is a one to one relationship between them.
    Some business code tend to use the workspace name, and other code like WFS tend to use the namespace to reference a catalog
    resource.

The concept of isolated workspaces (or namespaces) allow us to define multiple workspaces with the same namespaces. The
resources of an isolated workspace can only be accessed in the context of the virtual service of that workspace. Consider that
we have two workspaces with the same namespace:

  1. Prefix: ws1, URI: http://www.gs.com, Isolated: false
  2. Prefix: ws2, URI: http://www.gs.com, Isolated: true
    And consider also that both workspaces have a feature type name complex_feature. In the catalog point of view all this invocations
    will return the feature_type belonging to first workspace:
  • getResourceByName(“complex_feature”, FeatureType.class)
  • getResourceByName(“ws1:complex_feature”, FeatureType.class)
  • getResourceByName(“{http://www.gs.com}:complex_feature”, FeatureType.class)

Only this invocation will retrieve the feature type belonging to the isolated workspace (second one):

  • getResourceByName(“ws2:complex_feature”, FeatureType.class)
    If a resource is identified by its namespace URI the catalog will never be able to find that resource if it belongs to an isolated
    workspace, since the same namespace may be used by another workspace. That’s why we can only retrieve the content of an
    isolated workspace from is virtual service, because if we are in the context of a certain virtual service we can automatically
    convert the namespace URI in a specific workspace name \ prefix.

The catalog machinery is quite complex [1] with several wrappers and different catalog facades. To support workspaces isolation
we had to bring the concept of workspace isolation to the catalog facade implementations and implement the necessary handling
in the local catalog wrapper.

The changes in the facade are really simple, only one line of code was changed in DefaultCatalogFacadeImpl, we just need to make
sure that when we search a NameSpaceInfo by its URI namespaces that are tied to an isolated workspace are ignored. The issue is that
if a particular catalog facade implementation doesn’t do this change isolated workspaces are not correctly supported.

To avoid backward compatibility issues I introduced the concept of CatalogCapabilities (similar to Query capabilities in GeoTools), unless
a catalog facade or catalog implementation says explicitly that isolated workspaces are supported this functionality will be disabled. This
can be reused to support the introduction of new catalog features and avoiding breaking existing implementations.

The changes to support isolated workspaces are isolated int he catalog machinery and transparent to all the other business code. This
is backward compatible and will not break existing implementations, of curse if someone is using its own catalog facade implementation
isolated workspace will be disabled unless they implement the required business code.

I have made some preliminary tests with WMS and WFS operations and everything seems to be working as expected.

I hope this clarifies some of the doubts \ questions that were asked before.

Cheers,

[1] http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html
[2] https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi Jody,
thanks for the feedback, please find my answers bellow:

No worries. This is unrelated to global workspaces. When publishing a complex feature type it needs to be published (for several reasons) in a workspace that has the same namespace of the root feature type. This means that to publish the same complex feature type multiple times we need to have several workspaces with different prefix but the same namespace. Catalog related code is already capable of storying multiple namespaces as long as they have a different prefix. The problem is that the catalog allow us to query things based solely on the namespace as a grouping concept, creating a relation ship of one to one between an workspace prefix and the associated namespace. So isolated workspaces brings the ability to handle catalog requests of the sort when multiple workspace may have the same namespace, consider the following request: We are requesting that belongs to workspace associated to . If we have two workspaces with the same namespace both with a layer named layer1 which one should be choose ? This is were the limitation of the one to one relationship between workpsaces and namespaces comes from. The goal of isolated workspaces is to remove this limitation by: Well I couldn’t find a better alternative and I’m open to suggestions, what happens right now is that:

···

On 11/15/2017 06:44 AM, Jody Garnett wrote:

Thanks Nuno, sorry we were a bit overrun when you emailed.

I had some questions in today’s meeting, mostly around the relationship with global workspace. Andrea was able to clarify the user story, and that makes sense to me.
Is there any reason to make this a separate setting? Would “turning off” global be enough to enable this functionality?

de facto

getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)

layer1**namespace http:\www.workspace.com

  1. between non isolated workspaces a namespace must be unique

  2. no restrictions applied to isolated workspaces regarding namespaces multiplicity

  3. when a requested using the namespace as the grouping concept hits the catalog

  4. if we are in the context of the global service then we go for the non isolated workspace associated with the provided namespace, if no such workspace exists then no resource is found

  5. if we are int he context of an isolated workspace whose namespace matches the desired namespace, then we substitute the namespace grouping concept by the local workspace prefix

I am not too sure about CatalogCapabilities, I understand that the it is a common design we use to allow implementations to negotiate what functionality they support. It always makes me uncomfortable, breaking encapsulation and forcing the use of conditional code. Is there a possibility of better defining a method to avoid introducing this new class?

  1. The DefaultCatalogFacade is perfectly able of storing and using the same namespace with different prefix as a storing concept.
  2. When retrieving a NameSpaceInfo object by the namespace URI isolated namespaces need to be ignored, otherwise we will just get some random NamespaceInfo object each time

For a catalog facade to support isolated workspaces the two points above need to be respected. Unfortunately this requirements are on the implementation and not on the API.


Jody Garnett

On 31 October 2017 at 02:29, Nuno Oliveira <nuno.oliveira@anonymised.com> wrote:

Hi all,

A few months ago I started a thread [1] about allowing the definition of several workspaces with the same namespace in GeoServer.
The main (root) use case for this is to allow the publishing of the same complex feature type in GeoServer multiple times in different
workspaces. I finally had time to restart this work and can now give a more concrete answers to some of the comments.

The workspace and namespaces relationship boils down to how things are grouped together and stored in GeoServer catalog and the
ability to retrieve them. Let’s say that we have an arbitrary resource in GeoServer (layer, style, feature type, etc …), that resource
can be retrieved like this:

  1. getResourceByName(“layer1”, ResourceType.class)
  2. getResourceByName(“workspace:layer1”, ResourceType.class)
  3. getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)
    The three ways above (there is more ways of doing this) are all valid ways of referencing the same resource. The workspace name
    and the workspace namespace are used interchangeably, this works fine because there is a one to one relationship between them.
    Some business code tend to use the workspace name, and other code like WFS tend to use the namespace to reference a catalog
    resource.

The concept of isolated workspaces (or namespaces) allow us to define multiple workspaces with the same namespaces. The
resources of an isolated workspace can only be accessed in the context of the virtual service of that workspace. Consider that
we have two workspaces with the same namespace:

  1. Prefix: ws1, URI: http://www.gs.com, Isolated: false
  2. Prefix: ws2, URI: http://www.gs.com, Isolated: true
    And consider also that both workspaces have a feature type name complex_feature. In the catalog point of view all this invocations
    will return the feature_type belonging to first workspace:
  • getResourceByName(“complex_feature”, FeatureType.class)
  • getResourceByName(“ws1:complex_feature”, FeatureType.class)
  • getResourceByName(“{http://www.gs.com}:complex_feature”, FeatureType.class)

Only this invocation will retrieve the feature type belonging to the isolated workspace (second one):

  • getResourceByName(“ws2:complex_feature”, FeatureType.class)
    If a resource is identified by its namespace URI the catalog will never be able to find that resource if it belongs to an isolated
    workspace, since the same namespace may be used by another workspace. That’s why we can only retrieve the content of an
    isolated workspace from is virtual service, because if we are in the context of a certain virtual service we can automatically
    convert the namespace URI in a specific workspace name \ prefix.

The catalog machinery is quite complex [1] with several wrappers and different catalog facades. To support workspaces isolation
we had to bring the concept of workspace isolation to the catalog facade implementations and implement the necessary handling
in the local catalog wrapper.

The changes in the facade are really simple, only one line of code was changed in DefaultCatalogFacadeImpl, we just need to make
sure that when we search a NameSpaceInfo by its URI namespaces that are tied to an isolated workspace are ignored. The issue is that
if a particular catalog facade implementation doesn’t do this change isolated workspaces are not correctly supported.

To avoid backward compatibility issues I introduced the concept of CatalogCapabilities (similar to Query capabilities in GeoTools), unless
a catalog facade or catalog implementation says explicitly that isolated workspaces are supported this functionality will be disabled. This
can be reused to support the introduction of new catalog features and avoiding breaking existing implementations.

The changes to support isolated workspaces are isolated int he catalog machinery and transparent to all the other business code. This
is backward compatible and will not break existing implementations, of curse if someone is using its own catalog facade implementation
isolated workspace will be disabled unless they implement the required business code.

I have made some preliminary tests with WMS and WFS operations and everything seems to be working as expected.

I hope this clarifies some of the doubts \ questions that were asked before.

Cheers,

[1] http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html
[2] https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

Hi Torben,
thanks for the feedback, please read my answers bellow:

A boolean attribute will be added in both NamespaceInfo and WorkspaceInfo saying if they are isolated or not. I know this looks strange both keep in mind that the relationship between this two object is merely functional. When we create an Workspace in web UI two objects are created in the catalog a NamespaceInfo and a WorkspaceInfo and they kind of live separate “lives” … only when we need to remove one of them there is a piece of code that takes in consideration this relationship. Please see my answer to Jody for more details, but the short answer is in the case of request of the sort: If there is two workspaces with the same namespace (one of them isolated) and both contained layer1: Then when creating an workspace we will basically check a box saying if the created workspace is isolated or not [1]. [1] In the REST API it will be a new boolean attribute. In the UI a new column identifying isolated workspaces will be added to workspaces UI [2]. [2] Same as WFS, this is more a catalog behavior rather than specific service one. Nothing it will just become the default workspace. Yes. The only rule is that there can only be at most one non-isolated isolated workspace for a certain workspace. Of course in the situation you describe the user will then be free to mark the isolated workspace a non isolated one. Thanks for this questions Torben, I hope my answers will help clarify this isolated workspace concept. Cheers, Nuno Oliveira

···

On 11/15/2017 06:30 PM, Torben Barsballe wrote:

Hello Nuno,

For the most part, the functionality described seems like a feasible addition.

I do have a few questions about implementation:

  1. What sort of configuration object(s) will these isolated workspaces be? NamespaceInfo + WorkspaceInfo, or something different?
  1. How is an isolated workspace defined? Or in other words, what distinguishes an isolated workspace from a regular workspace?

getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)

http:\www.workspace.com

  • when targeting a global service the non isolated layer1 will be returned
  • when targeting an isolated workspace virtual service the layer1 from the isolated workspace will be returned

https://drive.google.com/file/d/1CfRoCG2zexG6ThCQ1KDFP1CTgYzPJjoX/view?usp=sharing

  1. How is an isolated workspace identified in the UI? In the REST API?

https://drive.google.com/file/d/1We-o8zxOVecByIJcn_GJsY6wTSvGIdCF/view?usp=sharing

And some questions about edge-cases:

  1. How does the WMS with a virtual workspace works with isolated works
  1. What happens if you try to set an isolated workspace as the default workspace?
  1. Assuming you have a regular workspace and an isolated workspace with the same namespace, if you delete the regular workspace what happens to the isolated workspace? Is it still an isolated workspace?

Torben

On Tue, Nov 14, 2017 at 10:44 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Thanks Nuno, sorry we were a bit overrun when you emailed.

I had some questions in today’s meeting, mostly around the relationship with global workspace. Andrea was able to clarify the user story, and that makes sense to me.
Is there any reason to make this a separate setting? Would “turning off” global be enough to enable this functionality?

I am not too sure about CatalogCapabilities, I understand that the it is a common design we use to allow implementations to negotiate what functionality they support. It always makes me uncomfortable, breaking encapsulation and forcing the use of conditional code. Is there a possibility of better defining a method to avoid introducing this new class?


Jody Garnett

On 31 October 2017 at 02:29, Nuno Oliveira <nuno.oliveira@anonymised.comit> wrote:

Hi all,

A few months ago I started a thread [1] about allowing the definition of several workspaces with the same namespace in GeoServer.
The main (root) use case for this is to allow the publishing of the same complex feature type in GeoServer multiple times in different
workspaces. I finally had time to restart this work and can now give a more concrete answers to some of the comments.

The workspace and namespaces relationship boils down to how things are grouped together and stored in GeoServer catalog and the
ability to retrieve them. Let’s say that we have an arbitrary resource in GeoServer (layer, style, feature type, etc …), that resource
can be retrieved like this:

  1. getResourceByName(“layer1”, ResourceType.class)
  2. getResourceByName(“workspace:layer1”, ResourceType.class)
  3. getResourceByName(“{http:\www.workspace.com}:layer1”, ResourceType.class)
    The three ways above (there is more ways of doing this) are all valid ways of referencing the same resource. The workspace name
    and the workspace namespace are used interchangeably, this works fine because there is a one to one relationship between them.
    Some business code tend to use the workspace name, and other code like WFS tend to use the namespace to reference a catalog
    resource.

The concept of isolated workspaces (or namespaces) allow us to define multiple workspaces with the same namespaces. The
resources of an isolated workspace can only be accessed in the context of the virtual service of that workspace. Consider that
we have two workspaces with the same namespace:

  1. Prefix: ws1, URI: http://www.gs.com, Isolated: false
  2. Prefix: ws2, URI: http://www.gs.com, Isolated: true
    And consider also that both workspaces have a feature type name complex_feature. In the catalog point of view all this invocations
    will return the feature_type belonging to first workspace:
  • getResourceByName(“complex_feature”, FeatureType.class)
  • getResourceByName(“ws1:complex_feature”, FeatureType.class)
  • getResourceByName(“{http://www.gs.com}:complex_feature”, FeatureType.class)

Only this invocation will retrieve the feature type belonging to the isolated workspace (second one):

  • getResourceByName(“ws2:complex_feature”, FeatureType.class)
    If a resource is identified by its namespace URI the catalog will never be able to find that resource if it belongs to an isolated
    workspace, since the same namespace may be used by another workspace. That’s why we can only retrieve the content of an
    isolated workspace from is virtual service, because if we are in the context of a certain virtual service we can automatically
    convert the namespace URI in a specific workspace name \ prefix.

The catalog machinery is quite complex [1] with several wrappers and different catalog facades. To support workspaces isolation
we had to bring the concept of workspace isolation to the catalog facade implementations and implement the necessary handling
in the local catalog wrapper.

The changes in the facade are really simple, only one line of code was changed in DefaultCatalogFacadeImpl, we just need to make
sure that when we search a NameSpaceInfo by its URI namespaces that are tied to an isolated workspace are ignored. The issue is that
if a particular catalog facade implementation doesn’t do this change isolated workspaces are not correctly supported.

To avoid backward compatibility issues I introduced the concept of CatalogCapabilities (similar to Query capabilities in GeoTools), unless
a catalog facade or catalog implementation says explicitly that isolated workspaces are supported this functionality will be disabled. This
can be reused to support the introduction of new catalog features and avoiding breaking existing implementations.

The changes to support isolated workspaces are isolated int he catalog machinery and transparent to all the other business code. This
is backward compatible and will not break existing implementations, of curse if someone is using its own catalog facade implementation
isolated workspace will be disabled unless they implement the required business code.

I have made some preliminary tests with WMS and WFS operations and everything seems to be working as expected.

I hope this clarifies some of the doubts \ questions that were asked before.

Cheers,

[1] http://osgeo-org.1560.x6.nabble.com/Allowing-multiple-workspaces-to-use-the-same-name-space-URI-td5307302.html
[2] https://docs.google.com/drawings/d/1AvCBi4yyJQ60cCKcxSJkThom0tT9Epna8-mL31zS7Mo/edit?usp=sharing

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-- 
Regards,
Nuno Oliveira
==
GeoServer Professional Services from the experts! Visit [http://goo.gl/it488V](http://goo.gl/it488V) for more information.
==

Nuno Miguel Carvalho Oliveira
@nmcoliveira
Software Engineer

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax:      +39 0584 1660272

[http://www.geo-solutions.it](http://www.geo-solutions.it)
[http://twitter.com/geosolutions_it](http://twitter.com/geosolutions_it)

-------------------------------------------------------
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
 
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility  for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.