JBoss7配置指南(二)

3 核心管理概念

 

3.1 运行模式

 

JBoss Application Server 7可以被启动到两个不同的模式.域模式可以用来运行和管理多个jboss服务器的拓扑， 或者是单服务器模式，仅运行一个服务器的实例

 

3.1.1 单服务器模式

对于大多数的使用来说，通过管理域实现的中心管理能力是不需要的。对于这些使用场景，一个jboss7的实例可以被运行成单服务器模式。一个单服务器的实 例是一个独立的进程，像JBoss3 ,4,5 或6的实例，可以通过standalone.sh或者standalone.bat进行启动。

如果需要多个服务器的实例或者多服务器的管理，那么就需要用户来协调管理多个服务器。比如:在所有的单服务器上部署一个相同的应用，用户需要在每台服务器 上进行操作。更为可能，用户会启动多个单独运行的服务器来组成高可用的集群，就像是使用JBoss 3, 4 5和6那样。

3.1.2 管理域

JBoss7一个最重要的新特性就是可以通过一个管理点来管理多个JBoss7服务器实例.一个域包含一个DomainController进程（域的中心管理点），这些被管的服务器是这个域的成员。
在这个域里所有的服务器实例共享统一的管理策略，域控制器来保证每个服务器都使用这一管理策略来配置。域可以横跨几个物理（或者虚拟)机器，所有的 JBoss7服务实例运行在一个受HostController进程控制的给定主机（host)上。一个HostController的实例会被配置成为 中心的DomainController.在每个主机上的HostController可以与DomainController进行交互来控制运行在自己 主机(host)上服务器实例的生命周期，并且帮助DomainController来管理。
当你通过domain.sh或者domian.bat来在一个主机上运行JBoss7管理域时，那么你的意图是去运行一个HostController， 并且一般是至少运行一个JBoss7的服务器实例,而且在主机上的HostController应该被配置来充当DomainController.

下图是一个管理域的拓扑:

 

3.1.2.1 Host(主机)

上图中的每个Host方框代表一个物理或者虚拟的主机。一个物理的主机可以包含零个，一个或者多个服务器实例(server instance)。

3.1.2.2  主机控制器(HostController)

当domain.sh或者domain.bat在主机上运行时，一个叫HostController的进程也会被启动。HostContoller只负责 管理服务器实例；它不会处理服务器实例的日常工作。HostController负责在自己的主机上启动停止单个服务器实例的进程，并且与 DomainController进行交互来管理这些服务器实例。

HostController默认在主机文件系统中JBoss7安装目录下读取domain/configuration/host.xml文件。host.xml文件主要包含特定主机的信息:
主要是:

    在安装要运行的JBoss7服务器的实例名     关于HostContraller如何与DomainController联系，并且注册到DomainController种来获取配置的信息。这个配 置信息可以是如何查找联系一个远端的DomainController,或者是告诉HostController本身就可以充当 DomainController.     特定于本地安装的各种配置信息，如在domain.xml里(见以下内容)中interface的配置信息可以被映射成host.xml中的IP地址信息。在domain.xml中的抽象路径信息可以被映射成host.xml的真实文件系统信息。

