JBoss Enterprise Application Platform 6 is modular and flexible, with an unlimited number of configuration and deployment options depending on your environment.
These chapters do not cover every single management options or task possible through JBoss ON. Rather, they cover tasks or configuration that are unique to EAP 6 or that require special consideration when used to manage EAP 6.
32.1. The Structure of JBoss EAP 6
The key features of JBoss EAP 6 are a modular class-loading structure and a domain framework which centralizes configuration in a single controller. These two features have one big asset in common: flexibility. The idea is to start with a small, lightweight application server and then add in the modules for the desired functionality and the server instances for a naturally distributed system.
JBoss ON works within the changeability of that system to bring clarity into how those modular, distributed resources are related and to provide an extra skin of both administrative control and information visibility.
JBoss ON imposes a hierarchy and structure on JBoss EAP 6 installation, but before you can have an idea of how that structure is applied, it helps to have an understanding of the order that EAP 6 itself has.
32.1.1. "Classic" Structure: Standalone Servers
Most of the functionality for the JBoss EAP 6 server is implemented through independent classes or subsystems. Which subsystems a server uses, and their configuration properties or configured instances, are defined in a profile.
A standalone instance for EAP 6, much as in EAP 5, is a collection of those defined subsystems, a set of socket bindings to define communications, network interfaces, and other settings.
The entire server instance is defined in its
standalone.xml file. Almost every entry in that file is identified as a child of the server. For example, these subsystem entries create the ee and jmx child resources for the server:
Likewise, socket bindings, network interfaces, and deployed content, which are defined in the configuration file, are discovered as resources.
Subsystems like datasources and logging configuration can have multiple instances defined; these are all configured as child resources of the subsystem. Because of the modular nature of the EAP 6 server, the exact subsystems — and therefore the exact children in JBoss ON — vary with the subsystem and other definitions in the configuration file.
Overall, because of the number of subsystems and other configuration settings, the standalone server has a very wide, flat, and shallow inventory tree. JBoss ON imposes little additional hierarchy on the standalone server structure. It reflects the way the server is configured in
Figure 32.1. Standalone Server Configuration
Management and operations for the standalone server are self-contained. Every child node for the standalone server combines both its configuration and its runtime environment (monitoring, alerting, and operations) in the same location. To change the configuration for a datasource, for example, edit the datasource entry directly. Every standalone server is managed independently of any other server, even in the same cluster or the same machine.
All of this is comparable to the structure and functionality of a JBoss EAP 5 server, with some slight differences in the organization of the inventory.
32.1.2. Separating Configuration and Real-Time Operations: Domains
The structure of the domain is entirely different, in a way that embraces a more modular design.
A domain divides the application server into two conceptual halves: server configuration and runtime operations.
Configuration is centralized into the domain controller. The domain controller defines the profile and subsystem configurations, JVM settings, interfaces, and other settings in a single place.
The functions of the application server are carried out by managed servers, which can be installed on multiple machines. These managed servers do not define their own configuration (with a handful of exceptions); they accept the profile structures from the domain and serve the web applications deployed through the domain.
There is a secondary level of organization domains and managed servers called server groups. Server groups are defined as part of the domain configuration. They create environments for managed servers; they are configuration nodes, in a sense. A domain can have multiple profiles, JVM definitions, and web applications; it is a central repository of all possible configuration. Only specific configuration and content is assigned to a server group, and that specific configuration is what is applied to the managed servers.
Figure 32.2. Simple Domain Structure
The domain configuration is defined in the
domain.xml file. This lists all of the configured profiles and subsystems, server groups, socket binding configuration, system properties, deployments, and other settings. As with the standalone server, almost every entry is discovered and added to the inventory as a resource. For example, this creates a server group resource, with a child deployment resource and a child JVM resource for the server group.
Example 32.1. Server Group domain.xml Entry
<server-group name="main-server-group" profile="full">
<heap size="1303m" max-size="1303m"/>
<deployment name="sample2.war" runtime-name="sample2.war"/>
The instances that carry out the operations are identified in the
host.xml file. These managed servers have virtually no configuration of their own; they simply point back to the original server group configuration to use in the domain.
<server name="server-one" group="main-server-group"/>
<server name="server-two" group="other-server-group">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
The domain, through its profiles and its server groups, defines the overall configuration. The managed servers are workers under that configuration. This division between configuration and operation, particularly the emphasis on the functionality of the domain as a whole rather than any individual member, is reflected in the EAP 6 management console. The Profile and Servers areas manage domain configuration, while Runtime displays current statistics and deployed web applications. The focus is always on domain configuration and domain information.
Figure 32.3. EAP 6 Console
Managing domain resources in JBoss ON is less about managing the configuration than it is managing information. One of the strengths of the JBoss ON inventory structure is that is exposes the components of the domain very clearly and helps delineate the relationships between those resources.
Figure 32.4. Domain Resources
For example, the entry for a managed server lists all of the subsystems defined in its server group's profile, it lists its host controller definition, and it lists managed web applications deployed on it (through the server group). This consolidates all of the configuration information that is applied to that one worker instance, which makes the monitoring information on that managed server more valuable.
There is a shade of artificiality in the JBoss ON inventory in order to maintain the domain relationships. The domain is a single, overarching entity, but the components of the domain can span multiple platforms and resources on those platforms. The domain controller is considered the parent resource for all domain resources, regardless of their platform. This is hinted at in Figure 32.5, “Domain Components in the JBoss ON Inventory”
. The domain controller is on Platform 1, so even though a host controller and two managed servers are on Platform 2, the host controller and managed resources are shown as children of the domain resource (on Platform 1).
Figure 32.5. Domain Components in the JBoss ON Inventory
32.1.3. EAP 6 Resources in JBoss ON
Every EAP 6 configuration area in
standalone.xml is interpreted as a resource type. Because EAP 6 draws a distinction between configuration components and operational components, the EAP 6 resource types in JBoss ON do different things; some resources define configuration, while others are used for monitoring, alerting, and operations.
In domains, profiles, socket bindings, and network interfaces for the domain are all configuration entries. Therefore, in JBoss ON, the corresponding resource types define configuration settings.
In domains, the managed servers are the functional instances. These resources are active, so, in JBoss ON, the managed server resources can run operations, monitor metrics, and trigger alerts.
There is no overlap between the configuration resources and the operational resources in functionality. For example, a datasource resource under a profile has configuration, but no monitoring or alerting. A datasource under a managed server collects the monitoring metrics, defines alerts, and runs operations. These resources are related — the managed server datasource resource references the configuration in the profile datasource — but they are different.
In standalone servers, configuration and management are enabled in the same resource. A standalone server is basically a combination of a profile resource (configuration) and a managed server resource (management). A datasource resource for a standalone server, then, has both configuration and monitoring, alerts, and operations on the same resource.
32.1.4. The Purpose of Managing EAP 6 Resources with JBoss ON
The JBoss ON UI maintains parity with the EAP 6 console, so it can be used to edit most configuration settings, create child entries, and deploy content, same as the EAP 6 management console.
The purpose of JBoss ON management, though, is not to have yet another web UI to use. JBoss ON maintains a larger perspective on the resources within the domain. This infrastructure-wide perspective reveals the relationship of a resource within the domain, the larger IT structure, and even itself and its own history aside from simply making a current configuration change.
Standalone servers and domains in JBoss ON are organized in a way that highlights the information that is available to administrators:
Additional monitoring metrics for resources, with stored historical data, resource-specific operational baselines, and alternate display types
Configuration and connection setting histories
Inventory change histories when children are added or removed through JBoss ON
Package versioning and repositories for controlled package updates
Configuration, monitoring, and alerting for underlying and associated resources, like the platform, Apache and Tomcat web servers, and plug-ins like mod_cluster