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.
Hope this helps.
They pass messages. They're fairly related.
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.