This document is meant to facilitate discussion of the design of the AS 7 domain management features. It is not a list of requirements; for that see the requirements document. The intent of this document is to focus more on how we see those requirements being realized.

(Note: this document includes embedded images, in image formats. At least the initial ones come from the MagicDraw tool; the underlying MagicDraw file is attached. Going forward this should end up in version control somewhere, perhaps in an sharable format like XMI.)

The Logical Model

In this section, we define the logical representation of the domain management model. First an image, followed by some definitions

Agreed Definitions:

Following are definitions for items in the above model or related concepts, as agreed in various discussions. However, people are still welcome to challenge these.

• Domain: Set installed images required to run N applications using the same version family of JBoss AS, ESB etc (single project) managed by one or more administrators/users.
• Version Family: A version family is any project release with the same major version  number, e.g. 5.0.0, 5.0.1, 5.1.0, 5.1.1, 5.2.0, etc are all the same version family.
• Multi-Domain: Two or more domains, encompassing hundreds of domains, thousands of  instances, and multiple XYZs (Not shown on the above diagram as multi-domain management is beyond the scope of the domain management model.)
• ServerGroup: User defined set of server instances that will be managed and configured as one.  All members must be at the same platform version and have the same application(s) and  all their dependencies.
• Cluster: Server group with group communication services configured.
• Server: One JBoss AS, ESB, etc instance (JVM process), that must belong to only one server  group.
• ActionGroup: User defined set of manageable property or properties within a single  domain that will be managed as one.
• Profile: The set of subsystems that are included in the server group configuration along with the deployment repository reference. A profile can include one or more other profiles provided that there is no logical conflict (two definitions of the same subsystem)
• DomainController: The authoritative source of domain content and changes.
• Subsystem: A typed block of domain configuration, with it's own namespace that is tied to some grouping of services. Example subsystems include remoting, xnio, web, etc.
• Extension: A component which can add subsystems to the domain configuration.
• Module: A class-loading space, typically 0..1 jars that define the visibility rules for a set of classes and packages. There is no implied service model or subsystem configuration with a Module, it is purely a grouping of classes that can be referenced somehow in the domain.

Physical Deployment

This section focuses less on the logical model and more on how the runtime components of the model map to the physical infrastructure on which a domain runs. For more on how some of these concepts are going to be used, see this page on server lifecycle use cases.

Agreed Definitions:

Following are definitions for  items in the above model or related concepts, as agreed in various  discussions. However, people are still welcome to challenge these.

• Host: An OS instance that can contain one or more Servers, ServerGroups, Clusters, Domains. (Comment: a Host 'contains' ServerGroups, Clusters or Domains in the sense that it can contain multiple Servers which may be associated with different ServerGroups, Clusters or Domains. Further, all Servers associated with a ServerGroup, Cluster or Domain may be running on the same Host.)
• Server: see above in "Logical Model" section. Here we are referring to a running Server process.
• Provisioning: Installing a new binary of a runnable instance of a Server.
• Patching: Notification and installation of fixes against a server, server  group/cluster.
• Patches: Content containing fixes for servers.
• InstalledImage: Content (binaries, configuration and miscellaneous resources) that is physically installed on a particular Host (see Provisioning) that allows one or more Servers to function. An Installed Image only contains content associated with a single Domain. Multiple Servers may share the same Installed Image. (Comment: we need to clarify how writeable areas relate to this.) A Host may contain multiple InstalledImages, either associated with different Domains, or associated with the same Domain (for use by different Servers).
• Domain Controller: A role played by a Host Controller process that is responsible for managing the domain. An AS instance running in domain mode will have most one Host Controller process instance acting as a DomainController. All persistent management operations will be performed against the DomainController. Other Host Controller processes will be subservient to the DomainController. If no Host Controller is acting as a domain controller, all Servers in the domain will continue to work, but no  administration will be possible until a DomainController becomes available. Other Host Controller process might be able to assume the DomainController role, provided they have a complete copy of the domain.
• Process Controller: (formerly known as Process Manager) a very lightweight process whose primary function is to spawn Server processes and Host Controller Processes and manage their stdio streams. This would be a very simple piece of code. The intent is to increase the resiliency of the Server processes by not having their parent process be a complex one like the Host Controller. This also allows the Host Controller to be patched and restarted without impact the associated Servers.
• Host Controller: (formerly known as Server Manager) A process which is responsible for coordinating with a Domain Controller to control the lifecycle of Server processes (via the process controller), the distribution of deployments from the Domain Controller to the Server instances, and the management of the Installed Image. (Comment: this definition subsumes the DomainSynchronizer concept mentioned below.)
• MasterRepository: Component to which the DomainController delegates the management of the master copy of all content used by any Server in the domain. Any content in any InstalledImage is synchronized (via the DomainController and a Host Controller) with the content in the MasterRepository before a Server is allowed to boot. (Note that the requirements document will describe rules for an "assumed synchronization" in cases where no DomainController is available.)

A couple notes on the above image:

1. The Host that is running the DomainController does not include other components like Host Controller, InstalledImage. This is both for simplicity and because how the bootstrap of the DomainController itself will work is as yet undiscussed.
2. The Host that is running the DomainController can of course also run other Servers.

Standalone Server

The above Physical Deployment section is oriented toward a more complex, multi-server topology. However, there is another significant type of use case that AS 7 needs to handle well: the single, standalone server that needs to be individually managed. Such a server would be appropriate for use cases where the end user does not want a complex managment infrastructure with separate domain controller and host controller processes:

• Developer usage
• Embedded AS (a special case of developer usage)
• Production deployments where the end user is comfortable scripting against the management API exposed by a standalone server, and handling the multi-server coordination themselves

Logical Model:

Internally, the object model representing the domain configuration for a standalone server may be quite similar to that shown above. However, the XML configuration schema and perhaps the management API will be simplified to remove extraneous concepts like the ServerGroup. (Whether creating a distinct management API for this use case is appropriate needs discussion. A separate API means clients like JON and the embedded console need to be coded against two APIs in order to cover all use cases.)

Physical Topology:

For the standalone server use case, all processes shown on both hosts in the Physical Topology image shown above will be collapsed into a single process. The ProcessController becomes irrelevant. In this use case, the DomainController component represents the management capability the standalone server exposes.

Domain Model Schema

See the JBossAS Domain Schema document for the current metadata schema.