[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Is ECF suitable for this project?

Hi Paul,

Paul Woodward wrote:
Hi Guys,
I've been following ECF for a little while now, and I've noticed a lot of emphasis on VOIP/chat/IM.
I've got a to develop a support application for managing multiple compute grids, this will be an RCP app based on the eclipse workbench. I plan to have an object model that represents each grid and its status. For a couple of reasons I would be very nice to be able to share this model 'live' between all of the support personnel:
1. There is a cost to the compute grid associated with getting real-time information - if one client gets it, I would like to share that everywhere
2. For some operations, optimistic locking will not be appropiate and I will want to pessimistically lock objects in all clients.

A part of ECF has the concept of a 'shared object'. A 'shared object' or set of shared objects can represent an arbitary model that is dynamically replicated among a group of processes. The shared object(s) can then send messages among the replicas to update the state in a manner appropriate to the application. A distinction is made between a 'primary' and the other replicas, so that (for example) a server (or one of the peers) can be authoritative WRT coordinating state changes.

So, for example, your object model could be 'wrapped' by a shared object and replicated among all participating clients and/or servers. State updates could be done either optimistically (for some state updates) or pessimistically (via a two-phase commit protocol) with the shared object class implementation making the decision about which state update protocol is required to meet application requirements. This way the shared object can make the determination about which protocol is required for a given state update, and engage in that protocol using some messaging primitives provided by the ECF container (reliable, sender-ordered group messaging). The point here is to not impose any particular state management on a shared object...i.e. force it into using either heavyweight pessimitic messaging for all state changes, or only optimistic protocols...but rather to allow/support the *application* to manage the distribution/replication and distributed synchronization of its own model in a way that makes sense for that model and it's usage via the user interface/view.

Note that as of fairly recently I added a set of classes to support transactional shared object replication...so that upon creation a shared object will be pessimistically replicated to the participating processes (all or nothing two-phase commit). These classes are in the org.eclipse.ecf plugin, in the org.eclipse.ecf.core.sharedobject package. Specifically the TransactionSharedObject abstract super class. For test code, see org.eclipse.ecf.test project, org.eclipse.ecf.test.AddTransactionSharedObjectTest.

Essentially what I would like is for any updates to the object model to be fired as property change events so that I have a consistent interface for model listeners for changes happening both locally and remotely.
This should be very easy. A shared object that was simply a property change listener that then serialized some version of the event and distributed that event to other group members (using optimistic and/or pessimistic as desired/appropriate) would be a natural. Shared Objects have a 'ISharedObjectContext' which allows every shared object to communicate with it's remote replicas (e.g. ISharedObjectContext.sendMessage(...)).
Does this sound like the kind of project ECF is being designed for? If it's not currently possible, what sort of time frame we we looking at?
Yes, it seems to fit quite well. The folks from the Corona project (http://www.eclipse.org/proposals/corona/) are actually using ECF for something like this (distributing events among a number of receivers...for notification rather than replicated model update).

I've worked with JGroups before and like it a lot. What is the planned timeframe for its integration?

Ah, good question. I would like to have javagroups as a provider underneath the ECF shared object API already. The reason it is not already is two fold:

1) Javagroups is under LGPL, which is not distributable under EPL...so if we do a javagroups-based ECF provider we cannot distribute it under the EPL (we can still do one, it's just that it has to be distributed in some other way...i.e. commercially, or under some non-EPL license...and not via eclipse.org)
2) We haven't had enough time to do as many providers as we would like. We now have an ECF 'generic' provider (server-reflected tcp-based messaging), and a JMS provider using the ActiveMQ implementation of JMS (http://ecf1.osuosl.org). We would very much like to already have a javagroups-based provider and a JXTA provider...but just haven't been able to do it yet. There is a nice little tutorial on using ECF to create such a provider however available here: http://www-128.ibm.com/developerworks/opensource/library/os-ecl-commfwk/

But we would love to coordinate such an effort with others to use javagroups as a messaging provider for the ECF shared object api. The basic models are very compatible...i.e. replication of a set of distributed objects, and reliable, ordered messaging (via javagroups channels) to deliver and apply state updates.

So if you are able perhaps we could coordinate putting in place an ECF provider implemented with javagroups in support of your project. Let me know if this would be doable, and how/whether you would like to participate in such an effort.