Reference Information for Developers

The event broker supports the AMQP 1.0 broker role. In its simplest form, this means that the event broker only accepts AMQP connections and never initiates them. A summary of where the Solace PubSub+ event broker implementation differs from the AMQP 1.0 specification can be found on the AMQP 1.0 Protocol Conformance page.

For instructions on how to administer and configure the AMQP service on an event broker, refer to AMQP 1.0 Messaging Management.

The next sections will discuss some information that could be useful to if you're developing applications that interact with Solace's AMQP implementation:

AMQP Concepts

If you haven't used AMQP and Solace PubSub+ together before, you might want to look at the AMQP section of the Overview: How Apps Interact with PubSub+ Messaging Components page. It'll take you on a tour of the PubSub+ event broker's messaging components, and explain at a high level how they make data move from producers to the broker, and from the broker to consumers, with AMQP.

Mapping AMQP Terminology to Solace Terminology

If you're reading through the AMQP protocol specification it's important to note how certain key AMQP terms map to equivalent event broker terms. The following table shows how they correspond.

AMQP Term Solace Term Comments
Container Client or event broker  
Connection Client Object Every connection from a container outside the event broker is represented by a unique client object.
Session N/A There is no visible session concept on the event broker; however, a "session" is automatically created after a client is successfully authenticated and a transport link between the client and event broker is successfully established for data exchange.
Link (inbound) Ingress Flow All ingress links of a given connection are implemented with a single common ingress flow.
Link (outbound) Egress Flow Each egress link of a given connection is implemented with an individual egress flow.
Source (on broker) Queue or Topic-Endpoint Clients always receive from an endpoint.
Target (on broker) Topic or Queue or Topic-Endpoint Clients can send to a topic or endpoint.

Mapping AMQP Messages to SMF Messages

Native AMQP wire-line messages are accepted by the event broker and translated to their equivalent Solace SMF messages and internal object state. This transformation is transparent to the client on the other end of the connection.

An AMQP message is composed of several parts. AMQP formally categorizes more parts of its message than SMF, and this has implications on mapping inbound and outbound messages. If an inbound message cannot be mapped from AMQP to SMF, the link on which the message arrived will be closed with an error. If an outbound message cannot be mapped from SMF to AMQP, the specific field in the message will be dropped.

Topic Syntax

The topic syntax to be used by an AMQP implementation is not defined by the protocol, and it's left up to the client and broker implementations to define. The Solace AMQP implementation uses Solace Message Format Topics syntax.

Mapping AMQP Addressing to Solace Queues & Topics

In the AMQP 1.0 protocol specification, the address field is used to identify the source and target of a link. On an event broker, the address is either:

  • the name of a queue.
  • a topic in SMF format

Delayed Message Consumption

Delayed message consumption allows messages to be published at one time and consumed at some later time, where you specify the lag between publication and consumption. For instructions on how to set up and use the feature, refer to Delayed Delivery. If you're going to use delayed message consumption, keep in mind that AMQP 1.0 sets every message as DMQ Eligible.