Universal Messaging 10.11 | Concepts | AMQP | AMQP Guide | AMQP Frame Transport
 
AMQP Frame Transport
AMQP defines the following components with regard to frame transfers:
*Containers
*Connections
*Channels
*Sessions
*Multiplexing
*Nodes
*Links
*Link Credit
*Link Recovery
AMQP Containers
An AMQP container is an application that may send or receive messages. An example would be an AMQP message broker or an application using an AMQP client.
Another example would be an application using an AMQP client:
Or it could be an AMQP router, proxy or P2P container:
AMQP Connections
AMQP connections offer a reliably ordered frame sequence restricted by a negotiable maximum frame size, with idle timeout semantics.
Note:
In Universal Messaging, the maximum frame size for AMQP connections must be less than or equal to the UM maximum buffer size.
Note:
In Universal Messaging, the AMQP connection idle timeout semantics are mapped to native UM connection keep alive.
AMQP Channels
AMQP frame sequences are transferred over a negotiated numbered of unidirectional channels.
Note:
In Universal Messaging, the maximum number of AMQP channels per connection is 2, excluding the reserved control channel 0.
AMQP Sessions
An AMQP session binds two unidirectional AMQP channels to define an ordered bi-directional byte stream.
Note:
In Universal Messaging, AMQP sessions are logically mapped to UM sessions. As multiplexing is currently unsupported, an AMQP connection can only have a single session when connecting to a UM realm.
AMQP Multiplexing
AMQP sessions can be optionally multiplexed over a single AMQP connection.
Note:
In Universal Messaging, session multiplexing is not supported at the moment. There are plans to add support in a future release by mapping to native UM multiplexing.
AMQP Nodes
AMQP nodes are addressable logical endpoints with an AMQP container without any assumptions or requirements about the model (e.g. hierarchical, federated, graph etc).
Note:
In Universal Messaging, server side AMQP nodes can be either topics or queues but not data groups. As AMQP does not define any such semantics, a prefix model is widely adopted and supported by many vendors, including Software AG. Topic and queue nodes are expected to be prefixed with a configurable value agreed to imply node semantics (default: topic:// and queue:// respectively).
Furthermore, as Universal Messaging maps them to topic and queue stores respectively, if a prefix is not matched the default behavior will be honoured (see AMQP Plugin Configuration for related information). Finally please note that some AMQP client implementations choose to define AMQP target capabilities to indicate the node type; Universal Messaging will try to use these as hints by looking for topic and queue strings in the capability name.
AMQP Links
AMQP Links define a named path that defines a unidirectional flow between two AMQP nodes, the source and the target (e.g. a publisher application and a topic).
Note:
In a Universal Messaging realm, an incoming link to a topic or queue node is mapped to a publisher and an outgoing link to an application container is mapped to a subscriber.
Note:
An AMQP link from a sending or receiving AMQP application / container to a UM topic or queue store has a name equal to the absolute UM path (e.g. publishing messages to a topic node called /trades/gbp will flow over an incoming link to topic /trades/gbp named after the full path.
AMQP Link Credit
AMQP links manage flow through link credits, allowing the receiving side of the link to control how fast messages flow through it. This allows a broker slowing down a publisher as well as a subscriber for controlling memory usage, pre-fetching etc.
Note:
In Universal Messaging, if an AMQP link is created without requesting a specific link credit, a configurable default value (1000) is assigned by the UM realm (see AMQP Plugin Configuration for related information).
Note:
In Universal Messaging, all AMQP subscription flows are mapped to asynchronous consumers currently. As a result of that, link credit values < 100 will be honored at a best effort basis but cannot be guaranteed. We plan to improve on this in future versions of UM.
AMQP Link Recovery
AMQP links can have an independent lifetime from AMQP sessions and AMQP connections and can be recovered.
Note:
In Universal Messaging, a pair of AMQP links are coupled with a single AMQP session and a single AMQP connection at the moment, while link recovery has not been implemented yet.