3.1.2.3 Domain Controller(域控制器）

一个HostController的实例被配置成整个域的中心管理点，就成为了DomainController.DomainController的主 要负责维护域的管理策略，保证所有的HostController能够获取目前的配置信息，以及协同HostController来保证运行的服务器实例 都根据当前的策略来配置。中心管理策略默认存储DomainController安装主机的domain/configuration /domain.xml中。

domain.xml必须位于运行Domain Controller Jboss7安装目录下的domain/configuration. 如果不作为Domain Controller运行的AS7则不需要这个文件;比如运行连接到远程DomainController的HostController的服务器。但不 作为DomainController运行HostController的AS7安装中存在这个文件，也不会有影响。

domain.xml文件包括各种配置，在Domain下的JBoss7的实例可以配置各种profile去运行。一个profile的配置包含各种组成 profile的subsystem的详细配置信息(比如，一个集成的jboss web实例就是一个subsystem,一个JBoss TS的事务管理器也是一个subsystem）.Domain的配置信息也包括在subsystem需要用到的socket组的定义。Domain配置信 息也包含Server group的定义。

3.1.2.4 Server Group (服务器组)

Server group是一组被统一管理和配置的服务器实例。在一个管理域里，每个服务器实例都是服务器组的一个成员(即使是一个组里只有一个服务器，这个服务器仍然 是一个组的成员)。Domain Controller和Host Controller会保证在一个server group里所有的server具有一致的配置。这些服务器被配置成同样的profile,并且部署相同的内容。

一个domain可以有多个server group.上面的图示种给出了两个server group： "ServerGroupA"和“ServerGroupB"。不同的Server group可以被配置成不同的profile和部署不同的内容:比如在一个domain在不同层的服务器来提供不同的服务。不同的Server group也可以运行同样的profile，部署相同的内容；比如对应用进行升级时候，为了避免整个服务不可用，可以首先对一个server group中应用进行升级,然后再对另外一个sever group升级。

sever group定义的例子如下:



   
   
       
       
   


一个server-group的配置包含以下不可缺省的属性:

    name -- server group名    profile -- server运行在的profile名

另外，还有以下可选配置:

    socket-binding-group -- 定义在server group中用到的默认的socket binding group名， 可以在host.xml里覆盖。如果在server-group里没有定义，那么必须在每个server的host.xml里定义。     deployments -- 在组服务器要部署的内容。    system-properties -- 组服务器种要设置的所有的system properties    jvm -- 在组服务器种默认的jvm设置。Host Controller将会合并在host.xml里提供的属性，并且用这些属性来启动服务器的JVM.详细配置信息选项请参考JVM配置。

3.1.2.5 Server (服务器）

在上述图表中的server表示一个实际的应用服务器实例。Server运行于独立域HostController的JVM进程中。Host Controller负责启动这一JVM进程。(在管理域里，终端用户不能直接从命令行里启动一个server进程).

HostController合并整理domain.xml里的域配置信息和从host.xml上获得的主机配置信息.


3.1.3 决定运行在单独服务器或者管理域上

什么用例适合管理域，什么适合单独服务器(standalone server)？管理域协调多个服务器的管理--通过JBoss7提供的中心节点，用户可以管理多个服务器,通过域管理的丰富功能来统一服务器的配置，通 过协调方式将服务器配置变更(包括部署内容）在各个服务器上生效。
重要的是要理解选择管理域和单独服务器要根据你的服务器是如何管理的,而不是根据为终端用户请求提供什么样服务的能力。管理域和单独服务器的差别对于高可 用集群也是十分重要的。理解高可用性对于运行的单独服务器和管理域是正交的。也就是说,一组单独服务器可以被配置成为高可用性集群。管理域和单服务器模式 决定服务器是如何管理的，而不是他们所提供的功能：

所以,考虑到以上原因:

  如果只有一个服务器，运行在域模式下不会有更多的好处,运行在单服务器模式下是更好的选择。   对于多服务器生产环境，运行在域模式和单服务器模式下取决于用户是否想使用管理域提供的中心管理。某些企业已经开发出自有成熟的多服务器管理方式，并且能够轻松协调管理多个单独服务器。读于这些企业，由多个单独运行服务器组成的多服务器架构是一个好的选择。   单服务器更适合与大多数的开发环境。任何在管理域下运行的服务器的配置都可以在单服务器模式运行的服务器获得,因此即使应用是将来要运行在域管理模式的生产环境中，很多(几乎是全部)开发都可以在单服务器模式下进行。

 

  运行管理域对于一些高级的开发是有帮助的。比如:需要多JBoss7服务器实例之间进行交互的开发。开发人员会发现配置多个服务器作为域成员是进行多服器集群的有效方式。

3.2 通用的配置概念;

以下通用的配置概念对于管理域模式和单服器模式都适用:

3.2.1 Extensions(扩展)

一个扩展(是一个能扩展服务器功能的模块）. JBoss 7的内核是简单清量级的。所有用户需要用到应用服务器的功能都是通过扩展提供的。一个扩展被打包成为在modules目录下的一个模块。用户如果需要一个 特别的扩展，则需要在domain.xml或者standalone.xml里加入 xml元素来指明这个模块名。

    [...]
   
   
   
   


3.2.2 Profile和subsystem(子系统 )

在domain.xml和standalone.xml配置中最重要的部分是一个(在standalone.xml)或者多个(在domain.xml 里)profile的配置。一个profile是一个命名的子系统集合。一个子系统是使用一个扩展添加到和服务器核心的一组功能(参考以上的扩展)。一个 子系统可以提供处理servlet的功能;一个子系统可以提供EJB容器，一个子系统可以提供JTA，等等。一个profile是命名的子系统的列表,并 且包含各个子系统详细的配置信息。 一个服务器拥有大量子系统的profile会提供丰富的功能.一个拥有数量少并且功能专注的子系统提供的功能相应减少，但是具有更少的内存消耗。

domain.xml和standalone.xml里关于profile的配置看上去大致相同，唯一的不同是standalone.xml只允许有一个 profile的xml元素(服务器运行的proifle）,但domain.xml可以有多个profile,每一个profile可以映射到一个或者 多个服务器组。

domain.xml和standalone.xml里关于子系统的配置是相同的。

3.2.3 Paths(路径)

路径是一个文件系统路径的逻辑名。在doamin.xml,host.xml和standalone.xml配置种都包含用来来声明路径的部分。其他的配 置可以通过逻辑名来引用这些路径，而不需要包含路径的所有全部信息(在不同的机器都不相同).比如: logging子系统的配置包含对jboss.server.log.dir路径的引用来指向server的log目录:



JBoss7自动提供一系列的标准路径，而不需要用户在配置文件中配置.

    jboss.home - JBossAS安装的跟目录
    user.home - 用户的home目录
    user.dir - 用户当前的工作路径
    java.home - java安装路径
    jboss.server.base.dir -  一个服务器实例的跟目录
    jboss.server.data.dir - 服务器存储数据的目录
    jboss.server.log.dir - 服务器日志文件目录
    jboss.server.tmp.dir - 服务器存储临时文件目录
    jboss.domain.servers.dir -host Controller在此目录为服务器实例创建的工作区(仅在管理域模式下)

用户可以通过在配置文件中使用xml元素来增加自己的路径或者覆盖除了上面前五个路径的配置。




Path的属性：

    name -- 路径名
    path -- 实际的物理文件系统名,如果没有relative-to的定义，将会被处理成为绝对路径.
    relative-to -- (可选)前面定义的路径名，或者系统提供的标准路径。
domain里配置不可以包含path和relative-to属性,只需要name属性。



上面这个配置的示例简单的说明:有意个叫"x"的路径，在domain.xml配置的其他部分可以引用。指向x的实际文件系统的路径是主机相关的，需要在 每个机器的host.xml里定义。如果这种在domain.xml里定义path的方式被使用，那么在每个机器上host.xml里都需要path来有 定义实际的文件系统路径:

在standalone.xml里都必须包含实际文件系统的路径信息。 

3.2.4Interfaces (接口)

接口就是对socket可以绑定到的一个物理接口,IP地址或者主机名的逻辑命名。domain.xml,host.xml和 standalone.xml的配置信息种都包行有接口声明的部分。其他部分的配置可以根据这些逻辑名来引用这些接口,而不需要包含这些接口全部详细的信 息(这些接口信息在不同的机器上不尽相同)。一个接口的配置包含接口的逻辑名，也包含解析这个接口名成为真实物理地址的信息。详细信息请参考接口和端口部 分。

在domain.xml里元素只需要name属性,不需要包含任何真实IP地址的信息:


这样一个配置简单的表明:"有一个叫internal的接口在domain.xml的其他部分可以引用。指向internal的IP地址是和主机相关的， 地址信息将会在每台机器的host.xml里指定。"如果使用这一方法，那么在每台机器上的host.xml里必须有interface元素来指定IP地 址:


  


在standalone.xml里的元素必须包含IP地址信息。

3.2.5 socket binding(socket绑定)和socket binding group(socket绑定组)

socket绑定是对一个socket命名的配置。
在doamin.xml,和standalone.xml配置种都包含用来来声明socket命名的部分。其他的配置可以通过逻辑名来引用这些socket，而不需要包含socket的所有全部信息(在不同的机器都不相同).请参考interfaces和ports部分。

3.2.6 System Properties(系统属性)

系统属性值可以在domain.xml, host.xml和standalone.xml里的多个地方设置.standalone.xml里设置的值会成为server启动进程的一部分。在domain.xml和host.xml设置的值将在serer启动时生效。

当在domain.xml或者host.xml里设置的一个系统属性，它是否能够最终被应用生效取决于它在什么地方被配置。如果系统属性作为在 domain.xml里根节点下的一个子孙节点被设置，那么它将在所有的server上生效。如果在domain.xml中里的设置，那么它将在这个组里所有的server生效。在host.xml里根节 点下作为一个子节点设置系统属性，那么它将在这个主机的host controller控制的所有server上生效。最后,在host.xml中里的设置，那么它将在只在那个sever上生效。同样的属性可以被配置在多个地方: 中的值要优先于在host.xml根节点中直接定义的值，host.xml里定义的值要优先于任何domain.xml里的值，里定义的值要优先于通过domain.xml里根节点里定义的值。

3.3 Management resources(管理资源)

当JBOss7在启动的时候解析配置文件，或者当使用AS7的管理接口的时候，都是在增加，删除或者修改AS7内部管理模型的管理资源。AS7的管理资源具有以下特征:

3.3.1.1 Address (地址)

所有JBossAS的管理资源都以树的结构进行组织。指向一个管理资源树节点的路径就是管理资源的地址。每个资源地址的片段都是键值对:
    键是在双亲上下文中资源的类型.因此，单服务器模式运行的服务器根资源就有以下类型的子孙:子系统，接口，socket绑定等等。提供AS7web服务器 能力的子系统就有类型是connector和virtual-server的子孙。提供AS7 消息服务器的子系统就有jms-queue和jms-topic类型的子孙节点。

   值给定类型特定资源的名字。比如:子系统里的web或者messaging, 子系统connector里的http或者https.
   管理资源的全路径是一个排好序的键值对的列表,这个地址可以指从资源数的根指向这个资源。地址中使用"/"来分割地址元素，使用"="来分割键和值:

    /subsystem=web/connector=http
    /subsystem=messaging/jms-queue=testQueue
    /interface=public

如果使用HTTP API,那么"/:来分割键和值而不是"=":

    http://localhost:9990/management/subsystem/web/connector/http
    http://localhost:9990/management/subsystem/messaging/jms-queue/testQueue
    http://localhost:9990/management/interface/public

3.3.3.2 operations(操作)

查询更改一个管理资源的状态要通过一个操作。一个操作具有一下特征:

字符串名: 零个或者多个命名的参数.每个参数都有一个字符串名和一个类型是org.jboss.drm.ModelNode值(或者当通过 CLI调用时，ModelNode用文本内容表示，通过HTTP APi调用时候，model node用JSON对象表示)。参数是可选的: 返回值也是一个类型是org.jboss.dmr.ModelNode的值(或者当通过 CLI调用时，ModelNode用文本内容表示，通过HTTP APi调用时候，model node用JSON对象表示)。 除了根节点的资源，每个资源应该有一个remove操作("这里应该是因为在AS7.0时很多资源都没有)。 add操作的参数会根据资源而不同。remove操作没有参数:

全局的操作都适用于所有的资源.详细内容请参考全局操作部分。

一个资源所支持的操作可以通过调用这个资源本身的一个操作获得:read-operation-names.一旦知道了操作的名，关于操作的参数和返回的 详细信息就可以通过调用read-operation-description来获得。比如，在单独运行服务器上获取根节点资源所支持的操作名,然后得到 一个操作全部的详细信息，在CLI中可以通过以下来获得:

[standalone@localhost:9999 /] :read-operation-names                                
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "shutdown",
        "take-snapshot",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "write-attribute"
    ]
}
[standalone@localhost:9999 /] :read-operation-description(name=upload-deployment-url)   
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "upload-deployment-url",
        "description" => "Indicates that the deployment content available at the included URL should be added to the deployment content repository. Note that this operation does not indicate the content should be deployed into the runtime.",
        "request-properties" => {"url" => {
            "type" => STRING,
            "description" => "The URL at which the deployment content is available for upload to the domain's or standalone server's deployment content repository.. Note that the URL must be accessible from the target of the operation (i.e. the Domain Controller or standalone server).",
            "required" => true,
            "min-length" => 1,
            "nillable" => false
        }},
        "reply-properties" => {
            "type" => BYTES,
            "description" => "The hash of managed deployment content that has been uploaded to the domain's or standalone server's deployment content repository.",
            "min-length" => 20,
            "max-length" => 20,
            "nillable" => false
        }
    }
}
如何获取一个资源所支持的操作请参考以下Description部分。

3.3.3.3 Attributes(属性)

管理资源将它们的状态暴露成为属性。属性有string类型名，和一个类型是org.jboss.drm.ModelNode值(或者当通过 CLI调用时，ModelNode用文本内容表示，通过HTTP APi调用时候，model node用JSON对象表示)。
属性可以是只读或者是可读写的。读写属性值可以通过全局的read-attribute和write-attribute操作来进行。
read-attribute操作仅有一个"name"参数，它的值是这个atrribute的名。比如在sorkcet-binding资源里通过CLI来读port属性:


[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:read-attribute(name=port)
{
    "outcome" => "success",
    "result" => 8443
}
如果一个属性是可写的，资源的状态可以通过write-attribute操作来改变。这个操作接受两个参数:

    name – 属性名
    value – 属性值

比如在sorkcet-binding资源里通过CLI来设置port属性:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=https:write-attribute(name=port,value=8444)
{"outcome" => "success"}

属性可以有两种存储类型:

    CONFIGURATION –  表示属性值保存在持久化的配置中，比如管理资源配置要从这些文件读取的:domain.xml,host.xml或者standalone.xml.
    RUNTIME – 表示属性之日仅仅保存在运行的服务器中而不是持久化的配置中。 比如一个metric(如已经处理的请求数)十一个RUNTIME属性一个典型的例子。

管理资源暴露出的所有属性值可以通过"read-resource"操作再加上“include-runtime=true"的参数来获得，比如通过CLI:

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "bytesReceived" => "0",
        "bytesSent" => "0",
        "errorCount" => "0",
        "maxTime" => "0",
        "processingTime" => "0",
        "protocol" => "HTTP/1.1",
        "requestCount" => "0",
        "scheme" => "http",
        "socket-binding" => "http",
        "ssl" => undefined,
        "virtual-server" => undefined
    }
}

省略include-runtime（或者设置成false)来限制仅仅存储在持久化配置上的值才被输出。

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                             
{
    "outcome" => "success",
    "result" => {
        "protocol" => "HTTP/1.1",
        "scheme" => "http",
        "socket-binding" => "http",
        "ssl" => undefined,
        "virtual-server" => undefined
    }
}

参考一下Description相关部分来获取更多关于一个特定资源暴露出属性的信息。

3.3.3.4 Children（子节点)

