JSR77 -> JSR88

[gianny DAMOUR <gi...@hotmail.com>]

Hello,


It seems that by now we do not have a clear idea of how to "connect" JSR77 
and JSR88.

For instance, when a J2EE module is deployed by dropping it in the 
"auto-deploy" folder, ApplicationDeployer (invoked remotely by a JSR88 
client in order to perform various deployment operations) needs to be 
notified. Also, when the JSR77 state of this module changes, 
ApplicationDeployer needs also to be notified.

ApplicationDeployer needs to be notified in order to track the state 
(running, stopped), the type (EJB, WAR, EAR et cetera) and various other 
pieces of information.

Multiple solutions could be implemented in order to "sync" the JSR77 and 
JSR88 models.

And this is a possible one only based on naming conventions:

Whatever the type of deployment, a MBean matching the pattern 
"*:role=DeploymentUnit,url=" + ObjectName.quote(url.toString()) + ",*" MUST 
be created. This is a requirement of the DeploymentController.

This naming convention could be extended to also include a moduleType 
property, if the deployment is a J2EE module. The value of this property is 
the ModuleType.toString value of this J2EE module.

Moreover, JSR88 requires a unique module ID and this module ID could also be 
an additional property (this is even suggested by the specifications).

For instance, if one drops a WAR in "auto-deploy", then the name of the 
deployment unit could be:
geronimo.deployment:role=DeploymentUnit,url=test,moduleType=war,moduleID=1

This way, ApplicationDeployer "just" have to query the MBeanServer to 
retrieve all the ModuleType.WAR modules.

ApplicationDeployer also needs to retrieve the state of these J2EE modules 
and this can be achieved also by using a naming convention: the name of the 
actual J2EE deployments, which MUST be compliant with JSR77, could also use 
the moduleType and moduleID additional properties.

This way, ApplicationDeployer "just" have to query the MBeanServer to 
retrieve the running ModuleType.WAR modules.

I think that the following methods of ApplicationDeployer could be 
implemented rather easily if one enforces these naming conventions:

public TargetModuleID[] getRunningModules(ModuleType moduleType, Target[] 
targetList);
public TargetModuleID[] getNonRunningModules(ModuleType moduleType, Target[] 
targetList);
public TargetModuleID[] getAvailableModules(ModuleType moduleType, Target[] 
targetList);
public void start(TargetModuleID[] moduleIDList);
public void stop(TargetModuleID[] moduleIDList);
public void undeploy(TargetModuleID[] moduleIDList);

The BIG issue of this solution is that it is based on naming conventions not 
really easy to enforce.

Another solution is to implement a "standard" monitoring infrastructure in 
order to register and track the available J2EE modules.

Any preference? Any other idea?

Gianny

_________________________________________________________________
High-speed Internet access as low as $29.95/month (depending on the local 
service providers in your area). Click here.   https://broadband.msn.com

Re: JSR77 -> JSR88

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

	First of all, I think the ApplicationDeployer needs to be involved
when things are auto-deployed as well as JSR-88 deployed.  So it should be
involved in every deployment (at least to the degree that it can track
them if it wants to).  I belive the module type and target(s) must be
conveyed here.  However, the level of "involvement" is still open
(notifications or direct invocations or whatever).  While naming 
conventions are convenient, I don't want to rely on that for basic 
operational requirements.

	Second, I think JSR-77 should be essentially responsible for 
tracking the "state" of the objects.  So if JSR-88 needs to know which 
deployments are in which states, it could look up the deployment MBeans 
and the inquire as to their state.  It might be nice to use notifications 
here too, so JSR-88 doesn't *have* to poll, but I don't think that's a 
requirement.  And when JSR-88 gets a request to change the state of an 
object, I think it will just call the JSR-77 method to do so.

Aaron

On Thu, 9 Oct 2003, gianny DAMOUR wrote:
> Hello,
> 
> 
> It seems that by now we do not have a clear idea of how to "connect" JSR77 
> and JSR88.
> 
> For instance, when a J2EE module is deployed by dropping it in the 
> "auto-deploy" folder, ApplicationDeployer (invoked remotely by a JSR88 
> client in order to perform various deployment operations) needs to be 
> notified. Also, when the JSR77 state of this module changes, 
> ApplicationDeployer needs also to be notified.
> 
> ApplicationDeployer needs to be notified in order to track the state 
> (running, stopped), the type (EJB, WAR, EAR et cetera) and various other 
> pieces of information.
> 
> Multiple solutions could be implemented in order to "sync" the JSR77 and 
> JSR88 models.
> 
> And this is a possible one only based on naming conventions:
> 
> Whatever the type of deployment, a MBean matching the pattern 
> "*:role=DeploymentUnit,url=" + ObjectName.quote(url.toString()) + ",*" MUST 
> be created. This is a requirement of the DeploymentController.
> 
> This naming convention could be extended to also include a moduleType 
> property, if the deployment is a J2EE module. The value of this property is 
> the ModuleType.toString value of this J2EE module.
> 
> Moreover, JSR88 requires a unique module ID and this module ID could also be 
> an additional property (this is even suggested by the specifications).
> 
> For instance, if one drops a WAR in "auto-deploy", then the name of the 
> deployment unit could be:
> geronimo.deployment:role=DeploymentUnit,url=test,moduleType=war,moduleID=1
> 
> This way, ApplicationDeployer "just" have to query the MBeanServer to 
> retrieve all the ModuleType.WAR modules.
> 
> ApplicationDeployer also needs to retrieve the state of these J2EE modules 
> and this can be achieved also by using a naming convention: the name of the 
> actual J2EE deployments, which MUST be compliant with JSR77, could also use 
> the moduleType and moduleID additional properties.
> 
> This way, ApplicationDeployer "just" have to query the MBeanServer to 
> retrieve the running ModuleType.WAR modules.
> 
> I think that the following methods of ApplicationDeployer could be 
> implemented rather easily if one enforces these naming conventions:
> 
> public TargetModuleID[] getRunningModules(ModuleType moduleType, Target[] 
> targetList);
> public TargetModuleID[] getNonRunningModules(ModuleType moduleType, Target[] 
> targetList);
> public TargetModuleID[] getAvailableModules(ModuleType moduleType, Target[] 
> targetList);
> public void start(TargetModuleID[] moduleIDList);
> public void stop(TargetModuleID[] moduleIDList);
> public void undeploy(TargetModuleID[] moduleIDList);
> 
> The BIG issue of this solution is that it is based on naming conventions not 
> really easy to enforce.
> 
> Another solution is to implement a "standard" monitoring infrastructure in 
> order to register and track the available J2EE modules.
> 
> Any preference? Any other idea?
> 
> Gianny
> 
> _________________________________________________________________
> High-speed Internet access as low as $29.95/month (depending on the local 
> service providers in your area). Click here.   https://broadband.msn.com
>