|Re: [ecf-dev] network discovery and distribution questions related to RFC 119 impl|
The OSGI EE RFC 119 has two major sub-components to it: 1) discovery; and 2) distribution.
Discovery is responsible for publishing and responding to remote services, and distribution is responsible for creating proxies, marshalling/unmarshalling params/return values from remote calls, and cleaning up after proxies, etc.
With static discovery (e.g. file-based discovery), the client 'knows' in advance what services are out there (and their endpoints). This information is read from a file upon framework startup.
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).
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?
I believe that in the ECF tutorial at EclipseCon, this use case (multiple remote services being published...all based upon r-osgi) resulted in clients that automatically tried to use one client's services, but then tried to use another (when discovered)...and when the application attempted to use the proxy from the first service it failed (because the r-osgi peer had already/automatically 'moved on' to some other client's remote service).
Note that in most demos, examples, etc of RFC 119 this policy decision is not an issue/question...because
a) Usually there is only one remote service/host...so there's no question about how to handle many.
b) Static discovery guarantees that the client will be 'ready' for what is discovered.
But with ECF's discovery API (yay!) we have support for discovery based upon SLP, zeroconf, as well as file-based/static discovery (sincere thanks to Siemens and Markus K). So as soon as people start deploying remote services based upon ECF's impl of RFC 119 they will run into this question/issue....as I believe we did at EclipseCon :).
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?). One thing that I am considering is introducing a service/extension point called a 'container finder' that will allow other bundles to customize the behavior of the ECF impl of RFC 119 in terms of finding/selecting/creating ECF IContainer instances (clients essentially) in response to discovered remote services. Then we can also have easy support for a variety of application requirements on this question...by the introduction of a service/extension other bundles could essentially say 'I'm the decider of this policy question for ECF's RFC 119 impl'.
Any thoughts/comments on the basic issue and/or this solution idea would be appreciated.
ecf-dev mailing list