管理资源可以支持子资源。一个资源孩子节点的类型(比如web子系统资源的connector子节点)可以通过查询资源的description来获得 (参考以下Description部分)或者通过调用"read-children-types"操作。当你知道了子节点的类型，你就可以通过全 局"read-children-types"操作和已知节点类型来获得全部子节点名。这个操作仅接受一个参数类型:child-type,它的值即使已 知的子节点类型。比如，一个表示socketbinding 组的资源有孩子节点。使用CLI来获得这些子节点的类型和给定类型所有的资源:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets:read-children-types
{
    "outcome" => "success",
    "result" => ["socket-binding"]
}
[standalone@localhost:9999 /] /socket-binding-group=standard-sockets:read-children-names(child-type=socket-binding)
{
    "outcome" => "success",
    "result" => [
        "http",
        "https",
        "jmx-connector-registry",
        "jmx-connector-server",
        "jndi",
        "osgi-http",
        "remoting",
        "txn-recovery-environment",
        "txn-status-manager"
    ]
}

3.3.3.5 Descriptions(描述)

所有的管理资源都暴露用于描述管理资源属性，操作和子节点类型的元数据(metadata).通过调用一个或者多个被管理资源所支持的全局操作来获取.以 上我们给出了 read-operation-names, read-operation-description, read-children-types 和 read-children-names操作的例子。 
read-resource-description 操作用来获得一个资源属性，子节点的详细信息。比如,通过CLI:

