[
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.
Thanks,
Scott
