Skip to main content

[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 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 ( ) 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.

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 )


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 be responded to with your code.

Also, I would like to move toward such a tutorial 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

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.



Back to the top