aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [Discuss] Support zones for Aries RSA. Also related to cloud support
Date Thu, 22 Sep 2016 08:23:05 GMT
So lets think about a practical example. We want to expose a REST 
service that is visible to the inside via its direct url on the server 
that exposes the service and also via a proxy server where this service 
will have a different url.

So the server side topology manager would detect that the service is to 
be published. It would call the distribution provider to export the service.

The provider would then return two ExportRegistrations one for the 
direct access and one for the access over the proxy. They could each 
have a special property like "zone" to distinguish them (like "backend" 
and "frontend").

The TopologyManager on the front end client side then could be 
configured to only consider Endpoints that have (zone=frontend) for imports.

I think on the client I like this approach. It would also need only 
minimal additions to the TopologyManager code. We would either need a 
config setting for a import filter or a SPI where the user can supply 
custom filtering logic.

On the server side I am not so sure. The distribution provider would 
need to know about the proxy and it might even need to communicate with 
it to get the alias address for the service it exports. Another problem 
is that in such a scenario the server administrator would be able to 
poke new holes into the firewall.
On the positive side I agree that the DistributionProvider might know 
more about the details of the protocol to be qualified to create a 
suitable address than the TopologyManager.

Generally I think I would prefer a more central approach where you have 
a system that is part of the firewall that manages which services to 
expose to the outside world. Maybe this can also be done with Remote 
Service Admin.

How about this:


We use a system with two instances of the zookeeper discovery. One that 
communicates with the backend zookeeper and one that communicates with 
the frontend zookeeper.

The backend discovery would report all internal services to the 
TopologyManager. The TopologyManager would select the backend services 
for import using a special proxy DistributionProvider.

The proxy DistributionProvider would create an OSGi service with the 
necessary prorperties to be exported as a proxy for the frontend. The 
TopologyManager would detect this service and export it using the same 
proxy DistributionProvider which would create an ExportRegistration with 
the url of the proxy Endpoint it would also either implement an HTTP 
Proxy for the service or configure an external proxy server.

This approach might even be able to cover both cases the case where we 
have one zookeeper with all addresses and the case where we have 
spearate zookeepers for frontend and backend.

If I understand correctly then the Endpoint information for the proxy 
service would always be sent to all discovery providers, or can the 
TopologyManager select where to export it? If it can not then I think we 
would need a filtering config for the zookeeper discovery so the 
frontend zookeeper will only contain the frontend services and the 
backend zookeeper would only contain the backend services.

What do you think?


On 21.09.2016 11:49, Timothy Ward wrote:
> Hi Christian,
>  From an RSA perspective this is a Topology Management issue, not a discovery issue.
Services should be exposed by the Distribution Provider with multiple ExportRegistrations
(and hence multiple EndpointDescriptions), one for the “internal” URL and one for the
“proxied” URL The Topology Manager on the client side should then import the Endpoint
Description that gives the behaviour that it desires.
> Using multiple discovery services to do this sort of scoping is possible, but much more
complicated than controlling it using the Topology Manager. Adding a simple filter to the
client side’s Topology Manager’s EndpointEventListener would probably be sufficient, and
could be done easily using Config Admin.
> Regards,
> Tim
>> On 19 Sep 2016, at 13:52, Christian Schneider <> wrote:
>> I just had a discussion with Panu Hämäläinen about the DiscoveryPlugin mechanism.
>> See and
>> What he needs is to have two zones of services, a backend zone and a frontend zone.
>> The (or some) services in the backend will be published with http. Inside the backend
zone the services should be available using this http url.
>> In the frontend zone these services should also be visible but their url should point
to a proxy server that offer a https connection and potentially some additional security mechanisms.
>> So we can not simply have one (zookeeper or other) discovery view. Instead we need
a different discovery view for backend and frontend and some mechanism to make some services
from one zone available in the other while also applying some changes like pointing to a proxy.
>> Do you think it makes sense to support this case in Aries RSA in some way?
>> I thought we might also be able to interact with one of the existing proxy servers
to automatically register the proxy for each service. Such a mechanism is very typically for
cloud enabled architectures. So that might also bring us nearer to good cloud support.
>> I would be happy about any ideas and feedback.
>> Christian
>> -- 
>> Christian Schneider
>> Open Source Architect

Christian Schneider

Open Source Architect

View raw message