Interesting
discussion.
But with dynamic
network discovery, it's possible that many services will be discovered
at runtime...from potentially many different clients/endpoints that
arrive/publish their services on the lan (or wan).
This creates the following dilemma for the client: which of the
potentially many remote services/endpoints that it discovers should it
actually respond to by creating a proxy and setting up that proxy in
the local service registry? Should it respond to all? (potentially
many...with a very significant runtime cost in terms of memory,
etc...and very suspect security). AFAICT, RFC 119 doesn't say
anything specific about this question/situation (please correct if I'm
out of date or not seeing relevant parts of spec).
RFC 119 talks about
properties (intents), which are meant to narrow down the list of
potential candidates based on service properties as well as QoS
attributes. It may very well depend on the DSW implementation whether a
discovered service can actually be made available via proxy.
In terms of our RFC
119 implementation this results in a policy question: which of the
services that are discovered should be responded to...automatically and
without user intervention? How do we allow the user to configure this
to their desires? How much, if anything, do we *require* the user to
do (and for which application contexts...e.g. Eclipse, RCP apps,
servers, etc) to allow/prevent strange things from happening in/on
networks. And how do we support this use case when (e.g.) multiple
r-osgi-based remote services (e.g.) are published and discovered?
Here is the strength
of the new spec. We want to encourage implementations to create proxies
on demand only. This is why DSW uses the ListenerHook (new in 4.2) to
be informed about the fact that there is an interested party looking
for a matching service. Taken the lookup service properties and the DSW
intents into account, the number of discovered services should be
reduced and not expanded.
So, the answer is
that we don't expect the DSW to create a proxy for every single service
discovered in the network. This is I think the 'global service
registry' approach that R-OSGi is taking, but in the EEG we discussed
and voted against it.
So, my question is
this: what do people feel is the right default 'policy' for
configuring a client so that it can/will discover 'appropriate' remote
services (but not 'inappropriate' ones?).
It is not so much
about policies as a matter of defining QoS attributes.
Tim.
"There is never enough time
to do it right, but there is always enough time to do it over"
-- Murphy's Law