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 Artemis 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
- Supports local transactions
- Supports XA transactions when using AMQ Core Protocol JMS and AMQ OpenWire JMS clients
- Written in Java for broad platform support
- Multiple management interfaces: AMQ Console, Management APIs, and JMX
1.2. Supported Standards and Protocols
Supports multiple wire protocols
- AMQP 1.0
- Artemis Core Protocol
- HornetQ Core Protocol
- MQTT
- OpenWire (Used by A-MQ 6 clients)
- STOMP
- Supports JMS 2.0
The details of distributed transactions (XA) within AMQP are not provided in the 1.0 version of the specification. If your environment requires support for distributed transactions, it is recommended that you use the AMQ Core Protocol JMS.
1.3. Supported Configurations
Refer to the article "Red Hat 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.
