activemq should offer higher level guarantees about reliability. zeromq is simpler. you can argue that activemq has things you will probably end up implementing yourself on top of zeromq, or that zeromq has less to get wrong...
another way of saying the same thing, which illustrates the cultural differences:
- activemq is intended to be used in "the enterprise". it tries to implements a logical ideal, which is a reliable infrastructure that services can use without being coupled to each other - without worrying about whether messages were received, or exactly who they go to. to reduce complexity it uses a central broker (so you send messages to a central "hub").
- zeromq is intended (imho) for programmers that want to wire things together. it's less concerned with abstractions and more with providing something simple clear, simple and flexible that can be understood and used well. to reduce latency it uses direct connections between peers.
from that viewpoint, you can see that the two are both orthogonal and yet similar... (disclaimer: i haven't used either, but i used work on an ESB so have a vague grasp of what's going on. please someone correct me if this is wrong - i might as well learn as i lose karma ;)
ps rabbitmq is somewhere in the middle and was (i think) originally more performance-motivated (i believe it's used in finance for example - when speed might be critical).
RabbitMQ's main motivation has been to make it easier to join systems together, scale your applications and manage complex environments. That is what messaging is for. Back in 2006, we felt there was a need for a good, stable and scalable open source licensed product that could compete with the incumbents.
Notice that I did not mention performance. RabbitMQ has good performance and it is used quite a lot in finance, but the majority of users are what you might categorise as "anyone using MySQL or Postgres".
Re activemq vs zeromq, I recommend reading "broker vs brokerless" on our blog.
"it uses direct connections between peers" -- this is kind of true.. the guide suggests that ultimately you will want a broker (what it calls "devices") to intermediate producer-consumer interactions.
Activemq is a program that you can install and run, of a type often called message oriented middle ware. Zeromq is a library that provides abstractions on sockets. Basically they are unrelated.
zeromq does not persist messages so you can lose them and need to adjust your infrastructure around this. If you are used to network programming that should be fine, just build persistence in to your protocol where you need it, ie reply after you have committed to persistent storage.
It persists messages in one direction. Imagine you have a publish subscribe situation where you have a few apps subscribed to a publisher. If one of those apps goes down, the publisher will make a note and store the messages until it comes back. When the app comes back, it will get all the messages it missed. It's really a wonderful thing if you were going to implement peer-to-peer pub/sub yourself.
It's also nice in applications like Mongrel2. Make an http request, in your browser, start up your web server, and the request completes! Great for development, where sometimes you switch to the browser faster than your app can restart after a change. With Mongrel2 (and thanks to 0MQ), you don't even notice the race condition.
ZeroMQ can persist messages to disk in high water mark situations, so once it hits memory pressure it can put it to disk, but it won't read from disk on crash...
