[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem regarding hello.ds examples.

 Hi Jeff,

On 9/9/2010 6:25 AM, Jeff Hamm wrote:
Hi Scott --

More questions :)

I found this this morning and it really helped a lot in explaining what is going on behind the scene.

http://www.eclipse.org/forums/index.php?t=msg&goto=554498&S=907c527c9a4d8b8613f45dfbb566288d#msg_554498


So with this knowledge, I tinkered around a little bit and now I think that the service.host in my example is not ever broadcasting that the service is available. I changed the cardinality of the reference in the client from 0..n to 1..n and the client service fails to start appropriately which lead me to the conclusion.

Yes. So first a little background (that will hopefully be helpful for all). ECF's remote services implementation is logically devided into two parts: discovery and distribution. For discovery, ECF uses the ECF discovery API (naturally :), and for distribution ECF uses the ECF remote services API. Both of these APIs (discovery and distribution) are abstract and support multiple providers...so that (for example) you can use apache zookeeper for network discovery of your services...or zeroconf, or slp, or xml-file-based discovery, or your own custom discovery. You can also use one of several (or even your own!) remote services provider (e.g. ecf generic, r-osgi, jms, xmpp, etc). This overall architecture is described graphically here [1].


This means that you can 'mix and match' your discovery and remote service providers...e.g. you can use zeroconf for lan-based discovery alongside r-osgi, or apache zookeeper alongside ecf generic...or file-based discovery alongside r-osgi...whatever combination makes sense for your use case. This is very handy, I believe, because with remote services it's often the case that the use cases for discovery are quite varied (e.g. lan vs. wan-based discovery, authentication/security requirements for discovery, etc)...and this architectural approach of a) separating the discovery and remote service APIs; b) making *both* APIs provider and protocol independent allows some very nice module-level reuse. That is, even if you have a discovery use case that requires a specific discovery provider (e.g. zookeeper), you can still have your choice about the distribution provider (which defines the marshalling/serialization and the remote invocation wire protocol).

You've probably noticed that in the hello examples there is a products directory...and in that products directory are some example product configurations. These product configurations show some examples of using various discovery and remote services providers...for example zeroconf and r-osgi, or file-based discovery and ecf generic, etc.

Now, back to Jeff's situation. It seems likely, based upon what Jeff has said about his remote service, that it is not being discovered by the consumer. This could be for a number of reasons...all of which having to do with discovery...e.g. you could not be including a discovery provider at all (i.e. there are no discovery provider running in the host), or you are not running one on the consumer, or they are not using the same protocol, or your network doesn't allow certain protocols/traffic for security reasons, or your lan/wan configuration doesn't allow you to use a certain provider, etc. Unfortunately, this is somewhat of a problem for discovery...and we/ECF unfortunately can't completely fix it...because at least network-based discovery (i.e. discovery that uses some protocol to communicate remote service meta-data) is quite sensitive to the network topology, lan/wan-based configuration (e.g. availability of name services, etc), and other things that are not under either our, or your control.

So what we have been, and are trying to do, is to create *several* discovery providers, that use different network protocols, require different network configurations, and use different strategies for discovery...so that you as the remote service designer and implementer can choose and use the one (or several!) that matches your requirements and your service's target network constraints.

I see by checking my email that in the time I've been writing this that Markus and Jeff have engaged in further dialog about Jeff's specifics of discovery. I hope that this overview has been a little bit helpful for Jeff or others. I would like to produce more documentation about the specifics of ECF's architecture/design/implementation/extensibility, but am a little hampered WRT resources availability for my time...and want the documentation to match what people are most in need of. So please let me know via this list what you are interested in hearing about.

BTW, ECF does have some basic support for debugging the OSGI remote services implementation (discovery and distribution). First of all, one can use the discovery UI stuff (which Markus can detail better than I can) to see in a user interface whether a remote service meta-data is published using a given discovery provider(s).

In addition, there are listeners that can be defined (and synchronously notified) during the various parts of the discovery and distribution process on both the service host and service consumer/proxy. See some documentation for this here [2].

The hello host and consumer examples (the non-ds examples) set up these listeners and simply print out to console when the discovery publish occurs on host, with what provider, etc. There are also examples in the test code...e.g. org.eclipse.ecf.tests.osgi.services.discovery.ListenerTest

Along with the discovery UI, these can be used to get some runtime indication of what's happening with network discovery on the host and consumer.

Hope this helps. I'll happily do more docs (both in wiki and in response to specific questions), given some additional time. I would like to make documentation a priority for this coming fall and subsequent releases, but like everything this takes resources and time.

Scott

[1] http://wiki.eclipse.org/OSGi_4.2_Remote_Services_and_ECF
[2] http://wiki.eclipse.org/Discovery_and_Distribution_Listeners