Bit of a brain dump here. Any comments on my wrongheadedness would be much appreciated. :) When I think about what the clustering services inside the AS will be doing with clustered deployments, I see two main things: 1) Keeping repositories in sync if people are using individual local filesystem repos on each node. This task is minor/optional/secondary, but I include it for completeness. 2) Coordinating deployments around the cluster as the ProfileService running on each node becomes aware of changes in the repository. Ensure each node is aware of the change, use a configurable policy to execute the deployment (e.g. sequentially or simultaneously), extend any 2PC deployment capability the profile service exposes to a cluster-wide operation. This is the more significant task. Keeping repositories in sync ------------------------------------ Again, this is IMHO the less meaningful task, but one that seems pretty straighforward. Only relevant if the repository is the local filesystem, not enabled by default (even in an 'all' config). 1.As with deployers/ and deploy/ there is a scanner that reads a set of URIs (e.g. farm/) and presents deployments to the ProfileService 2.On startup before presenting deployments to ProfileService it reconciles the state of farm/ with the cluster, brings over added deployments not available locally, brings over modified deployments, removes deployments previously removed from cluster but still present locally. 3.After startup, no longer presents things to the ProfileService; the profile service is responsible for scanning for changes itself. 4.After startup, however, it continues to scan the farm/ dir for purposes of noticing changes and replicating them around the cluster. Coordinating deployments ---------------------------------- Here things get more fuzzy. "Coordinating" basically means either a) controlling the initiating of the deployment process on each node, or b) somehow pausing it in the middle and exchanging messages around the cluster until the cluster-wide state is appropriate and then resuming, or c) some combination of both. To me using a) implies some variant of the HDScanner concept -- i.e something that periodically queries the Profile for modified deployments and then invokes on MainDeployer to undeploy the old version and deploy the new version. Looking at the MainDeployer API it looks like it exposes enough methods for pretty fine grained control of this; e.g. the change(String, DeploymentStage) method implies the ability to walk things through deploy/undeploy step by step. Using b) implies writing a specialized Deployer(s) that does coordination in the deploy()/undeploy() methods. That seems conceptually wrong to me; i.e. a bit outside of the scope of what a deployer should be doing. An advantage of doing it in a Deployer is the possibility of using metadata that an earlier deployer could make available. For example, a bean annotated with @Farm or a war with a special tag in jboss-web.xml could be cluster-deployed without needing to be associated with DeploymentPhase.APPLICATION_CLUSTERED. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152451#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...