geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: Kernel Deployer Enhancements
Date Mon, 20 Oct 2003 13:16:22 GMT
Hello Aaron,

You wrote:
>	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.
I though that you intended to implement these JSR-88 commands via 
ApplicationDeployer? I had a look to the brand new version of 
ApplicationDeployer and I am not, yet perhaps, convinced:

You have decided to verify the distributed modules at this specific stage, 
which is perhaps not a good place. Indeed, and this point has already been 
raised by someone else, such a process is module type specific. I agree that 
these verifications are minimalist, however I’ve got the feeling that you 
also intend to validate the DD, generate the required classes et cetera at 
this stage, which does not sound correct.

Moreover, the ModuleType API makes clear that vendors can define new module 
types by sub-classing ModuleType. And hence, to put logic within 
ApplicationDeployer to assess if a distributed module is valid does not 
sound good.

Consider the following scenario:

I write a Deployment Planner, which knows how to plan and deploy a *.ser 
file/archive. With the current implementation, it is not possible to 
distribute such an archive even if such a Deployment Planner is mounted.

A solution is to listen to the registration/unregistration of Deployment 
Planners. These Deployment Planners provides advertisements on their 
deployment capabilities. ApplicationDeployer uses these advertisements to 
perform the validations and also guide the deployment to the right Planner 
(it can simply bypass DC). Even if this type of upstream evaluation is the 
preferred way for event-based solutions, IMO this is not really required.

IMO, ApplicationDeployer should be a rather hollow component, which calls 
either a MBean or DC. More accurately, the JSR-88 commands are implemented 
like this:

- start: simple call to a MBean (use the JSR-77 capabilities);
- stop: simple call to a MBean (use the JSR-77 capabilities);
- undeploy: unregister a MBean;
- distribute: what has been implemented without the "ServerTargetModule 
section" and then call to DC; and
- redeploy: composite operation equivalent to undeploy, distribute and then 

If you remember the idea of a meta-data MBean mounted for each deployment, I 
believe that this is our point of entry to implement start, stop and 
undeploy. ServerTargetModule is more or less an attribute of this same 
meta-data MBean.

DC is only used to create via the relevant Deployment Planner this meta-data 

>	To support all this, I'd like to add some features to the
>DeploymentController (DC):
>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).
I though that you intended to implement a pure event-driven solution. If 
yes, then one does not need this change:

For instance, one can:
- defer the creation of a target module ID until a URL is actually deployed 
by a deployment planner;
- listen to the registration/unregistration of meta-data MBeans, which 
encapsulates a TargetModuleID;
- use these notifications to track the available modules; and
- listen to the JSR-077 status change notifications broadcasted by the 
children of these meta-data MBeans in order to assess if a deployment is 
running or simply available.

One ends up with a looser coupling between the various artifacts (which is 
one of the main advantages of event-based solutions).

I have implemented such a solution and I am waiting for the validation or 
not of the meta-data MBean in order to finalize the implementation and 
submit a proposal.

Should I try to progress the implementation or do you prefer to plug JSR-088 
via your approach?

>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.
If one does not want a polling solution, I am also short of ideas.


MSN Messenger 6  : dialoguez en son et en image 
avec vos amis.

View raw message