[
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 admin...so 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:
org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager.
The current flow for service export is this (this has to be documented
more thoroughly, and will be here [2]):
bundleContext.registerService
ServiceHook->BasicTopologyManager
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:
org.eclipse.ecf.osgi.services.remoteserviceadmin.HostContainerSelector)
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
it.
I think this is actually a question about the declarative services
lifecycle. I'm not certain of this...so 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
Zookeeper?
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. :)
Scott
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].
[1] http://www.eclipse.org/forums/index.php?t=msg&th=205732&start=0&S=25fa5307bc4de642f8cb01bc3f5e856e
[2] http://wiki.eclipse.org/EIG:Topology_Management
Thanks again!
