Architecture and features

According to an IDC study on the business value of Red Hat JBoss EAP in 2014, it appears that JBoss EAP:

• Increased the number of business applications developed per year by 70%
• Reduced the time per application developed by 35% per week
• Reduced the instances of unplanned downtime per Year by 80%
• Reduced the time to resolve planned downtime incidents (hours)

This is certainly due to the JBoss architecture which seems to be mostly acclaimed because of the following characteristics:

• JBoss EAP is a modular and lightweight application server
• An EAP server is a collection of modules or extensions
• An extension defines one or more subsystems
• A subsystem is a set of capabilities added to the server by an extension
• A server is started with one profile
• A profile is a collection of subsystems available to the server running the profile

In configuration files, extensions are referenced as follows:

<extension module="org.jboss.as.jmx"/>
<extension module="org.jboss.as.jpa"/>
<extension module="org.jboss.as.jsf"/>

Subsystems configuration and settings are specific to the profile to which they relate:

<subsystem xmlns="urn:jboss:domain:jmx:1.3">
   <expose-resolved-model/>
   <expose-expression-model/>
   <remoting-connector/>
</subsystem>
<subsystem xmlns="urn:jboss:domain:jpa:1.1">
  <jpa default-datasource="" default-extended-persistence-    inheritance="DEEP"/>
</subsystem>
<subsystem xmlns="urn:jboss:domain:jsf:1.0"/>

By default, the EAP comes with four predefined profiles:

• default: The default profile embeds the most frequently used subsystems, including logs, ejb3, security, and weld
• ha: The ha profile extends the default profile subsystem list with clustering capabilities offered by the JGroups subsystem
• full: This is similar to the default profile, but it notably adds the messaging (HornetQ) subsystem (as well as a few other subsystems)
• full-ha: This is the same as full profile, but it includes clustering features from the JGroups subsystem

The server can be started using two different modes: standalone or domain mode. The standalone mode is ideal for running a single server instance with a single server. As soon as you have a collection of server instances and want to be able to manage all the instances from a single location, the domain mode is recommended.
In a domain mode topology, server configuration is centralized in the domain.xml file; on the contrary, in the standalone mode, each standalone instance has its standalone.xml configuration file.