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)".
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 backwend service until the routing proxy is up.
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
