Kernel Deployer Enhancements

[Aaron Mulder <am...@alumni.princeton.edu>]

	I'd like to make some improvements to the kernel 
DeploymentController.  Specifically, I'd like to work on implementing the 
JSR-88 command "start", "stop", "undeploy", "distribute", "redeploy", etc.  
Several of these take multiple modules to operate on, and all return a 
"progress object" which provides events and messages and status codes to 
describe the progress of the ongoing operation.  I'm assuming that the 
right way to implement the progress object is to have the 
DeploymentController fire JMX notifications that the progress object can 
listen for and relay to its clients.

	To support all this, I'd like to add some features to the
DeploymentController (DC):

1) Have a way for the DC to issue an ID for a deployment job 
(autoincrementing integer or something) and then fire notifications with 
that ID as the job is executed.

2) Let the caller supply a list of goals to the DC, instead of only 
invoking operations like "deploy(URL)".  That way the JSR-88 back end can 
hand the deployer a list of goals for a list of modules, all as one "job".

2a) Add IDs or optional user data or something to goals so that the JSR-88 
back end can later figure out whether individual goals were achieved or 
not (perhaps of 4 deployments, 1 succeeded and 3 failed).

3) Let the caller register goals asynchronously (get an ID for the job
immediately, rather then waiting for the DC monitor to be acquired).  
Perhaps have a queue of work for the deployer or something, though it 
seems like we'll need a thread to invoke the DC on the pending work.

4) Implement a bunch of notifications for deployment plan processing, 
perhaps only to be used if the DC was invoked in that way (see #1).

5) Add start/stop goals to the existing deploy/undeploy/redeploy

6) (lower priority) allow the deployer to be interrupted.  Given an ID, it 
would stop processing that if it's what it's currently working on, or take 
it out of the queue if the specified job is still waiting

7) (still lower priority) allow an interruption with rollback, where any 
work already done on the job is reversed.

	Any thoughts on this?  I know next to nothing about JMX 
notifications, so I'll need to study up on that a bit.  If there's some 
better way to handle the status callbacks, I'm all ears.

Thanks,
	Aaron