[standalone@localhost:9999 /] /socket-binding-group=standard-sockets:read-resource-description
{
    "outcome" => "success",
    "result" => {
        "description" => "Contains a list of socket configurations.",
        "head-comment-allowed" => true,
        "tail-comment-allowed" => false,
        "attributes" => {
            "name" => {
                "type" => STRING,
                "description" => "The name of the socket binding group.",
                "required" => true,
                "head-comment-allowed" => false,
                "tail-comment-allowed" => false,
                "access-type" => "read-only",
                "storage" => "configuration"
            },
            "default-interface" => {
                "type" => STRING,
                "description" => "Name of an interface that should be used as the interface for any sockets that do not explicitly declare one.",
                "required" => true,
                "head-comment-allowed" => false,
                "tail-comment-allowed" => false,
                "access-type" => "read-write",
                "storage" => "configuration"
            },
            "port-offset" => {
                "type" => INT,
                "description" => "Increment to apply to the base port values defined in the socket bindings to derive the runtime values to use on this server.",
                "required" => false,
                "head-comment-allowed" => true,
                "tail-comment-allowed" => false,
                "access-type" => "read-write",
                "storage" => "configuration"
            }
        },
        "operations" => {},
        "children" => {"socket-binding" => {
            "description" => "The individual socket configurtions.",
            "min-occurs" => 0,
            "model-description" => undefined
        }}
    }
}

