Brian Stansberry wrote:
Excellent question! We need to agree on the definition of some terms.
To me a "domain" is a set of servers meant to be managed as a unit (acknowledgment: how things are "managed as a unit" is vague/fuzzy; a key task is to clarify exactly what that means.) The servers don't need to all have a homogenous profile, as people may wish to tier things. (In example above written for the clustering meeting the "DataGrid" profile was meant to describe a bunch of servers running Infinispan to serve as large scale grid storage behind a JEE tier.)
I see a domain as needing to allow multiple clusters, even ignoring the different tier idea. Mutliple clusters are a useful mechanism for a rolling upgrade; you subdivide your overall capacity into N smaller clusters, and then can upgrade those by taking a cluster at a time off line. This is needed instead of a rolling upgrade of 1 server at a time within the same cluster if the new version of the app can't co-exist with the old in the same cluster (e.g. incompatible state).
I have a slightly simpler definition, but is essentially the same as what you are describing. I used it in req 1:
"A domain is a management policy that applies to one or more servers/nodes, which may or may not be part of a cluster"
In other words, the only thing that every member of the domain has in common is the fact that they have the same domain.xml file. A better definition would probably be. "A domain is a management policy that applies to one or more servers/nodes, which may or may not be part of a homogenous group". When you think about it, a server-group, and a cluster are really the same thing, the only difference is that the cluster has an additional set of services that a basic group does not. This was what I meant by the cluster-service tag, a way to specify how a group would cluster a particular service (maybe not all services should be clustered). Although it was just something I through out there as an example. A better way likely exists