Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Automatically set IP address in a declarative service (ideas or best practices?)

Hi Pablo,

On 3/21/2011 4:31 AM, Pablo García Sánchez wrote:
Hi all. I posted this message into ECF Forum[1], but Makus advised me
to post in the mailing list instead, due to is more used. Copy/paste
from there:

"I am doing research about distributed and service-oriented algorithms
in clusters and heterogeneous networks, and I would like to use OSGi
and ECF in my thesis.

Due to I want to do research in P2P topographies (that is, not
all-to-all connections), I would like to deploy ECF in several nodes
of a cluster and doing the services bindings manually (or
semi-automatic). For example, bundle A in Node A requires service B
from Node B and service C from node C and B and study latencies,
distributed genetic algorithms, dynamically adding new nodes... and
all that stuff.
So, the idea is to expose all service hosts in DS way and bind
manually or also in a declarative way, but I have several doubts:

- The first one is about setting
"org.eclipse.ecf.containerFactoryArgs" in each service to expose. In
DS you can set it in the xml description file, but, this URL will be
different in each node, so I should change in every xml in every node?

You could do this.

Or I could access to ComponentContext properties and set the ip in the
activate() method of the component? (

This should work as well. Note that you can create the container instance 'manually' in activate method (with the desired containerFactoryArgs), and the default implementation of RSA topology manager will pick it up/use it...rather than creating a new container instance when the service is exported.

reading this URL from command
line or whatever).

There are two other approaches that I can think of for your use case (as I understand it)

1) Use the OSGI configuration that you can customize the service properties of the ds-exported service without using system properties 2) Use the (new to ECF 3.5) Remote Service Admin, and customize the container creation for each node. The OSGi RSA specification has the concept of a 'topology manager'. This is an object that controls the export (service host) and import (service consumer). ECF 3.5 comes with a single topology manager at the moment...with class:

The current flow for service export is this (this has to be documented more thoroughly, and will be here [2]):

                                    Get ECF RemoteServiceAdmin impl
                                       Get IHostContainerSelector
Call IHostContainerSelector.selectHostContainers export the service for each container returned from selectHostContainers

There are two basic points of customization possible in this call stack:

1) The type/implementation of the topology manager (i.e. with RSA you can create/use your own topology manager) 2) The type/implementation of the IHostContainerSelector. It's actually the default implementation of IHostContainerSelector (with class: that is responsible for creating and/or selecting the host container instance(s) to use for the subsequent export (and this HostContainerSelector is what uses the containerFactoryArgs to actually create the host container instance. It's easy to customize/replace the IHostContainerSelector and control how/when/what container is created/used during remote service export. All one needs to do is implement their own IHostContainerSelector class (optionally using/re-using the AbstractHostContainerSelector if desired), and then register this new instance as an IHostContainerSelector service (using the whiteboard pattern). This will override the use of the default ECF container selector (i.e. HostContainerSelector), and use yours instead.

It's also possible to use/create your own topology manager, for even greater control over the export (and import) of remote services. For example, you might trigger the export of a remote service based upon some application-level event.

Is this a good programming practice?

- My second doubt is related to the first: how can I execute the
activate() method of a componet before being used or bound by a
consumer? I think that this is possible, but I don't know how to do

I think this is actually a question about the declarative services lifecycle. I'm not certain of it might be good to ask in another forum, consult the specification for declarative services, or perhaps someone with more knowledge of the declarative services lifecycle can answer this.

- My final doubt is how to say to each node which service of what node
must chose. I've thought in using filters of the service registry,
filtering by IPs and other properties, but also I want to know wich is
the best programming practice to do it. Maybe I should investigate

Or maybe should I wait until Remote Services Admin (RSA) becomes
available along this month? Perhaps it could be the solution to all my
problems : )

Actually, I think it is the solution to most of your problems, as it provides the flexibility that you seem to be looking for. :)


Thanks in advance."
[End of the ECF post]

After post that thread I waited to the release of ECF 3.5, and I can
see the new documentation wiki, with everything more organized and so
:) It seems that Remote Service Admin is a good improvement of this
version, but there are no information about how to use it properly in
the wiki yet. Also the Topology Management[2] could be useful to my
work, but also is not well explained yet.

Yes, this is true...I think it will be useful for your use cases, as it provides quite a lot of customization/control for handling more 'exotic' use cases (such as yours). I'm working on documentation of the topology manager structure as much as possible...but since there is only one of me working on both the implementation and the documentation of this part of ECF (in my spare time), this goes slowly. Any help/contributions in that regard are welcomed. In the mean time, I would suggest looking at/reading the OSGI RSA specification (chap 122 in the enterprise specification). There are links on [2].


Thanks again!

Back to the top