As it turns out the AMQP 0-91 spec is only that short because the protocol definition is split out as a separate (139 pages) document.
In contrast, the full STOMP spec fits on a page.
Of course they are vastly different in scope, but that is kind of the point.
There's a place for protocols like AMQP, there's a place for generic brokers like RabbitMQ, but there's also a place for far simpler protocols and simpler and/or specialized brokers. Lots of them.
For many applications being able to customize a simple, few hundred lines long, specialized broker is more useful than having all the extra capabilities you'd get from AMQP or a multi-protocol broker like RabbitMQ for example.
That's part of the reason you'll keep seeing a proliferation of these systems - it's trivial to implement a simple broker that can handle tens or hundreds of millions of messages a day on modern hardware (my last broker processed about 4-5 million messages/day using 10% of a single 2GHz Xeon core, written in completely unoptimized Ruby that took about a day to write), which means the barrier to writing your own and get something that fits your requirements exactly and where you understand every line instead of trying to find the ideal off the shelf solution is pretty low.
Now, there are many cases where an off the shelf solution to this is the right answer. The more complex your requirements are, the more critical proper failure handling is etc., or if external requirements involve speaking a complex protocol, the more attractive something like RabbitMQ gets.
But I doubt there will ever be a "one true system" for RPC or message exchanges, because the needs people are using RPC and message exchanges to address are so vastly different. You shouldn't look at whether or not these systems get widespread traction for that reason. What matters is if they are good at meeting the needs of their specific niches.
I could not find the 139 page document to which you refer.
There are two 0-91 docs, one is the spec definition for users, which as I said short and is mostly edge cases you can ignore. There is a second doc for implementers which defines the classes and methods in more detail. This is 63 pages long. Note also that for the purposes of client codegen, the BSD licensed XML file in 0-91 is only a few pages long - because the surface of the spec is surprisingly small.
As a comparison, the definition of core XMPP (a Jabber server) in http://www.ietf.org/rfc/rfc3920.txt is 90 pages. BTW the core spec is just for IM not pubsub.
In the case of both AMQP and XMPP the length comes from the requirement to interoperate between implementations.
You make a good point about STOMP above. We love STOMP too. There is as you say a place for it - for lots of protocols. We have however found with STOMP that because many behaviours are completely unspecified, that it costs us a lot more to support (find and fix bugs, maintain stable behaviour under different conditions, etc). It is less likely that the same application talking to two STOMP brokers will behave the same way with both brokers - deterministically and predictably. Maybe this is a good thing - there is more scope for competing implementations? I don't think it's ideal. And let's not talk about JMS in this regard.
I would not discourage people from writing their own brokers. You are among many who have done this and people will go on doing it. But although you may understand every line - what happens when someone else has to take over managing your code? What if the requirements change - or the scope of use grows? This is where products add value.
A lot of our customers have extremely simple requirements like "don't ever lose my messages" or "broadcast to twenty different types of subscriber". So, I don't think it's fair to make generalisations about "complex requirements".
Comments
As it turns out the AMQP 0-91 spec is only that short because the protocol definition is split out as a separate (139 pages) document.
In contrast, the full STOMP spec fits on a page.
Of course they are vastly different in scope, but that is kind of the point.
There's a place for protocols like AMQP, there's a place for generic brokers like RabbitMQ, but there's also a place for far simpler protocols and simpler and/or specialized brokers. Lots of them.
For many applications being able to customize a simple, few hundred lines long, specialized broker is more useful than having all the extra capabilities you'd get from AMQP or a multi-protocol broker like RabbitMQ for example.
That's part of the reason you'll keep seeing a proliferation of these systems - it's trivial to implement a simple broker that can handle tens or hundreds of millions of messages a day on modern hardware (my last broker processed about 4-5 million messages/day using 10% of a single 2GHz Xeon core, written in completely unoptimized Ruby that took about a day to write), which means the barrier to writing your own and get something that fits your requirements exactly and where you understand every line instead of trying to find the ideal off the shelf solution is pretty low.
Now, there are many cases where an off the shelf solution to this is the right answer. The more complex your requirements are, the more critical proper failure handling is etc., or if external requirements involve speaking a complex protocol, the more attractive something like RabbitMQ gets.
But I doubt there will ever be a "one true system" for RPC or message exchanges, because the needs people are using RPC and message exchanges to address are so vastly different. You shouldn't look at whether or not these systems get widespread traction for that reason. What matters is if they are good at meeting the needs of their specific niches.
Thanks for your comment.
I could not find the 139 page document to which you refer.
There are two 0-91 docs, one is the spec definition for users, which as I said short and is mostly edge cases you can ignore. There is a second doc for implementers which defines the classes and methods in more detail. This is 63 pages long. Note also that for the purposes of client codegen, the BSD licensed XML file in 0-91 is only a few pages long - because the surface of the spec is surprisingly small.
As a comparison, the definition of core XMPP (a Jabber server) in http://www.ietf.org/rfc/rfc3920.txt is 90 pages. BTW the core spec is just for IM not pubsub.
In the case of both AMQP and XMPP the length comes from the requirement to interoperate between implementations.
You make a good point about STOMP above. We love STOMP too. There is as you say a place for it - for lots of protocols. We have however found with STOMP that because many behaviours are completely unspecified, that it costs us a lot more to support (find and fix bugs, maintain stable behaviour under different conditions, etc). It is less likely that the same application talking to two STOMP brokers will behave the same way with both brokers - deterministically and predictably. Maybe this is a good thing - there is more scope for competing implementations? I don't think it's ideal. And let's not talk about JMS in this regard.
I would not discourage people from writing their own brokers. You are among many who have done this and people will go on doing it. But although you may understand every line - what happens when someone else has to take over managing your code? What if the requirements change - or the scope of use grows? This is where products add value.
A lot of our customers have extremely simple requirements like "don't ever lose my messages" or "broadcast to twenty different types of subscriber". So, I don't think it's fair to make generalisations about "complex requirements".
I completely agree with you about RPC.
Cheers,
alexis