Messaging is the basis of many enterprise integration patterns and has been a central piece of application architecture for decades. Regardless of age, messaging technology is on the rise because of cloud and mobile applications. Messaging patterns provide a loosely-coupled communication mechanism for software components. These patterns enable the software components to process different tasks in an asynchronous manner. This loose coupling eases business process changes and can improve application scalability and resiliency.

Messaging middleware, also known as Message-Oriented Middleware (MOM), is responsible for application message management and delivery. MOMs typically provide features such as security, routing, guaranteed delivery, classes of services, and transactions.

MOMs can be embedded within other products, much like the way Red Hat JBoss Enterprise Application Platform (JBoss EAP) 7 embeds a MOM based on ActiveMQ Artemis. A MOM can also be a standalone server, requiring its own specialized management, tuning, and clustering.

For example, consider the checkout process for a web store that triggers the following actions:

These actions take time to process, so executing within a checkout request means users might have a long wait for order confirmation. However, these actions do not necessarily need to be performed right away. In other words, they can be performed asynchronously.

For example, the checkout action could instead send a message to a payment application and return to the user instantly. Similarly, once the payment is confirmed, then a message could be sent to an inventory component. Finally, the delivery component could initiate its tasks upon receiving a message.

With such an architecture, each action is potentially handled by separate components. This spreads the capacity needs amongst all of the components and potentially reduces system-wide bottlenecks.

Even if an action cannot be completed right away, then the action can be postponed without canceling the entire process or an alternative process flow can be triggered. This adds resistance to issues outside of the organization, as well. For example, an transient error from an external payment processor does not require failure of the entire order.

The Java Message Service (JMS) is a specification for Java components to send and receive messages without being directly connected to one another. JMS provides a standardized API for accessing MOM services, much like JDBC provides a standardized API for accessing relational databases. JMS also defines common semantics that a MOM is expected to follow. This relieves applications from being dependent on particular product idiosyncrasies.

The JMS API is based on the following resource types:

JMS refers to both queues and topics as destinations. Many message operations, such as sending a message, apply to both queues and topics.

Applications refer to destinations by using a JNDI name. This name is under the control of the application server administrator, which facilitates message redirection without changing application source code. This eases business process changes for features implemented via messaging.

JMS ConnectionFactories are also referenced by using a JNDI name. This way applications can be directed to different MOMs, or even different products. Developers commonly do so by way of connecting the application to an embedded MOM during development, but to an external MOM in production.

The following are the current messaging offerings from Red Hat:

For more information about these messaging products, see the references section.

The messaging server embedded in JBoss EAP incorporate components from ActiveMQ Artemis, and leaves other components out, such as those that provide support for the STOMP and AMQP protocols. Native client libraries for languages other than Java are also absent in JBoss EAP.

From a product standpoint, Red Hat intendeds for JBoss EAP messaging to be a general messaging and integration platform. Meanwhile, Red Hat AMQ and Red Hat AMQ Streams are intended as complete JMS messaging server solutions.

Although some Jakarta EE application server vendors provide an embedded JMS server that is only for development and small scale production use, this is not the case for JBoss EAP. Because JBoss EAP JMS server has a focus on the Jakarta EE ecosystem, it does not support every available protocol. However, it provides full enterprise support, and is capable of dealing with high-performance and critical production scenarios.

To use Red Hat JBoss AMQ instead, you must install the AMQ JCA Resource Adaptor and configure JMS connection factories.

ActiveMQ Artemis is the messaging-activemq subsystem embedded into JBoss EAP 7. ActiveMQ is managed by using the management CLI and console.

Activating the messaging-activemq subsystem implies using either the standalone-full.xml or standalone-full-ha.xml configuration files for standalone server mode, or either the full or full-ha profiles for managed domains.

The subsystem contains two child objects in the default JBoss EAP 7 configuration, exemplified by the following CLI command:

[domain@127.0.0.1:9990 /] /profile=full/subsystem=messaging-activemq:read-resource
{
    "outcome" => "success",
    "result" => {
        ...output omitted...
        "jms-bridge" => undefined,
        ...output omitted...
        "server" => {"default" => undefined},
        ...output omitted...
    }
}

The jms-bridge contains bridges that automatically transfer messages between the embedded JMS server and any other JMS server known by the JBoss EAP 7 domain. This also includes servers from other vendors. The standard configuration files do not provide a default bridge.

The server=default is the embedded JMS server. It contains a number of attributes and child objects that configure all MOM aspects, such as JMS resources, networking, storage, and clustering.