[Fwd: Re: [ecf-dev] network discovery and distribution questions related

[Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>]

See below for comments about my questions from Tim Diekmann

<tim>

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