Este conteúdo não está disponível no idioma selecionado.

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.

Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red Hat