Network based messaging

Levi Pearson levi at cold.org
Mon Jul 28 22:45:00 MDT 2008


Dave Smith <dave at thesmithfam.org> writes:
> I've looked at JMS and threw it out because of the Java
> dependencies. My software is mostly Python and C++. I also looked at
> (and used) CORBA, but it's too complex and the learning curve is
> killer. What I really want is D-Bus, but currently D-Bus doesn't
> support remote messaging[1] since it relies on Unix Domain Sockets.

So, I did a little more research on AMQP, and I'm not sure why you
seemed to reject it out of hand over XMPP, which is not even designed
for the sort of thing you're trying to do.  What you seemed to be
describing is called Message Oriented Middleware in 'enterprise'
circles, and JMS is one example of it, though its fatal flaw is lack
of interoperability.  Which is precisely why JP Morgan created AMQP,
which is an open protocol with several independant implementations
(Apache QPid, LShift's RabbitMQ, and OpenAMQ).  The standard hasn't
been finalized yet, but it's pretty close.

Here's some relevant description info from AMQP's site (https://jira.amqp.org/confluence/display/AMQP/About+AMQP):

The AMQP Model

The AMQP model explicitly defines a server's semantics because
interoperability demands the same semantics for any server
implementation. The model specifies a modular set of components and
standard rules for connecting these components. There are three main
types of components which are connected into processing chains in the
server to create the desired functionality:

    * The "exchange" receives messages from publisher applications and
      routes these to "message queues", based on arbitrary criteria -
      usually message properties or content.

    * The "message queue" stores messages until they can be safely
      processed by a consuming client application (or multiple
      applications).

    * The "binding" defines the relationship between a message queue
      and an exchange and provides the message routing criteria.

This model emulates the classic middleware concepts of
store-and-forward queues and topic subscriptions. It also expresses
less trivial concepts such as content-based routing, message queue
forking, and on-demand message queues.

In very gross terms, an AMQP server is analogous to an email server,
with each exchange acting as a message transfer agent, and each
message queue as a mailbox. The bindings define the routing tables in
each transfer agent. Publishers send messages to individual transfer
agents, which then route the messages into mailboxes. Consumers take
messages from mailboxes, which creates a powerful and flexible model
that is simple.  

The AMQP Wire-level Format

The AMQP wire-level format is a binary framing with modern features:
it is multi-channel, negotiated, asynchronous, secure, portable,
neutral, and efficient.

The AMQP wire-level format is split into two layers; a functional
layer and a transport layer. The functional layer defines a set of
commands (grouped into logical classes of functionality) that do
useful work on behalf of the application. The transport layer that
carries these methods from application to server, and back, and which
handles channel multiplexing, framing, content encoding,
heart-beating, data representation, and error handling. Both the
transport layer & high-level layers are plugable, which allows
evolution of the protocol and the adoption of emerging technologies.

Implementations:
Apache Qpid: http://cwiki.apache.org/qpid/
RabbitMQ: http://www.rabbitmq.com/
OpenAMQ: http://www.openamq.org/
ZeroMQ: http://www.zeromq.org/

ZeroMQ also has a nice whitepaper on AMQP: http://www.zeromq.org/whitepapers:amqp-analysis


                --Levi



More information about the PLUG mailing list