The important detail they miss out is that there's no broker and no (built in) persistence, and that sucks when parts of your critical messaging infrastructure go down and you lose messages you thought had been sent.
I believe all the socket types except REQ and REP do have incoming/outgoing queues. There's just no requirement for a broker to serve as an independent queue.
Yes, your applications do have queues for incoming/outgoing messages but there is no "message queue" A "message queue is an external thing that provides some kind of service but with ZeroMQ that external thing does not exist. If you sometimes need an external thing to provide delivery guarantess and persistence, then it is easy to connect RabbitMQ to accept/send ZeroMQ messages. Or just make your own shim process that translates to/from AMQP.
Comments
The important detail they miss out is that there's no broker and no (built in) persistence, and that sucks when parts of your critical messaging infrastructure go down and you lose messages you thought had been sent.
If you read the name as "zero message queue" is it surprising that it doesn't have persistence? There's no message queue.
I believe all the socket types except REQ and REP do have incoming/outgoing queues. There's just no requirement for a broker to serve as an independent queue.
Yes, your applications do have queues for incoming/outgoing messages but there is no "message queue" A "message queue is an external thing that provides some kind of service but with ZeroMQ that external thing does not exist. If you sometimes need an external thing to provide delivery guarantess and persistence, then it is easy to connect RabbitMQ to accept/send ZeroMQ messages. Or just make your own shim process that translates to/from AMQP.
zmq is not simple a messaging framework. its more like a concurrency library. and there are a lot of reliability and high availability patterns for zmq: http://zguide.zeromq.org/page:all#Chapter-Reliable-Request-R...
Yes, because 0mq is just sockets.