Chapter 1. Overview

AMQ Broker is a full-featured, message-oriented middleware broker. It offers specialized queueing behaviors, message persistence, and manageability. Core messaging is provided by Apache ActiveMQ with support for different messaging styles such as publish-subscribe, point-to-point, and store-and-forward. It supports multiple protocols and client languages, freeing you to use many if not all of your application assets. Lastly, AMQ Broker is supported to work with Red Hat JBoss Enterprise Application Platform.

AMQ Broker is based on Apache ActiveMQ Artemis.

1.1. Key Features

  • Clustering and high availability options
  • Fast, native-IO persistence
  • Fully transactional (including XA support)
  • Written in Java for broad platform support
  • Choice of Management Interfaces: AMQ Console and/or API

1.2. Supported Standards and Protocols

  • Supports multiple wire protocols

    • AMQP 1.0
    • Artemis Core Protocol
    • HornetQ Core Protocol
    • MQTT
    • OpenWire (Used by AMQ 6 clients)
    • STOMP
  • Supports JMS 2.0

1.3. Supported Configurations

Refer to the article "Red Hat JBoss AMQ 7 Supported Configurations" on the Red Hat Customer Portal for current information regarding AMQ Broker supported configurations.

1.4. Document Conventions

This document uses the following conventions for the sudo command and file paths.

The sudo Command

In this document, sudo is used for any command that requires root privileges. You should always exercise caution when using sudo, as any changes can affect the entire system.

For more information about using sudo, see The sudo Command.

About the Use of File Paths in this Document

In this document, all file paths are valid for Linux, UNIX, and similar operating systems (for example, /home/...). If you are using Microsoft Windows, you should use the equivalent Microsoft Windows paths (for example, C:\Users\...).

1.5. Key Concepts

Messaging brokers allow you to loosely couple heterogeneous systems together, while typically providing reliability, transactions, and many other features.

Unlike systems based on a Remote Procedure Call (RPC) pattern, messaging systems primarily use an asynchronous message-passing pattern with no tight relationship between requests and responses. Most messaging systems also support a request-response mode, but this is not a primary feature of messaging systems.

Designing systems to be asynchronous from end to end allows you to really take advantage of your hardware resources, minimizing the number of threads blocking on IO operations, and to use your network bandwidth to its full capacity. With an RPC approach you have to wait for a response for each request you make so are limited by the network round-trip time, or latency, of your network. With an asynchronous system you can pipeline flows of messages in different directions, so you are limited by the network bandwidth, not the latency. This typically allows you to create much higher performance applications.

Messaging systems decouple the senders of messages from the consumers of messages. The senders and consumers of messages are completely independent and know nothing of each other. This allows you to create flexible, loosely coupled systems.