Friday, August 1, 2008

Can AMQP break IBM's MOM monopoly?

Jeff Gould at InteropSystems has written a great series of articles about the value and promise of AMQP.  Part 1 of the article is here: Can AMQP break IBM's MOM monopoly?  In part 2 of the series, Gould interviews Red Hat's Carl Trieloff, who talks about what we're doing with AMQP, JBoss and MRG.


Tim Fox said...

In order for AMQP to be successful it needs:

a) To be simple. The current 0.10 is way too complex making it extremely difficult for established vendors to implement on top of their existing messaging technology. Going back to 0.8 and rethinking is one option here, and one that I believe is being actively pursued by other AMQP interested parties. If AMQP is to survive perhaps that's the life-line it needs? Remember the KISS principle.

b) One of the "big guys" like IBM or Tibco to implement to it. I fail to see what interest those guys would have in implementing AMQP. Any AMQP product they produce would directly take revenue away from their proprietary product revenue streams. Why would they do this?

Jeff Gould said...

There was a time when people said IBM would never implement TCP/IP because it would hurt SNA. There was a time when people could not even have imagined the possibility that IBM would port Linux to its mainframes. But nowadays you can run WebLogic and Oracle on Linux on a mainframe if you want to (and JBoss as well, I presume), and obviously they will be communicating with the outside world over TCP/IP. Surely at some level that has to impact sales of IBM’s own software, but IBM bit the bullet and did it anyway because they understood it would boost flagging mainframe sales.

I believe economic theory predicts that smart monopolists such as IBM and Microsoft will moderate their monopoly behavior to the extent that doing so helps them to maximize profits. Sales of WebSphere MQ are not exactly beating any records for growth these days. The AMQP proponents seem to be arguing that IBM will ultimately make more money if it allows the new protocol to open up the messaging market and reignite its growth.

Of course, I don’t know whether this will actually happen (and I can’t address Tim’s objection that the current version of the protocol is too complex). But surely this scenario is at least plausible…

Tim Fox said...


Yes I think it's plausible, but only if it's radically simplified, since it's only then you'll see an implementation uptake. Simplicity is a requirement for making it on to network devices too.

Right now it's just too complex, and this is a big barrier to adoption. Unlike JMS which was deliberately made simple to retro-fit onto existing messaging technology, AMQP, in it's current state at least, is deeply intrusive, requiring pretty much an re-write from scratch in order to implement it.

I'm all for AMQP, in concept at least, but I think it needs to go back to basics if it's going to have a shot at ubiquity.

Historically, IMHO, those protocols which have made it everywhere tend to have one thing in common - simplicity.

As soon as a protocol becomes too complex, interoperability suffers, since vendor A has interpreted the spec one way and vendor B has interpreted it another way. End result - they can't talk to each other.

That's if they have managed to implement it all, and they have the budget to undertake such a major piece of work.

Pieter Hintjens said...

Tim, thanks for stressing the need for simplicity in AMQP, this has been one of my bugbears since 0-9 came out.

Simplicity is not just a feature, it's the result of the way the spec is built, the architecture of the process itself.

IMHO the ideal AMQP specification consists of a stack of protocols that interoperate properly and each solve part of the problem. E.g. why can't I use the AMQP semantics (one protocol) on top of XMPP, why can't I reuse the AMQP wire level format for classes and methods with other semantics, etc.

A stack of protocols would give different vendors space in which to compete properly. Right now, the single AMQP spec makes that impossible and we get the consequent design by committee in which simple ideas get overwhelmed by complex ones.

Successful protocols that want to deconstruct existing markets have to be significantly simpler than existing options.

We've already seen that the AMQ exchange-binding-queue semantics make it much easier to design decoupled architectures.

Now let's see if the same can be done with framing, security, reliability, etc.

Unknown said...
This comment has been removed by the author.
Unknown said...

Yep, we know it needs to get simpler - and the great thing is everyone working on AMQP agrees on that point.

So many people want this to succeed... we owe them and ourselves to deliver this (simply).

John OHara

Maurice said...

清卡數,補習,補習,china mobile phone,珠寶設計繪圖入門,裝修,
seo training course,姻緣配對,投資,
office furniture,Piano,

Maurice said...

Sai Kung property,廣告,
online shop,seo,潮流鞋類,
IVA,internat marketing,webdesign,
hong kong hotel,星加坡酒店,
hotels,hong kong hotels,

Maurice said...

macau hotel,馬來西亞酒店,

Anonymous said...

t I believe is being Diablo 3 Itemsactively pursued by other AMQP interested parties. If AMQP is to survive perhaps that's the GW2 Goldlife-line it needs?