[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] Re: Need further clarification on Distributed Event Admin
|
Hi Andrea,
Thanks for sending this description of your work with
DistributedEventAdmin to the ecf-dev mailing list. Just for everyone
else's reference, Andrea and I have been having a technical exchange on
the ecf newsgroup, which you can see here:
http://www.eclipse.org/forums/index.php?t=thread&frm_id=99&;
There are a couple of comments interspersed in Andrea's posting below.
Andrea Zoppello wrote:
Hi Scott,
Thank you for the response, i've no problem in moving out technical
discussion
on the mailing-list i'm already subscribed :-)
I'll take one or two days trying to make some practice with the
suggestion you give me.
BTW maybe it's better i'll explain what i'm trying to do:
1) In my project all service has a property identifing the service
(custom.id )
2) All OSGi service implements a common interface ( based on
Messagging Concept, each service receive a message as
the input and produce a message as the output )
3) My OSGi services are all implementing the EventHandler interface,
and are all created using DSComponent Factories.
The usage of DSComponent Factories is very useful for me because:
- It allows me to have multiple services for the same factory.
- It allows me to specify at "service creation time" the event
admin-topic property for my service
So what happen to my service is that if the service is identified by
"ServiceFoo" the component factory
will specify "BASE/MESSAGES/ServiceFoo_<NODE_IDENTIFIER>" in the event
topic properties.
<Node_Identifier> is a string readed from a configuration file
identifying a node.
To be quicky doing the things in this way let me to have each service
to listen to a dedicated topic.
On top of this i built a message router, that use the event admin
service to send message from
one service to another. Obviously the message router has to have
knowledge of the service registered in the system
before sending a message.
For doing this i've implemented a Registry class to be aware all
services registered in the system, this registry class
use some "notification topics" on the distributed event admin to be
aware of other nodes.
In my registry class i've successfully handled all situations except
the situation in which one of the nodes crash, in
that case the crashed node won't be able to notify to others and the
registry state will be not consistent.
This is the reason why i've consider to use JGroup, for all other use
case distributed admin within my Registry
code class works for me, i've just tried with success to start more
than one nodes in different orders ant it works perfect
except for the use case described.
As we discussed on the newsgroup, ECF has a JGroups-based
provider...available at the ECF OSU Open Source Lab CVS server:
Anonymous access
host: ecf1.osuosl.org
path: /ecf
module: plugins/org.eclipse.ecf.provider.jgroups
Eclipse: :pserver:anonymous@xxxxxxxxxxxxxxx:/ecf
Extssh access (I administer this machine so can provide write access)
host: ecf1.osuosl.org
path: /home/cvs/ecf
same module
Eclipse: :extssh:ecf1.osuosl.org:/home/cvs/ecf
This provider is based upon JGroups 2.5.0. It implements the ECF shared
object API, and this API exposes access to group membership changes, as
well as manipulation of group membership from the manager container.
The DistributedEventAdmin class (i.e.
org.eclipse.ecf.remoteservice.eventadmin.DistributedEventAdmin) actually
extends BaseSharedObject (i.e.
org.eclipse.ecf.core.sharedobject.BaseSharedObject). This means that
the DistributedEventAdmin is actually a shared object instance...and so
subclasses of DistributedEventAdmin can/could receive events (such as
group membership changes)...and respond to them by running arbitrary
code. It sounds like this *might* be useful for your use case(s).
To be briefly in my conclusion i had two different use cases
1) The need to distribute the Router implementation ( and this is jsut
working simply using the ECF Distributed Event Admin Implementation )
2) Mantain a consistent registry of my custom services in cluster
configuration ( solved partially at the moment )
OK, sounds very good. Andrea...if you are able and willing it might be
a good idea to create a wiki page of your use cases for
DistributedEventAdmin...and how to setup/use the ECF implementation
(with JGroups and/or some other provider). If you would be willing to
do this it would be very helpful to the community, I think. If you have
a bugzilla login, you can create wiki pages and add them to the ECF home
page: http://wiki.eclipse.org/ECF.
I will happily assist in this, if desired (and of course will answer
questions, etc). Even better, if you were able to contribute code, or
identify bugs, or identify areas in either the API or implementation
where generalization/improvement could be made that would also be most
appreciated. And finally, if you were willing to blog publicly about
this work (or allow me to) that would also be helpful...as I don't think
a lot of people yet know about the DistributedEventAdmin and what it can
do...especially with ECF's multi-provider architecture and the use of
the shared object API.
Thanks,
Scott
Andrea
Il 04/02/2010 15:55, Scott Lewis ha scritto:
Hi Andrea,
Andrea Zoppello wrote:
Hi Scott,
Thank you for the great explanation, after reading your response a
lot of things that i was confused about are a bit clear quite now.
I finally understand that ECF have and manage a concept of group
membersghip ( like the one jgroup has.... ).
This group/membership management is quite interesting for me because
at the moment i've used the DistributedEventAdmin implementation
successfully, but i also need *group management* features too...
My initial idea was to use:
1) ECF for the distributed event admin stuff
2) Implementing something based on Jgroup to have node on cluster to
be aware when other nodes coming up and go down.
Now after reading your post it seems ECF could cover also the point 2).
Yes. Just a little more information on this...ECF has an API called
the 'shared object' API (i.e. org.eclipse.ecf.sharedobject). This is
the API that implements reliable group membership/management. The
API exposes various methods to get at group membership information
and get access to manipulating the group members (e.g. see
org.eclipse.ecf.core.sharedobject.ISharedObjectContainer which
extends org.eclipse.ecf.core.IReliableContainer ...which exposes
group membership access information). See also
org.eclipse.ecf.core.sharedobject.ISharedObjectContainerGroupManager,
which is implemented by the group manager, and provides some group
membership control information.
Now, just for your information...the DistributedEventAdmin is
actually *implemented* using the shared object API. So it should be
possible for you to use the existing DistributedEventAdmin
implemention *and* access/use the shared object API for your other
use cases.
Finally, I'm not sure whether you were aware of this, but we have a
jGroups 2.4.1-based ECF provider *and it already implements the
shared object API*. Meaning that it can right now serve be used with
the DistributedEventAdmin, and the jgroups group membership functions
(over multicast) can be accessed via the shared object API.
Is there any example or tutorial about group/member management with
ECF API. A simple example with two nodes receiving notifyng could be
enough.
Unfortunately, there is not yet such a tutorial. I would like to
have one, but just haven't had the opportunity. However, if you look
in org.eclipse.ecf.core.sharedobject.BaseSharedObject (which,
incidently is the superclass for DistributedEventAdmin), you will see
1) that the shared object/distributed event admin is provided an
org.eclipse.ecf.core.sharedobject.ISharedObjectContext upon creation,
and can access group membership information via this context (which
means that if you extend DistributedEventAdmin you can/could call
these ISharedObjectContext methods as you wish.
2) the shared object has method addEventProcessor(IEventProcessor),
which allows shared object event notifications...of group membership
changes...to be responded to with your code.
Also, I would like to move toward such a tutorial myself...so if I
can help via responses to questions I will be able to use that to
compile such a tutorial eventually.
Oh, BTW...if at all possible I would like to have detailed technical
discussions on the ecf-dev mailing list...because there are more
people that regularly read that mailing list...and I think many of
them could/would benefit from your observations, use cases, and
questions. Do you think it would be possible to move this discussion
to that mailing list?
If you need instructions about how to join the mailing list, see
https://dev.eclipse.org/mailman/listinfo/ecf-dev
I've a last question:
In my equinox node ( where i'm going ) to setup the distribute event
admin i want to implement something like " if there's already a
group manager create a client container ) else create and setup a
group manager ( ECF server manager ) container"
I think this is possible but i dont't know how to detect if the ECF
manager is available...
It should be possible to do by using the IContainerManager service to
iterate through the existing containers (e.g.
IContainerManager.getAllContainers()), and test each one for whether
it's a manager (e.g. by getting the ISharedObjectContainerAdapter for
the container...and if it's non-null calling
ISharedObjectContainerAdapter.isGroupManager()).
Unless I'm misunderstanding your use case here...which is possible,
of course.
Thanks,
Scott
