[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] service discovery working even if port mis configured
|
Hi Peter,
On 4/17/2014 4:22 AM, Peter Hermsdorf wrote:
Hi,
I'm investigating using ECF for use in a (RCP) client and server
scenario. I've gotten the timeservice example to run, including using
DS for the service definition, but I've some trouble getting ECF
configured for our use case.
Maybe someone can bring some light in the questions i have.
The general problem i have is that service discovery is working too
well for our setup ;)
That means e.g.: when running the
com.mycorp.examples.timeservice.consumer.ds and
com.mycorp.examples.timeservice.host and changing the server port to
eg. 8888 in the supplied TimeServiceHost.generic.product launch config
without changing the corresponding -Decf.generic.server.port in the
client launch config the service gets discovered as well.
Yes. The reason for this is that the uri for accessing the service is
communicated automatically via one of the discovery providers.
From my point of view it seems like the client is ignoring the port
setting.
This is by design...for the examples anyway...in order to make the
examples as initially easy-to-use/try out as possible...without having
to do any discovery configuration or starting of edef bundles, etc...in
order to try out a remote service.
If i think of environments where production and test machines reside
in the same subnet that automatic discovery would lead to unexpected
results.
Yes. You are quite correct that production/test/deployment of remote
services would/should likely use some other discovery mechanism...e.g.
for WAN-based discovery. The examples are currently configured for
easy, out-of-the-box, LAN-based discovery.
What i've tried is substituting the org.eclipse.ecf.provider.jmdns
service discovery provider with the zookeeper discovery. When running
zoodiscovery.flavor.standalone the result seems to be the same
(misconfigured server port, but service gets discovered).
The only solution which i found was running
zoodiscovery.flavor.centralized, which results in a not working client
when the supplied IP address is wrong.
Yes. Each of the discovery providers (i.e. slp, zookeeper,
zeroconf/jmdns, dnssd) can be configured...for example zoodiscovery has
a 'standalone' and 'centralized' flavor. For zoodiscovery, this is
documented here:
https://wiki.eclipse.org/Zoodiscovery
What we want: simple client setup that just talks to the server
supplied (which is only known at runtime of the client app - so xml
service description cannot be used). The client is expected to get the
server's IP adress from a local property file in the user home.
I'm not certain I understand what completely what you mean by 'xml
service description cannot be used', but one possibility that occurs to
me is that rather than one of the network discovery protocols
(zookeeper, dnssd, slp, zeroconf), you could use an edef/xml
description...with most of the information in it 'constant'...e.g. like
in the timeservice examples here:
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice.consumer.filediscovery/timeserviceendpointdescription.xml
BUT...for the properties that you wish to change/set (e.g. the server's
IP address from local property file)...you could
dynamically/programmatically read an EDEF template file...set/change the
necessary values...prior to using the newly constructed/manipulated EDEF
to actually discover the service.
Before I go further with this...do you think this could satisfy your use
case? It sounds to me from your description of what you want that it
might...i.e. use a few local property files to read a few properties
(i.e. server's IP address), change or create the associated EDEF, and
then use that EDEF to trigger remote services discovery and remote
service import. Does that seem right?
ECF's RS impl does have some code that would/could assist with this...if
it fits your desired use case. For example, we have classes for reading
and writing EDEF...in EndpointDescriptionReader and
EndpointDescriptionWriter classes...respectively...located here [1].
These could be used to read in a template, manipulate the
EndpointDescription properties, and then write them out to a new EDEF
file (presumably to a new bundle that would be subsequently
started...thereby triggering RS discovery).
I've done this before myself (create/manipulate EDEF...dynamically
create a new bundle...and start the new bundle to trigger RS discovery)
on behalf of another user of OSGi Remote Services...so I'm quite sure it
works properly.
It would be great to use DS for service description and only have one
single point of configuring the server location, eg. as System
Property which is set by a dependent bundle or something. (so multiple
services, but only one remote server configuration done at runtime)
Maybe someone can point me in the correct direction for this kind of
setup.
I'm still not completely certain, but perhaps the above is in the right
ballpark. Please let all know.
Thanks,
Scott
[1]
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/osgi/bundles/org.eclipse.ecf.osgi.services.remoteserviceadmin/src/org/eclipse/ecf/osgi/services/remoteserviceadmin
