David Lloyd wrote:
If the domain.xml does, indeed, contain the authoritative representation of the domain, then it does indeed need to contain, directly or indirectly, definitions of all serivces available up to and including the list of active deployments. For example, as defined in the existing requirements, a deployment can be associated with one or more server groups, which are defined as part of the domain. If the domain doesn't map deployments to server groups, what will? In addition, adding deployments can very well imply other changes to domain.xml that are necessarily made at the same time. Everything I see in the requirements says to me that the current deployment listing must be a part of the domain model.
This opens the door to new ideas. If the domain.xml (including deployment listing) represents the current state of the domain, and server managers (SM) sync this down, why not make it a versioned database? Then, if a SM comes up after some changes were made on the domain controller (DC), the SM can pull down only the differences, just like database replication. This is good in the case of a very complex configuration with many deployments (the SM only has to pull down deployments that it needs [as defined by the domain.xml] and that it doesn't already have). It may also allow something like atomic deployment, where multiple deployment units and/or config changes are deployed as a single unit. Also, the coolest thing of all would be the ability to revert the whole domain to arbitrary previous states, by simply playing the log backwards.
If the differences prove too great (either in size or in age) to pull in diffs, then the whole state can always be pulled down into the SM.