The first step in JBoss world is to understand these terms and the relationship between each other: Modules, Extensions, Subsystems, and Profiles.
Let’s say that the definition of these terms is the same between Standalone and Domain mode. I will explain each term separately then I will show you the difference in terms of profiles management between Standalone and Domain mode.

Modules

A module basically provides code (Java Classes) to be used by EAP services and/or by applications. Modules are loaded into an isolated Classloader, and can only see classes from other modules when explicitly requested. In fact, all code running is run inside modules, I mean by code the code provided by the core and the Application code.

Moreover, an application can see a module that exposes a particular version of an API. So, an application developer may control this manually and it can be very useful. But by default, EAP 7 automatically decides which modules to expose to an application, based on its use of JEE APIs.

All modules available in an EAP 7 installation are folders inside JBOSS_HOME/modules:

• Modules for EAP 7 Product under: JBOSS_HOME/modules/system/layers/base folder.
• Modules for third-party products under: JBOSS_HOME/modules/system/layers folder.
• Local modules folders added by a system administrator should be under: JBOSS_HOME/modules.

Inside one of the module folders listed above, a module name is used to create a folder tree. For example, the module named:

• org.wildfly.extension.undertow is under JBOSS_HOME/modules/system/layers as org/wildfly/extension/undertow.
• com.oracle is under JBOSS_HOME/modules as com/oracle.

Extensions

A module that provides features and capabilities to the application server is called an extension, or let’s say that the extension is the reference of a module in .xml configuration files.
For example, the module org.wildfly.extension.undertow is referenced as below in the standalone.xml file:

<server xmlns="urn:jboss:domain:4.1">
    <extensions>
		...
		<extension module="org.wildfly.extension.undertow"/>
		...
	</extensions>
	...

So, Extensions are added to an EAP instance using the “extension” element, which appears at the beginning of the EAP main configuration files : standalone.xml or domain.xml.
Adding an extension to the configuration files does not make that extension module loaded and active, it make the extension available for management. For example, clustering configurations can be done if the related extensions are available, but the related modules will only be loaded and activated when an application that requires clustering services is deployed. Which is really a good point for JBoss!

Subsystems

An extension management model provides one or more subsystems. When an extension is added to an EAP instance, the capabilities and attributes of the subsystems provided by the extension management model are configured within the “subsystem” element in the EAP configuration file.
Most of the time, an extension module provides a single subsystem, but a subsystem use multiple extension modules… For example:

• org.wildfly.clustering.web.infinispan extention module is used by the infinispan subsystem, which use also using org.wildfly.clustering.server:

  <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
  	<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
  		...
  	</cache-container>
  	<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
  		...
  	</cache-container>
  	...
  

• org.jboss.as.clustering.jgroups extension module is used by the jgroups subsystem.

In fact, each subsystem has its own XML schema to define what is allowed within its element. All EAP 7 subsystem schema definitions can be found in the JBOSS_HOME/docs/schema folder:

