Home » Archived » Eclipse Communications Framework (ECF) » Is ECF suited for distributed process administration?
|
| Re: Is ECF suited for distributed process administration? [message #591993 is a reply to message #591974] |
Fri, 30 December 2005 22:56   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Unregistered Guest,
> I currently have a solution implemented with several
> different processes
> running on different machines.
> I would like to add a way to monitor these processes
> and interact with
> them (start/stop, change configuration, etc). The way
> I wanted to do
> this was to have on each computer an agent that could
> perform various
> actions (alter config files, restart apps) and that
> will connect to a
> messaging server. I want the console application to
> connect to the
> messaging server as well and send commands in way
> similar to chat. I
> would also like to make the server known to the
> clients by multicast so
> that I do not have to configure much.
>
> Is ECF suited for such a thing, a human talking to
> processes? Does it
> have all the bricks needed to allow me to build this?
Basically, the answer is: 'yes', it does have all the necessary bricks to do this. The main support for this sort of functionality comes through the notion of an ECF 'shared object', which represents an arbitrary agent, whose code and state are dynamically replicated within the context of the ISharedObjectContainer instances.
Upon addition to an ISharedObjectContainer, shared object instances have access to sending/receiving arbitrary messages to/from their remote replicas. They have access to primitives for sending either 'multicast' (to all participants within a given group of connected containers), or to directing to a replica within a specific group member.
There are currently three provider implementations for ISharedObjectContainer: 1) a 'generic' provider included in the org.eclipse.ecf.provider plugin; 2) one based upon the ActiveMQ implementation of JMS; 3) one based upon XMPP group chat.
Programmers can define any behavior they wish for shared object instances...including the process monitoring and control behavior you describe, as well as behavior for showing/controlling an Eclipse/SWT/RCP user interface.
Please let us know if you want more input in support of this effort and/or you feel you could contribute the work back to the ECF project.
Thanks,
Scott
|
|
|
| Re: Is ECF suited for distributed process administration? [message #592014 is a reply to message #591993] |
Wed, 04 January 2006 19:12 |
Eclipse User |
|
|
|
Originally posted by: obender2.hotmail.com
I modified the HelloWorld example and added the following lines trying to connect to the <i>myobject</i> shared object already created
ISharedObjectContainer container2 = SharedObjectContainerFactory.getDefault().makeSharedObjectCo ntainer(DEFAULT_CONTAINER_TYPE);
container.connect(groupID, null);
ID[] ids = container2.getSharedObjectManager().getSharedObjectIDs();
I used the same groupID as before but nothing gets returned in ids.
Second question is: how do I make the supplied server, the one in org.eclipse.ecf.serverfeature, expose itself through jmDNS?
|
|
|
| Re: Is ECF suited for distributed process administration? [message #592017 is a reply to message #592014] |
Wed, 04 January 2006 22:48 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi,
> I modified the HelloWorld example and added the
> following lines trying to connect to the
> <i>myobject</i> shared object already created
>
> ISharedObjectContainer container2 =
> SharedObjectContainerFactory.getDefault().makeSharedOb
> jectContainer(DEFAULT_CONTAINER_TYPE);
> container.connect(groupID, null);
> =
> container2.getSharedObjectManager().getSharedObjectID
> ();
>
> I used the same groupID as before but nothing gets
> returned in ids.
I think the call you are looking for is:
ID connectedID = container2.getConnectedID();
Then connectedID.equals(groupID) should be true (if connect succeeds).
The method you are calling above (getSharedObjectIDs()) returns the set of IDs for the shared objects that have previously been added via ISharedObjectManager.addSharedObject(...)
Since you haven't added any, an empty array is returned.
>
> Second question is: how do I make the supplied
> server, the one in org.eclipse.ecf.serverfeature,
> expose itself through jmDNS?
Excellent question.
The current collab example app (org.eclipse.ecf.collab) has code in it to setup a jmdns container, setup a localhost server, and register that server as a service exposed via JMDNS. You can check out that code in org.eclipse.ecf.example.collab.ClientPlugin.initDiscovery, initServer, registerServer() methods.
These are all currently *not* called upon initialization, so just running the collab example plugin won't do this. But if you want to use/copy the ServerStartup and DiscoveryStartup classes (with appropriate mods) then please feel free to do so.
Note that this code (ServerStartup and DiscoveryStartup) probably should/will migrate out of the example app and into the org.eclipse.ecf.provider plugin...so please don't count on them being present in the example collab plugin code for long. But at that point (when they migrate) things should be easier for folks like yourselves...i.e. just create/call these classes in your own client code.
Perhaps even we should consider adding an extension point for org.eclipse.ecf.provider? Let me know what you think.
|
|
| | | |
| Re: Is ECF suited for distributed process administration? [message #592051 is a reply to message #592047] |
Fri, 06 January 2006 03:16 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Ostap,
Ostap Bender wrote:
<stuff deleted>
>
>
> I found that the server was complaining about the SharedObject that I
> was trying to replicate, I needed to place my class on the server as
> well to make the server stop complaining.
Right. Currently (with non-Eclipse RCP/OSGI runtimes) the server needs
to have any needed classes in its classpath for it to find the
appropriate class. This will soon be changing, however, as
a) RCP/OSGI on server implementations begin appearing (for example:
http://www.eclipse.org/equinox/incubator/server/).
b) ECF moves to server implementations that are not just java
applications, but rather run the RCP/OSGI runtime...and allow
interplugin classloading dependencies to be expressed via the OSGI
'buddy loading' mechanism. This makes it possible to express
inter-plugin classloading needs (i.e. plugin a depends upon plugin b for
a shared object class, for example) within the manifest.mf of the
respective plugins.
>Never got an error on the client though.
Well, this could be a bug, but I'm not sure. If the client sends the
following:
getContext().sendCreate(toContainerID, newobjectdescription);
Then if remote classloading/instance creation fails, then the server
should asynchronously send back a failure event that implements
ISharedObjectCreateResponseEvent...e.g.
public void handleEvent(Event event) {
if (event instanceof ISharedObjectCreateResponseEvent) {
// a previous create request failed...what to do?
}
....
> I did send a message and I got no reaction from the object, I thought
> the replica will get an event. How do I know if the message made it to
> the other end?
See above. Note that there is also a fair amount of code to
transactionally replicate a shared object in
org.eclipse.ecf.core.sharedobject. All you really must do to use this
code is to create a class that extends TransactionSharedObject...for
example (from org.eclipse.ecf.test.sharedobjects):
public class TestTransactionSharedObject extends TransactionSharedObject {
Boolean state = null;
public TestTransactionSharedObject(Boolean val, int timeout) {
super(timeout);
state = val;
}
public TestTransactionSharedObject() {
super();
state = null;
}
protected SharedObjectDescription getReplicaDescription(ID receiver) {
// This method is executed on primary to determine initial state
// for replicas
// include primary state in properties
Map properties = new HashMap();
properties.put("state", state);
return new SharedObjectDescription(getID(), getClass().getName(),
properties);
}
protected void initialize() {
// This method is executed on both primary and replicas
super.initialize();
// Only set state via properties if we are replica (not primary)
if (!isPrimary()) {
Map properties = getConfig().getProperties();
if (properties != null) {
state = (Boolean) properties.get("state");
}
}
}
}
And more important how do I attach the replica to anything?
This is actually a tricky question that I am dealing with right now.
The answer in general depends upon what you want to attach it to. Let's
say, for example, that you want the replica to access the local
UI...then you can get to the UI by creating new views, connecting to
existing views, etc by writing code in the msg handlers. If you want to
connect to other shared objects, I'm working on API in the
ISharedObjectContext to allow you to connect (for asynchronous local
invokation) to another shared object that exists within the given
container (and, of course, disconnect from it). The support for this is
in place, but I need to add to the ISharedObjectContext API. I am
working on the SharedObject API, however, right now (to do this and to
allow, e.g. the creation of shared objects via a SharedObjectFactory
that is also an ECF extension point. This would also allow plugins to
contribute shared objects (communications components) via the RCP/OSGI
mechanisms (i.e. by providing extensions for ECF extension point).
But, alas this is not all done...yet...but I'm working on it and fully
aware of its importance. LMK (anyone!) if you have thoughts about
specific needs and desires for the API.
Scott
|
|
| |
| |
  |
Goto Forum:
Current Time: Sat Apr 20 00:51:02 GMT 2024
Powered by FUDForum. Page generated in 0.04265 seconds |
] 
Search
Help
Register
Login
Home
