Re: [Embedlets-dev] [Arch] Re: Persistence vs. Management

[Gregg G. W. <gr...@sk...>]

>> If you apply your 'inversion of control' pattern the Embedlet should not
>> see a difference. The container would determine the services that are
>> available and determine whether the Embedlet could be persisted and what
>> persistent service is required. 
>
>Inversion of control means the container controls the Embedlet.  It does not 
>imply that all services are automagically provided to an embedlet by the 
>container, with no work required on the part of the embedlet.  It just means 
the
>embedlet will be called when/if the Container decides it should be...not the 
>other way around.  It has very little to do with which Container services are 
>exposed and how they are accessed by an embedlet.

In our container, we have the following initial interface:

public interface Startable {
	public void startObject(SystemContext ctx);
	public void stopObject();
	public String getSystemName();
	public void setSystemName(String name);
	public UIFactory getStatusUI();
}

This is the minimal context needed to live in the container.  SystemContext 
provides access to lookup other objects that can provide other services, or 
which this object may interact with.  From here we have:

public class StartableObject implements Startable {
	protected String name;
	protected SystemContext context;
	protected boolean debug;
	/** set to true when threads should stop */
	protected boolean stopping; 
	public void startObject( SystemContext ctx ) {
		this.context = ctx;
		stopping = false;
		// Provide the thread for Runnables
		if( this implements Runnable ) {
			new Thread( this, 
				getSystemKey()+"-Thread" ).start();
		}
	}
	public void setDebugging( boolean how ) {
		debug = how;
	}
	public boolean isDebugging() {
		return debug;
	}
	public void stopObject() {
		context = null;
		stopping = true;
	}
	public void setSystemName( String val ) {
		name = val;
	}
	public String getSystemName() {
		return name;
	}
	public void debug( String msg ) {
		if(debug) ctx.debug( getSystemName(), msg );
	}
	public void reportException( Throwable ex ) {
		ctx.reportException( getSystemName(), ex );
	}
}

SystemContext includes a method, waitSync(Object obj) that is to be called by 
all threads in the system, started by objects from inside of startObject().  
It does not return until all objects' startObject() has completed.  Since we 
use properties for persistence, Properties are set first, before startObject() 
is called, to provide the initial parameters, including the name of the 
object, which is stored in the property 'systemName, which the setters/getters 
provide access to.

From here in the class hierarchy, there are more convenience classes such as 
SocketServerStartableObject that has an interface and port property and will 
bind the port and manage it, calling a method apon accepting a connection.  
There's another that just subscribes to the pub/sub space with a specified 
top-level topic for modules that just do local processing of pub/sub traffic.  
Others exist as well that are event more focused on particular types of 
applications.  Providing these base classes with all the convenience methods 
simplifies the developers tasks, as well as allows base functionality to 
evolve with less impact on the actual classes.

The outpost container could either have a persistence object installed that 
could be looked up by the objects, or the 'Base' interface would need to have 
two methods such as the setProperties() and getProperties() that I mentioned 
earlier.  I think that it is vital to have properties in the base API.  At a 
minimum, a 'debug' setting should be available, per embedlet, to control its 
behaviour during testing/debugging.  Andrzej, I really do think that the 
properties based adminitration of the object is exactly the right base 
functionality to provide for all objects.  Adding a more complex management 
paradigm for complex object manipulation would be done in a new base class 
that facilitated that mechanism.

The availablity of the associated classes at compile time would make it clear 
that the functionality was supported.  I really hate configurability just for 
the sake of configurabilty.  Persistance of properties can be optional, but it 
should be possible for them to be configured per object, and I think having 
layered contexts for properties is overkill.  If an embedlet application is so 
large that contexts make since, then it will be a highly specialize 
application, where a specialized configuration tool that would manage this 
layering would not be out of the question.

-----
gr...@cy...  (Cyte Technologies Inc)