Hi On 14 Jan 2015, at 08:23, Christian Schneider <[email protected]> wrote:
> How about using a special property for the routing proxy? Publish it with the > same interface as the backend services but give it a service property like > proxy=true. > Then in the front end you can filter for a service with filter=“(proxy=true)". Also, if your service client is a DS component then these filters can be dynamically added/changed/removed using Configuration Admin. > > Another option is to set the priority of the routing proxy higher than the > backend services. So the frontend will always bind to it when it is present. > This might be a bit unreliable on startup as the frontend would then > bind to a backbend service until the routing proxy is up. This would also fail unless the client eagerly rebinds to the highest ranked service when a new one becomes available. This is not the default behaviour for DS or blueprint. > > Christian > > > > On 14.01.2015 01:26, Ancoron Luciferis wrote: >> On 01/12/2015 11:54 AM, Peter Kriens wrote: >>> So I am a bit confused what you want? The example seems to explain how you >>> handle different backends in OSGi from a single REST API. If you want to >>> support /rest/backends/:name API’s, then the mechanics in this model should >>> be perfectly clear. Obviuosly I did not show how to hide the backend >>> because I’ve no idea what kind of policies you want to use, that is right >>> in your domain and not depending on OSGi. Therefore, from the given example >>> it should be clear where to place that functionality in a proper service >>> oriented way. The purpose of the example is to highlight how to architect >>> an OSGi system properly. >>> >>> So do you still have questions how to do backends with OSGi design or are >>> we now discussing communication protocol issues? If the latter is the case >>> I think this list is out of scope? >>> >>> Kind regards, >>> >>> Peter Kriens >>> >>> >> Hi Peter, >> >> good questions. I totally agree with you that the example application >> you made up nicely shows the use of different services being combined >> into a single ReST API. >> >> Now, I know how to do the things I want to do programmatically in >> application-level code. That's not my issue. My main issue is that I >> want to make the presentation layer (the ReST application in your >> example) agnostic of the presence of multiple backends. Only the >> "routing" should actually know that there are multiple implementations >> of the same service. >> >> That's why I was referring to the FindHook earlier in the thread, which >> is the only mechanism currently known to me that allows one to hide >> services from consumers. However, this has the drawback, that consumers >> need to be refreshed once the FindHook gets installed and I didn't find >> any place I could "intercept" service registration to not expose the >> services to bundles other than the one providing the "routing" proxy >> service. >> >> Thinking about it, I probably could make use of a ServiceFactory to >> always return the routing DataService proxy. That way, any consumer >> would only get the proxy... hm... have to try that... >> >> ...thanx for the indirect pointer! :) >> >> >> Cheers, >> >> Ancoron >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
