zeromq - 

ØMQ (also seen as ZeroMQ, 0MQ, zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fanout, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks. It has a score of language APIs and runs on most operating systems. ØMQ is from iMatix and is LGPLv3 open source.

 Ø  The socket library that acts as a concurrency framework.
 Ø  Faster than TCP, for clustered products and supercomputing.
 Ø  Carries messages across inproc, IPC, TCP, and multicast.
 Ø  Connect N-to-N via fanout, pubsub, pipeline, request-reply.
 Ø  Asynch I/O for scalable multicore message-passing apps.
 Ø  Large and active open source community.
 Ø  30+ languages including C, C++, Java, .NET, Python.
 Ø  Most OSes including Linux, Windows, OS X.
 Ø  LGPL free software with full commercial support from iMatix.

ØMQ delivers value-add over the TCP. Asynchronicity, message queueing, routing based on business logic, multicast etc.

ØMQ has higher throughput than TCP although it's built on top of TCP:
Avoiding redundant networking stack traversals can improve throughput significantly. In other words, sending two messages down the networking stack in one go takes much less time then sending each of them separately.This technique is known as message batching.

    It handles I/O asynchronously, in background threads. These communicate with application threads using lock-free data structures, so concurrent ØMQ applications need no locks, semaphores, or other wait states.

    Components can come and go dynamically and ØMQ will automatically reconnect. This means you can start components in any order. You can create "service-oriented architectures" (SOAs) where services can join and leave the network at any time.

    It queues messages automatically when needed. It does this intelligently, pushing messages as close as possible to the receiver before queuing them.

    It has ways of dealing with over-full queues (called "high water mark"). When a queue is full, ØMQ automatically blocks senders, or throws away messages, depending on the kind of messaging you are doing (the so-called "pattern").

    It lets your applications talk to each other over arbitrary transports: TCP, multicast, in-process, inter-process. You don't need to change your code to use a different transport.

    It handles slow/blocked readers safely, using different strategies that depend on the messaging pattern.

    It lets you route messages using a variety of patterns such as request-reply and publish-subscribe. These patterns are how you create the topology, the structure of your network.

    It lets you create proxies to queue, forward, or capture messages with a single call. Proxies can reduce the interconnection complexity of a network.

    It delivers whole messages exactly as they were sent, using a simple framing on the wire. If you write a 10k message, you will receive a 10k message.

    It does not impose any format on messages. They are blobs of zero to gigabytes large. When you want to represent data you choose some other product on top, such as Google's protocol buffers, XDR, and others.

    It handles network errors intelligently. Sometimes it retries, sometimes it tells you an operation failed.

    It reduces your carbon footprint. Doing more with less CPU means your boxes use less power, and you can keep your old boxes in use for longer. Al Gore would love ØMQ.

Actually ØMQ does rather more than this. It has a subversive effect on how you develop network-capable applications. Superficially it's a socket-inspired API on which you do zmq-msg-recv[3] and zmq-msg-send[3]. But message processing rapidly becomes the central loop, and your application soon breaks down into a set of message processing tasks. It is elegant and natural. And it scales: each of these tasks maps to a node, and the nodes talk to each other across arbitrary transports. Two nodes in one process (node is a thread), two nodes on one box (node is a process), or two boxes on one network (node is a box) - it's all the same, with no application code changes.

brokerless (no central server)
lightweight (mem footprint, disk)
tool box for smart sockets - may have to build higher level functionality if needed

No serialization library - you choose format (e.g. JSON, Google PBs, etc.)
No topics, persistence, transactions
No detection of failed or slow consumers (messages simply get dropped without any notification to the producer program) 
supports many messaging patterns,transports, platforms and language bindings

can bridge w/ rabbitMQ
http://www.rabbitmq.com/blog/2010/10/18/rabbitmq0mq-bridge/

broker vs brokerless comparison (by zeromq)
http://www.zeromq.org/whitepapers%3abrokerless

http://stackoverflow.com/questions/731233/activemq-or-rabbitmq-or-zeromq-or

comparison 
http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/
[1] http://www.imatix.com/articles:whats-wrong-with-amqp
[2] http://www.h-online.com/open/features/The-Red-Hat-Patent-Problem-and-AMQP-746549.html
[3] http://www.ipocracy.com/blog:redhat-claims-amqp
[4] http://stackoverflow.com/questions/3789822/qpid-finer-amqp-control-with-the-high-level-api