Concepts

Chapter 1 - Amqp concepts

This chapter has a brief introduction to Amqp and other introductory material

Amqp is a wire level messaging protocol that sits at the same level in the "conceptual network layering model" (i.e. OSI) as HTTP - it sits on top of the TCP protocol. TCP is a fully asynchronous communications channel between 2 peers, protocols that sit on top of TCP define which side gets to read and write under what circumstances and a what time in order to prevent chaos. The Amqp protocol defines a set of commands and messages that go between consumers, producers, and brokers. RabbitMQ is a broker (and there are others), while consumers and producers are both "clients", although the distinction isn't absolute - a client can be both a consumer and a producer.

Amqp allows for bi-directional messaging, this is more complex than in HTTP, where servers receive requests and send responses, and clients send requests and receive responses. An Amqp client application can operate in a "server-like" way by waiting indefinitely for incoming messages - this kind of application would be a "consumer". Incoming messages which the consumer processes are sent by the broker, there is no direct connection between producers and consumers. An Amqp producer application would connect to a broker and send messages, but the protocol doesn't require the broker to acknowledge or respond to these messages. In some cases the broker will respond, this behaviour can be switched on by setting particular messages parameters. Thus, the Amqp broker queues messages that are sent by producers and delivers these to consumers. The Amqp protocol defines both "run time" messaging semantics and "broker configuration commands", and the Amqphp library exposes all Amqp messages.

Amqp protocol messages (i.e. "run time messages" and "broker configuration commands") are defined in an XML document, these protocol messages are grouped in to classes, so when talking about Amqp messages I usually refer to (class).(method) e.g queue.declare. Amqphp uses this document to generate parts of the protocol implementation --this is the reason for using Phing-- unless you build the library by running the code generator against the XML document the library won't work. Many of the protocol messages are simple request response-like commands which follow a common pattern: Amqphp provides a common way of sending these messages:

$msg = $chan->$amqpClass($amqpMethod, array('p1' => 'p1 value'), "method payload (optional)");
$resp = $chan->invoke($msg);

The 2 steps are "create message" then "send message", if the message is synchronous (i.e. has a response type) then the response message is returned from the second step, in this example in $resp. The first line uses the \amqphp\Channel class to create an Amqp message (here $amqpClass and $amqpMethod can be any valid Amqp message as defined in the XML spec) and the second line sends the message to the broker. If the message that you create has a defined response (such as such as queue.declare) then invoke call waits for the corresponding response message from the broker (this is returned in $resp), otherwise it returns immediately (as for basic.publish). Amqp messages can also have "parameters" (analogous to HTTP headers, again defined in the XML spec), each message type has it's own pre-defined set of parameters, you specify these in Amqphp by providing an associative array of name / value pairs when creating a message (i.e. the first line above has parameter p1 with value "p1 value").

Next Chapter: Api Overview

Documentation home