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

[Carl Cook <carl@xxxxxxxxxxxxxxxxxxxxx>]

Hi Scott (and all others),

Taking a step back from the implementation of RFC 119, are there clear use cases for when dynamic service discovery is of genuine use? There may well be, and if so, please just disregard this email (!), but after reading the RFC, I saw a clear description of the implementation, but nothing really on the reasons why such a feature is justifiable - without overstepping the mark, I am an advocate of the rule "if you can't use it in three separate contexts, leave it out" :).

From my experience, static service configuration seems to be the mainstream, although dynamic discovery is useful when you have to deal with versioning of services (where a proxy routes the request to the appropriate implementation based on IP address, application headers, etc). However, this can already be achieved (reasonably well) by UDDI, LDAP/Active Directory, etc.

I like the idea of dynamic service discovery. I can think of all sorts of applications, such as using a Dependency Injection framework (Guice, for example) to instantiate and inject a web service (client side) proxy into an program, where Guice itself has used the discovery framework to locate the web service (a currency conversion service for example if the application is in the financial/trading domain). However, as you point out in your email, there are a lot of hidden caveats to this, such as security, resolution of service conflicts, etc.

Am I reading into this RCF correctly, or have I missed the point of the RFC (in particular the dynamic service discovery section)?

Do you feel that there are substantial use cases to support the implementation of dynamic service discovery?

I hope this email generates some more discussion regarding this RFC!

Kind Regards,
--
Carl Cook,
+61 4 02729388

2009/4/8 Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>

Hi Folks,

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.

Scott








_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev