Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] help

Hi Ronen,

On 3/22/2011 8:47 AM, ronen hamias wrote:
Hi Scott and thanksfor the response,
i think my need is for away to control my "service clustering" lets say i have IHello service and IHelloImpl and
i wish to distributed IHelloImpl over a cluster of nodes (servers) where actually its the same class/bundle only that it has several instances 
see attached illustration.
my end users (UI) does not need to be aware of the service location they connect to a proxy and it will delegate the service request for them.
but i do require to be able to control the endpoint selection (round rubin, random access, properties query(optional)) and to be able to extand the endpoint selection in the future
as i see it it will be nice if i could determain an endpointSelectionProvider to implement such ep selection logic

It seems to me that you will likely need to implement your own topology manager to address your use case...since it involves controlling the remote service export and import process in a specific, application-defined way.  

The OSGi RSA specification explicitly allows for multiple/alternative topology that the remote service export and import process (in response to discovery), can be controlled as appropriate.  The specification has a great deal of flexibility in this area (topology managers)...specifically to support use cases like yours.

Further the RSA impl in ECF 3.5 fully allows for the creation of other topology managers...and supports using/creating alternative topology managers. 

But, since the ECF RSA implementation is relatively new, there are not (yet) many existing public examples of alternative topology managers based upon the ECF RSA impl.  There is, however, the 'BasicTopologyManager', which is the one that comes with ECF 3.5...and enables the basic support for remote service export and import.  The source code for the BasicTopologyManager is here:

This topology manager extends the AbstractTopologyManager

You are of course welcome to reuse any of the code in ECF...or you can use it as example code to create your own topology manager to meet your use case.  Note that the the ECF RSA impl allows quite a good deal of flexibility *without* a new topology manager...e.g. the IHostContainerSelector and IConsumerContainerSelector structure...but you can also create a completely new topology manager (not based upon BasicTopologyManager or AbstractTopologyManager), if you desire.

I myself am in the process of creating some alternative topology managers (e.g. for exporting/importing REST-based remote services), under the auspices of my own commercial venture (  If you are interested in working with me directly on this, then please contact me directly at slewis at  Obviously, since I'm the primary author of ECF's RSA well as the BasicTopologyManager/AbstractTopologyManager and the underlying RSA implementation, I have some direct knowledge of how to do this :).



can you please direct me to an example to achive such capability?

Best regards

On Tue, Mar 22, 2011 at 4:55 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
On 3/22/2011 5:29 AM, ronen hamias wrote:

<stuff deleted>

few questions:
i wish to distribute the consumer and provider remotly i dont see how the consumer is aware of its providers location...

That's what the discovery mechanism if for.

1. what methods should i use for dynamic discovery of endpoints?

ECF has a discovery API that is used for Endpoint Discovery, and this API supports multiple providers.  There are examples in the hello world consumer (and host) of using zeroconf, apache zookeeper, edef (file-based discovery).  And there are also ECF discovery providers which use dnssd and slp (Service Locator Protocol).

The selection of a discovery provider should be based upon your use case...i.e. how is your service going to be discovered by clients? (i.e. statically...via edef files, or dynamically (via one of the network protocols)...on LAN, WAN, or both?...with a server to coordinateservice discovery (e.g. zookeeper) or serverless, etc.

2. what happen if i have 3 instances of my service on 3 diffrent nodes how the consumer will locate these 3 instances and which of them will he invoke?

This is what the network discovery is for...for communicating the meta-information about the remote services (i.e. EndpointDescriptions) to the consumers of those services (through some means of discovery). 

If your application needs to make some application-level decisions about which services (or which remote services) to import or invoke then you can implement that in several ways...e.g. by having your own service properties, by having/using multiple service interfaces (i.e. different service types).  You can also control the actual remote service import...if you creating your own topology order to decide (for example), when to import a discovered remote service, and when to ignore it.


ecf-dev mailing list

Ronen Hamias
Cell Phone: +972-50-2289988
_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx

Back to the top