Reference Information for Developers
The message broker supports the AMQP 1.0 broker role. In its simplest form, this means that the message broker only accepts AMQP connections and never initiates them. A summary of where the Solace PubSub+ message 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 a message 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:
- Mapping AMQP Terminology to Solace Terminology
- Mapping AMQP Messages to SMF Messages
- Topic Syntax
- Mapping AMQP Addressing to Solace Queues & Topics
- Delayed Message Consumption
If you're reading through the AMQP protocol specification it's important to note how certain key AMQP terms map to equivalent message broker terms. The following table shows how they correspond.
|AMQP Term||Solace Term||Comments|
|Container||Client or message broker|
|Connection||Client Object||Every connection from a container outside the message broker is represented by a unique client object.|
|Session||N/A||There is no visible session concept on the message broker; however, a "session" is automatically created after a client is successfully authenticated and a transport link between the client and message 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.|
Native AMQP wire-line messages are accepted by the message 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.
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 SMF Topics syntax.
In the AMQP 1.0 protocol specification, the address field is used to identify the source and target of a link. On a message broker, the address is either:
- the name of a queue.
- a topic in SMF format
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 Message Consumption. If you're going to use delayed message consumption, keep in mind that AMQP 1.0 sets every message as DMQ Eligible.