aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject Re: [Discuss] Support zones for Aries RSA. Also related to cloud support
Date Wed, 21 Sep 2016 09:49:51 GMT
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.



> 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

View raw message