Skip to main content

[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



Back to the top