That's rather damning. As a casual but curious user, I "got" ØMQ and was up and running from a one page tutorial. AMQP left me scratching my head for longer. It didn't seem quite as orthogonally structured. It just wasn't UNIX.
I think that is due to OpenAMQ and not AMQP the protocol. sudo apt-get install rabbitmq-server will get you a working AMQP server on Debian or Ubuntu in one step. Building from source is fairly easy, as well: http://www.rabbitmq.com/build-server.html
It would be nice if they pointed out why rather than a simple "this sucks" with no reasoning.
I tried getting OpenAMQ up and running about a year ago but it was like pulling teeth. On the other hand, I got RabbitMQ installed and working in almost no time at all so I don't think the AMQP standard is what's getting in the way of building a quality messaging product. 0MQ was still in pre-alpha with nothing available to download at the time so it wasn't even possible to use it. It's nice to see that the project delivered something useful.
Hrm. I've been talking through a decentralized social web architecture on my blog, with an eye to building an open source project later on, and had intended to use AMQP as the backbone for reliable message passing. This somewhat puts paid to that.
Absolutely, I'm working on an MMO, and the complexity/flexibility of the AMQP protocol has been a god send.
However, I do agree that its concepts are somewhat convoluted for a new user, it took me quite a bit of digging to get the basics of what an exchange/queue was and what bindings mean, etc.
However, 0MQ looks attractive but simply doesn't have what's needed for a complex project that spans languages, platforms, and usages beyond the basic pub-sub.
I would compare both protocols as XML vs. JSON, whereas XML may be tedious but it's absolutely necessary for some cases, specially where tight specifications are needed.
I'd love to see a quick diagram of what the protocol's look like on the network and compare them to various other MQ systems and other protocols like HTTP etc.
No misunderstandings... When the AMQP working group was founded, RHAT took a very assertive role over AMQP and created versions that no-one else implemented, and which were pushed through the working group by sheer political force. Read the abomination that is the AMQP/0.9 spec, if you have the courage. The determination of RHAT to create incompatible forks of the spec is a large part of what killed AMQP in our eyes. We spent several years trying to save AMQP from that. We failed. We're a small team, RHAT had 20 people working on this.
> We're a small team, RHAT had 20 people working on this.
They should have realized they already failed when they allocated 20 people just do work on the protocol specification. This is another example of a design by committee done by a large enterprise vendor and how it results in a a bloated, inefficient and overly complicated specification.
All 20 people feel the need to justify their time by adding more crap and features to the design. Usually no matter how simple or complicated the actual protocol needs to be, its specification will always be proportional to the number of people * time assigned to work on it.
Ah, another one bites the dust by the hands of an "enterprise" software vendor. These guys make money selling free software to big companies that are too stupid to realize that their support contract is about as valuable as the paper it's written on.
"Hey this thing X is broken our new product solves all problems and is superior in any way."
While I too would like to see AMQP 1.0 rather sooner than later and despite the open standard there are only a few usable implementations, I doubt that this new and great wire protocol will solve all of AMQPs problems which are located in other areas.
We've waited 6 years for AMQP to develop a community and address basic issues such as its complexity and high cost of change. No progress... despite years (literally) of work to try to open the AMQP workgroup to wider participation.
We love the idea of open messaging protocols and invested a painfully huge amount in AMQP but it's not been worthwhile: almost as soon as we helped found the AMQP working group, the protocol was hijacked into something complex and untenable.
At iMatix we believe in simple, clean, fast software. Just run any AMQP broker and compare to 0MQ and the conclusion is clear: 0MQ wins, hands down.
0MQ still has a long way to go but it's totally open, and anyone with a good idea is welcome to contribute. No contracts to sign. Just join the mailing list and discuss.
We will make messaging patterns into 1st class citizens of the Internet.
This is the metaprogramming we used to build OpenAMQ. It was very successful in technology terms (1M lines of real code generated from 20k lines of metacode) but a failure in social tems (too high a barrier to community participation).
SFL saved my ass in the mid-1990s. I was in dire need of some easy-to-use, well-documented functionalities in C and SFL was easily the best there was. A million thanks for providing such high-quality code to the community!
It's not that imatix is some random company saying AMQP is broken... they are part creator of said beast. I think they've simply come to the conclusion that there is a better way to do it.
I designed and wrote AMQP versions 0.1 through 0.8 and iMatix founded the AMQP working group. I was editor of the last 0.9.1 spec which fixed almost all of the bugs and inconsistencies of 0.8. It's a great, clean, tight spec but still fundamentally flawed :-) As for AMQP/1.0, no comment, but I would not run my business on it.
Pieter, I recall you mentioning that there are three forms an industry can have as standard;
1) The best is a healthy number of implementations based on an open source specification;
2) The undesirable way is having a implemantations based on an API, namely JMS;
3) The lowest most undesirable way is having an implementation as industry standard, as this allows for vendor lockins, soaring prices, and tardy performance;
Having said that, ØMQ is an implementation (albeit fast and open) without an open specification , nevertheless, you are essentially basing your business on number 3. an implementation as industry standard (given that what you do, industry will follow). Secondly with your influential clout in this field, are you not pushing an implementation into the market as the next industry standard -> whereas it should ideally be an open spec?
Aside, what high performance (which excludes restms) substitute spec are you cooking up? Is there a slight possibility that you will reverse engineer the spec from ØMQ?
Nice question. 0MQ has a wire protocol but it's minimalist, just doing framing. As we push 0MQ out into wider use we'll grow the protocol stack upwards. It'll take years. We do have a protocol specification project - http://rfc.zeromq.org/
We do intend to deliver IETF-quality specs that turn messaging patterns like pubsub into 1st class citizens of the Internet, so that arbitrary vendors can produce pieces that plug into this. But these specs will still be really simple.
I've always advocated a standard API for AMQP and proposed one (WireAPI) years ago, because this reduces vendor capture. Imagine if vendors designed arbitrary socket APIs... well some do, and it locks their users in.
So 0MQ is partly an API standardization project, partly an architecture project (to build a layer that seems to be missing from the stack), and partly a protocol specification project.
I wish you strength and that the community support you! It looks like a decent direction to move in.
Your efforts at messaging pattern commodification on the Internet looks especially interesting, given your experience with restms. I hope this cracks it and makes life easy for all of us!
