Jason Greene [
http://community.jboss.org/people/jason.greene%40jboss.com] modified the
document:
"Domain Management Model Design"
To view the document, visit:
http://community.jboss.org/docs/DOC-15215
--------------------------------------------------------------
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
http://community.jboss.org/docs/DOC-15098 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.)
h2. The Logical Model
In this section, we define the logical representation of the domain management model.
First an image, followed by some definitions
http://community.jboss.org/servlet/JiveServlet/showImage/102-15215-11-296...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15215-11...
h4. 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.
h2. 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
https://community.jboss.org/docs/DOC-15303
this page on server lifecycle use cases.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15215-11-389...
http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15215-11...
h4. 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).
* *DomainController*: A role played by a ServerManager process that is responsible for
managing the domain. An AS instance running in domain mode will have most one
ServerManager process instance acting as a DomainController. All persistent management
operations will be performed against the DomainController. Other ServerManager processes
will be subservient to the DomainController. If no ServerManager 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 ServerManager process might
be able to assume the DomainController role, provided they have a complete copy of the
domain.
* *Process Manager*: a very lightweight process whose primary function is to spawn Server
processes and ServerManagerProcesses 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 ServerManager. This also allows
the ServerManager to be patched and restarted without impact the associated Servers.
* *ServerManager*: A process which is responsible for coordinating with a Domain
Controller to control the lifecycle of Server processes (via the process manager), 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 ServerManager) 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
ServerManager, 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.
h2. 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 server manager 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
h4. 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.+)
h4. 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 ProcessManager
becomes irrelevant. In this use case, the DomainController component represents the
management capability the standalone server exposes.
h2. Domain Model Schema
See the
http://community.jboss.org/docs/DOC-15403 JBossAS Domain Schema document for the
current metadata schema.
--------------------------------------------------------------
Comment by going to Community
[
http://community.jboss.org/docs/DOC-15215]
Create a new document in JBoss AS7 Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=102&am...]