分类：
2009-10-22 17:06:54
The Advanced Message Queuing Protocol (AMQP) is an application layer protocol specification for asynchronous messaging. Being built as a wire-level protocol instead of an API (like e.g. JMS) AMQP clients should be capable of sending and receiving message regardless of their respective vendors. As of now there are already quite a number of serverand clientimplementations on multiple platforms available.
While the original use case for the AMQP was to provide an interoperable messaging protocol for the financial industry the current standard aims to provide an universal construction kit for generic message queue architectures. In that sense concepts of message-oriented middleware (MOM) systems such as publish/subscribe queues are not implemented directly as first class citizens. Instead users are given the means to establish such concepts by wiring relatively simple AMQ entities together. These entities are also part of the specification and form a layer on top of the wire level protocol: the AMQP model. This model unifies messaging patterns such as the before mentioned publish/subscribe, queues, transactions and streaming while adding extra capabilities such as easily extensible, content-based routing.
Publish/subscribe in this context means the decoupling of producers and consumers: producers do not need to know based on what criteria consumers will receive messages. Queues are the structures holding messages in a first-in, first-out fashion. Routing encapsulates the decision which message will eventually turn up in the messages queues present in an asynchronous messaging system.
In this introduction I will try to illustrate the concepts introduced by this model using an AMQP client implementationwritten by Aman Gupta in Ruby. It uses a event-driven architecture (based on EventMachine) and therefore may look and work a bit unfamiliar. However the design of the API shows the correspondence between the AMQ model entities in a very straightforward fashion and should be of value even for programmers not familiar with the Ruby language.
It should be noted that there are at least three more Ruby clients available , , . One of those clients, Carrot, has been explicitly written to get back to non-event-driven, synchronous Ruby while preserving much of the clean style in which the event-driven Ruby API is written.
The AMQP server used in this article is the RabbitMQ server written in Erlang. It is an implementation of the release 0-8 of the AMQP specification, targeting 0-9-1 in the near future.
One last thing before getting started: asynchronous messaging is a very common and widespread technology, ranging from the various instant messenger protocols such as Skype or XMPP/Jabber to the good old email. These services all share a couple of traits:
-They carry messages with some more or less arbitrary content (e.g. an email containing text and a PowerPoint presentation about office jokes) and some routing information (e.g. an email address) which is somewhat more formalized.
-They are asynchronous which means they have to decouple producer and consumer and thus may have to queue messages (e.g. someone sends you a chat message but you are offline or your mailbox receives an email).
-The producer and the consumer are distinct roles with different knowledge. I do not need to know your IMAP username and password in order to send you an email. In fact I don’t even need to know if you email address is an alias or a “real" address let alone that you use IMAP to access your mails. This distinction also means that a producer does not control which content is actually read/being subscribed to – exactly like my email application chooses to drop most of the unsolicited medical adverts that are send hourly to my mailbox.
The fact the AMQP is an abstract protocol (in the sense that it does not address one specific use case) does not make things much more complicated. On the contrary: the Internet made the metaphors and patterns of messaging ubiquitous. People generally are used to them and asynchronous messaging solves many problems in a straightforward and scalable fashion. As soon as the initial learning roadblock has been overcome modelling asynchronous messaging architectures in AMQ will not add any unnecessary complexity to it.
In order to get started with the examples you probably need to install some software. If you already have Ruby running on your system this should take less than 10 minutes. The RabbitMQ site also carries a lot of information to get you started as soon as possible. You will need:
-The Erlang/OTP package. See for download and for installation instructions.
-The RabbitMQ broker. See for download and for installation instructions.
-A Ruby VM. If there is no Ruby interpreter installed on your platform of choice you will probably want to download the Ruby MRI VM. See for download options and installation instructions.
-Two Ruby "gems" (packaged libraries). The gem utility should be distributed along with your Ruby installation.
- Update the gem utility itself if you did a fresh install/are
not sure if it’s current or not. Type gem update --system. On BSD/UNIX
systems you might need to perform this (and the following operations)
as superuser.
- Tell gem to search for packages on the Github site: gem sources -a
- Install the AMQP gem: gem install tmm1-amqp. This should also install the event-machine gem.
Now all you need to do is to start the RabbitMQ server.
There are several entities described in the AMQ specification. One way to distinguish between them is whether they are configured by the server administrator or if they are declared on the fly by clients.
The configured entities are:
- The message broker server itself which listens to AMQ messages e.g. on a TCP/IP socket.
-The virtual host which partitions a message brokers data into distinct sets, very much alike the virtual host concept in webservers such as the Apache http daemon.
- The user which connects to a virtual host using credentials.
.........................详情请看原文