注意在上述例子中的输入:"operations" => {}"。如果命令行已经包含参数operation=true,(比如 /socket-binding-group=standard-sockets:read-resource- description(operations=true))，那么操作的结果会包含这个资源所支持的每个操作的描述。

关于被管理资源上运行read-resource-description和其他全局操作所支持的其他参数的详细信息，请参考全局操作部分。

3.3.2 和JMX Beans相比:

JBossAS管理的资源在概念上和Open MBeans极为相似。他们有一下主要的几点不同:

    JBossAS的管理资源通过树形结构进行组织。资源地址的键值顺序是不同的，因为它定义了被管理资源在数形结构上的位置,而JMX ObjectName的key属性顺序不是很重要。     Open MBean属性的值，操作参数的值和操作的返回值，必须是JDK规定的简单类型(String,Boolen,Integer等等) 或者实现了javax.management.openmbean.CompositeData 或者 javax.management.openmbean.TabularData的对象。JBossAS管理资源的 属性值，操作参数值和操作的返回值都是org.jboss.dmr.ModelNode类型。

3.3.3 管理资源树的基本结构(management resource trees)

如同以上提到的，被管理资源以树形结构组织。数的结构决定于你运行在单服务器模式还是管理域模式。


3.3.3.1 单服务器模式(Standalone server)