[jboss@vmjboss ~]$ ls -rtl
total 8312
-rw-rw-r-- 1 jboss jboss   5604 Apr 18  2016 xml.xsd
-rw-rw-r-- 1 jboss jboss  33107 Apr 18  2016 wildfly-undertow_3_1.xsd
-rw-rw-r-- 1 jboss jboss  31295 Apr 18  2016 wildfly-undertow_3_0.xsd
-rw-rw-r-- 1 jboss jboss  26467 Apr 18  2016 wildfly-undertow_2_0.xsd
-rw-rw-r-- 1 jboss jboss  24042 Apr 18  2016 wildfly-undertow_1_2.xsd
-rw-rw-r-- 1 jboss jboss  22155 Apr 18  2016 wildfly-undertow_1_1.xsd
-rw-rw-r-- 1 jboss jboss  20317 Apr 18  2016 wildfly-undertow_1_0.xsd
-rw-rw-r-- 1 jboss jboss  54521 Apr 18  2016 jboss-as-infinispan_4_0.xsd
-rw-rw-r-- 1 jboss jboss  55506 Apr 18  2016 jboss-as-infinispan_3_0.xsd
-rw-rw-r-- 1 jboss jboss  55006 Apr 18  2016 jboss-as-infinispan_2_0.xsd
-rw-rw-r-- 1 jboss jboss  49219 Apr 18  2016 jboss-as-infinispan_1_5.xsd
-rw-rw-r-- 1 jboss jboss  48569 Apr 18  2016 jboss-as-infinispan_1_4.xsd
-rw-rw-r-- 1 jboss jboss  47823 Apr 18  2016 jboss-as-infinispan_1_3.xsd
-rw-rw-r-- 1 jboss jboss  47555 Apr 18  2016 jboss-as-infinispan_1_2.xsd
-rw-rw-r-- 1 jboss jboss  42567 Apr 18  2016 jboss-as-infinispan_1_1.xsd
-rw-rw-r-- 1 jboss jboss  42144 Apr 18  2016 jboss-as-infinispan_1_0.xsd
-rw-rw-r-- 1 jboss jboss  14994 Apr 18  2016 jboss-as-jgroups_4_0.xsd
-rw-rw-r-- 1 jboss jboss  14734 Apr 18  2016 jboss-as-jgroups_3_0.xsd
-rw-rw-r-- 1 jboss jboss   9042 Apr 18  2016 jboss-as-jgroups_2_0.xsd
-rw-rw-r-- 1 jboss jboss   7368 Apr 18  2016 jboss-as-jgroups_1_1.xsd
-rw-rw-r-- 1 jboss jboss   6558 Apr 18  2016 jboss-as-jgroups_1_0.xsd
...

All subsystems can be configured using the CLI or the Management Console, I don’t recommand the manual xml update especially in this case! The management tools will make the update properly when needed.

Profiles

A profile is a group of subsystems configurations, by default there are four predefined profiles can be used in Standalone mode and Domain mode:

• default: Is the basic subsystem but the most commonly used one, including logging, security, datasources, infinispan, weld, webservices, and ejb3…
• ha: Contains the exact same subsystems as the default profile, with the addition of clustering capabilities, provided mainly by the jgroups subsystem.
• full: Is similar to the default profile, but notably adds the messaging (messagingactivemq) and a few other less used subsystems.
• full-ha: Is same as the full profile, but with the addition of clustering capabilities.

Of course, you can create new profiles, either from scratch or cloned from the ones provided out-of-the-box.

Standalone vs Domain mode

As said before, four profiles are configured by default on Standalone and Domain mode, but where the profiles are configured is diffrent:

Standalone
In the JBOSS_HOME/standalone/configuration folder you can find four standalone configuration files:

• standalone.xml: which has the default profile configured.
• standalone-ha.xml: which has the ha profile configured.
• standalone-full.xml: which has the full profile configured.
• standalone-full-ha.xml: which has the full-ha profile configured.

By default the standalone.sh script will start an instance with default profile so using standalone.xml, if you want to start an instance with another profile you have to give the .xml configuration file as parameter, to use full-ha profile:

$JBOSS_HOME/bin/standalone.sh --server-config=standalone-full-ha.xml

So a standalone server instance can easily be started with more or less subsystems available, it is up to you to choose the needed profile.

Domain
In the domain the story is a little bit different, four profiles mentioned before exist in the domain.xml file:

<profiles>
    <profile name="default">
		... <!-- Subsystems configuration -->
	</profile>
    <profile name="ha">
		... <!-- Subsystems configuration -->
	</profile>
    <profile name="full">
		... <!-- Subsystems configuration -->
	</profile>
    <profile name="full-ha">
		... <!-- Subsystems configuration -->
	</profile>
</profiles>

Then when you create a server group you need to specify a profile, which will be the same for all servers in this group.

I hope that this blog will help you to understand the terms evoked (Modules, Extensions, Subsystems, and Profiles) and relationships between them. If any question remain don’t hesitate to ask 🙂