I don't think of 0MQ as a direct competitor to AMQP. Having been involved in the development of both, AMQP as compared to 0MQ implements a fairly heavyweight wire protocol with complex "message oriented middleware" semantics. 0MQ on the other hand aims to be "just a transport" -- think fast message switch -- with most traditional middleware semantics left to the application to handle.
As for the lack of error handling in the code samples, I completely agree with you and would have preferred to see all the examples include error handling and simple stub code for processing but I was outvoted by others working on the article.
Posted Jan 21, 2010 18:48 UTC (Thu) by JLCdjinn (guest, #1905)
[Link]
Mr. Lucina,
Would you be willing to provide updated code samples with error handling and stubbed processing in the comments, here, for the completists among us?
0MQ: A new approach to messaging
Posted Jan 22, 2010 14:57 UTC (Fri) by mato (subscriber, #964)
[Link]
I have updated the examples available on the 0MQ documentation page with both error handling and stub processing code. I haven't done any special error handling for the Java and Python examples since 0MQ just throws native exceptions.
Hope this helps.
0MQ: A new approach to messaging
Posted Jan 21, 2010 19:37 UTC (Thu) by chrish (subscriber, #351)
[Link]
Thanks for an interesting article.
I'd be really curious to hear more about how 0MQ compares with AMQP solutions, and in particular RabbitMQ (which was the message queueing project I was keeping an eye on before this article). Any comments on the strengths and weaknesses of each? Among others, what kind of features are possible only when you have a piece of software sitting between senders and receivers (as RabbitMQ)?
0MQ: A new approach to messaging
Posted Jan 22, 2010 7:19 UTC (Fri) by sustrik (guest, #62161)
[Link]
There's different focus: While RabbitMQ is more suitable for SOA-style deployments, 0MQ is focused on things like high-performance computing and stock trading.
From technical point of view, not having a broker means there's no centralised management, configuration, logging etc. On the other hand, not having a broker means there's no single point of failure.