单服务器模式下管理树的树形结构和standalone.xml配置文件的十分相似:

根节点资源:    
        extension – 在服务器上安装的扩展。
        path – 服务器上可用的路径。
        system-property – 配置文件中设置的系统属性 (如不在命令行种设置的属性)
        core-service=management –  服务器中核心的管理服务。
        core-service=service-container – JBoss7的最核心资源JBoss MSC ServiceContainer
        subsystem – server上安装的子系统.大部分的管理模型都是子系统类型的子节点。
        interface – 接口配置
        socket-binding-group – server上socket绑定组的中心资源
        socket-binding – 单个socket绑定的配置
        deployment – server上已经部署的内容

3.3.3.2 管理域模式 (managed domain)

在管理域模式下，管理资源树会跨越整个域，包含域范围的配置(如在domain.xml上定义的配置),和主机相关的配置(如在host.xml配置的内 容)以及每个运行应用服务器暴露出的管理资源。在管理域中Host Controller进程提供对整个资源树的访问.如果Host Controller是主Domain Controller，那么资源树中对于每个主机相关信息都是可得到的,如果Host Controller是远程Domain Controller的从属(slave)，那么仅与Host Controller所在的host相关部分的资源树的是可以访问的。

整个域的根资源如下。这些资源包括它的子孙，除了host类型都会被持久化到domain.xml中。
        extension – 域模式上运行的扩展。
        path – 在域中可用的路径。
        system-property – 配置文件中设置的系统属性 (如不在命令行种设置的属性),可以在整个域里使用
        profile – 一组子系统的设置，可以分配给server group
        subsystem – 子系统的设置,可以组成profile.
        interface – 接口配置
        socket-binding-group – socket绑定组设置，可以被sever group使用。
        socket-binding – 单个socket绑定的配置
        deployment – 可用的部署内容，可以分配给sever group. deployments available for assignment to server groups
        server-group – server group配置
        host – 单独的Host Controller.每个host类型的节点都代表是特定主机的根资源。host和host的子孙节点的配置会被持久化存储到主机的host.xml文件中。
            path – 主机服务器上可用的路径
            system-property – 主机服务器配置文件中设置的系统属性
            core-service=management –  Host Controller的核心管理服务。
            interface – 可以被Host Controller和主机上服务器使用的接口配置。
            jvm – 用来启动服务器的JVM设置
            server-config –  配置HostController如何启动sever;配置使用什么server group，和覆盖在其他资源上定义的和服务器相关的配置项。 
            server – server的根资源.sever和一下资源不会直接被持久化； 在域范围和主机级别的持久化的yuan ,组成了server的配置。
                extension – 在服务器上安装的扩展。
                path –  服务器上可用的路径。
                system-property –  配置文件中设置的系统属性 (如不在命令行种设置的属性)
                core-service=management –  服务器中核心的管理服务。
                core-service=service-container – JBoss7的最核心资源JBoss MSC ServiceContainer
                subsystem –  server上安装的子系统.大部分的管理模型都是子系统类型的子节点。
                interface – 接口配置
                socket-binding-group –  server上socket绑定组的中心资源
                    socket-binding – 单个socket绑定的配置
                deployment –  server上已经部署的内容