I believe that we may need a layered deployment mechanism. This does not
change the architecture of deployment, just adds more deployment goals and
adds more detail to what deployment planners for WEB/EJB modules must do.
Let me explain what my problem is, how I understand the current deployment
system works, and what my proposed solution is.
My problem relates to security modules that need to be re/deployed before
and must be undeployed after the WEB/EJB modules that they service.
It's my understanding that the DeploymentController gets a bunch of
DeploymentGoals in the form of DeployURLs and starts "randomly" passing them
around various registered DeploymentPlanners. These DeploymentPlanners
opportunistically eat the goals and spit out plans. If I add a
SecurityDeploymentPlanner, there is no guarantee that there will be any
DeployURLs left by the time the DeploymentController gets to it. Even if
there was a way to guarantee that the SecurityDeploymentPlanner, there is no
way to pass information on to the WEB/EJB deployers to ensure the proper
start/stop dependency.
One solution is to not have a SecurityDeploymentPlanner and have the WEB/EJB
deployers generate plans for the security modules. I don't like that
solution since I don't like the tight coupling.
Another solution is to add more goals for module deployment. Maybe
something like
StartDeploy -> SecurityDeploymentPlanner -> ModuleDeploy ->
WEB/EJBDeploymentPlanner
| |
V V
SecurityPlans
ModulePlans
The ModuleDeploy goal would contain enough information for the modules so
that the proper start/stop order is maintained. The idea is that the start
goal is not the same as the goal that modules deployment planners eat. This
will allow any number of layers to be configured, w/ no additional
programming.
Thoughts?
Regards,
Alan
----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com
Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit <http://www.reuters.com/messaging>
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of The
Reuters Group.
