
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.