Christian Schneider commented on ARIES-1613:

I think this highly depends on the security constraints the company wants to 
enforce. The people responsible for security often like
to avoid connections that are initiated from the outside or dmz and have a 
target in the intranet. 

So I would rather place a second zookeeper server in the same zone as the 
webservers. The zookeeper server could then be fed from the internal network 
with the addresses of the proxy server aliases for the internal services. So 
the front end servers would not need any access to the intranet as they just 
need access to the external zookeeper and the proxy server. In this scenario 
only the http proxy would need access to the intranet and such a system can 
typically be nicely secured as it only provides a simple functionality.

The feeding mechanism could either be driven by the individual intranet servers 
that host the services or by a separate bridge software that only talks with 
the two zookeeper instances. I think it makes sense for us to at least design 
both scenarios. I personally do not currently plan to implement any scenario 
but maybe someone can jump in there.

For me the important part is that we provide the hooks in Aries RSA so such an 
implementation can be plugged in at any time.

> DiscoveryPlugin interface not exported
> --------------------------------------
>                 Key: ARIES-1613
>                 URL: https://issues.apache.org/jira/browse/ARIES-1613
>             Project: Aries
>          Issue Type: Bug
>          Components: Remote Service Admin
>    Affects Versions: rsa-1.9.0
>            Reporter: Panu Hämäläinen
> The package containing the interface 
> org.apache.cxf.dosgi.discovery.zookeeper.publish.DiscoveryPlugin is not 
> exported (MANIFEST.MF) from bundle cxf-dosgi-ri-discovery-distributed (1.7.0) 
> which makes it impossible to implement 3rd party discovery plugins.

This message was sent by Atlassian JIRA

Reply via email to