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.
Advertising
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 <ch...@die-schneider.net> wrote: > > I just had a discussion with Panu Hämäläinen about the DiscoveryPlugin > mechanism. > See https://issues.apache.org/jira/browse/ARIES-1613 and > https://issues.apache.org/jira/browse/ARIES-1614 . > > 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 > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
