0MQ: A new approach to messaging

Posted Jan 21, 2010 15:54 UTC (Thu) by emk (subscriber, #1128)
Parent article: 0MQ: A new approach to messaging

Very nice! I'm glad to see 0MQ is shaping up nicely. The big open-source
competitor in this space is the AMQP protocol, of which there are several
implementations.

But I'd like to mention a pet peeve of mine: I dislike code samples from
which error-handling has been omitted in the name of "brevity". Since every
responsible caller of the API will need to perform error-handling, it's a
dubious idea at best to publish broken code samples, and it misrepresents
the actual ease-of-use of the API.

0MQ: A new approach to messaging

Posted Jan 21, 2010 16:49 UTC (Thu) by mato (guest, #964) [Link] (4 responses)

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.

-mato (Martin Lucina)

0MQ: A new approach to messaging

Posted Jan 21, 2010 18:48 UTC (Thu) by JLCdjinn (guest, #1905) [Link] (1 responses)

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 (guest, #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 (guest, #351) [Link] (1 responses)

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.

Btw, nice piece of software, RabbitMQ is.

0MQ: A new approach to messaging

Posted Jan 21, 2010 21:40 UTC (Thu) by pieterh (guest, #52123) [Link] (4 responses)

iMatix, which makes 0MQ, also designed the core of AMQP as it is exists today and makes
OpenAMQ, the first AMQP implementation. So we're well aware of the overlap and competition
between 0MQ and AMQP. AMQP is a very nice message routing and queering abstraction, derived
from JMS. There are many others, and if you look at RestMS (http://www.restms.org), another of
our works, you'll see some alternative views.

Basically, 0MQ is a low-latency data center fabric, AMQP is an enterprise fabric, and RestMS is a
internet-scale fabric. There is overlap but they are complementary. You can never imagine doing
4M messages a second over AMQP, it's just way too heavy. But 0MQ has no semantics for inter-
broker federation, such as OpenAMQ has. Likewise, neither 0MQ nor AMQP works on Internet
scales, where RESTful principles become more important than immediate performance.

0MQ: A new approach to messaging

Posted Jan 22, 2010 16:39 UTC (Fri) by zooko (guest, #2589) [Link] (2 responses)

Why isn't AMQP suitable for Internet-scale?

See also "Delay-Tolerant Networking: http://www.dtnrg.org/wiki

0MQ: A new approach to messaging

Posted Jan 23, 2010 22:12 UTC (Sat) by pieterh (guest, #52123) [Link] (1 responses)

> Why isn't AMQP suitable for Internet scale?

I listed a number of problems with AMQP here: http://www.ipocracy.com/blog:10-principles-
for-amqp. You might also read this: http://www.zyre.com/blog:_start/p/2

Mainly, AMQP is too complex. The reasons are detailed and historical and I take responsibility for
many of the design decisions, such as using binary framing for control commands. The effort
needed to make a client stack is too heavy.

AMQP also ignores the principles that make for successful Internet protocols. Architectural ones,
such as REST but also established practice such as making many small RFCs, not a single huge
one.

Having said this, AMQP works very well indeed inside the enterprise, where we've used it for
many projects. It solves a certain class of messaging problem very nicely. There are many
classes of messaging problem. As I said, AMQP basically sits in the JMS space. You would not
use JMS across the Internet.

Hope this helps.

0MQ: A new approach to messaging

Posted Jan 24, 2010 7:33 UTC (Sun) by zooko (guest, #2589) [Link]

Thanks for the answers and the links!

0MQ: A new approach to messaging

Posted Jan 28, 2010 20:45 UTC (Thu) by z8000 (guest, #63250) [Link]

Why is 0MQ not appropriate at "Internet scales" (and I presume "should" be relegated to LANs)?
Perhaps I don't fully grok what you mean by "Internet scale" (WAN?).

I ask because (1) it looks great for a general transport at any "scale" and (2) the article itself
discusses a scenario in which 0MQ could be used over a WAN (branch offices, the forwarder, etc.).

What am I missing?