[
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
