This post originated from an RSS feed registered with Java Buzz
by Brian McCallister.
Original Post: AMQP 0.8 Published
Feed Title: Waste of Time
Feed URL: http://kasparov.skife.org/blog/index.rss
Feed Description: A simple waste of time and weblog experiment
I just had a quite good time reading (via
InfoQ) the
AMQP 0.8 Spec which has finally snuck out to the public!
Rumours of this puppy have been flying for a while, and I have to admit I thought
it would never be opened. Woot, I love being wrong.
I had heard lots of "I think it is going to be [FOO]" kinds of speculation from folks,
mostly leaning towards the "too complex for anyone to bother implementing" side of
[FOO], but on a first pass, it doesn't look bad to implement at all. I rather like
the technical smell of it!
I am extremely curious who is going to wind up with the copyright assignment of it.
Right now it is spread across all the folks who worked on it (behind closed doors).
They seem to be good folks on the vendor side (IONA, Redhat, Cisco). I don't know
JP Morgan (who presumably bankrolled it and the others will try hard to keep happy)
to make a guess at their behavior. If it were to go IETF or a respectable protocol
oriented standards body I'd be overjoyed. The licensing terms look reasonable
on first glance, and they claim to have carefully designed it to dodge any
IP issues which could come up.
Very interestingly, the protocol goes far beyond simple message transport and
extends into the control of the messaging system to a significant degree. It
really reads like an API much more than a protocol. For example, it includes
explicit commands for destination creation and configuration. For the most part
its semantics map very nicely into JMS, which I presume was a design goal, and
it certainly would be straightforward to put an implementation into ActiveMQ.
I have heard rumour that one might be underway by someone who had access to the
spec before today, but I am not sure of this. Grr, closed development.
Speaking of closed development, and a protocol that reads like an API, that is,
really, my biggest concern. Redhat and IONA certainly have earned the benefit of a
doubt, but... I'm not holding me breath on this being a standard as long as it
is more or less controlled by JP Morgan (which is my understanding, and I am happy
to be corrected). I can very much see a strong case of doing the design with a small
group behind closed doors in order to keep committee-creep out, and that is all
fine and good. Now that an initial is out, though, I am very curious to see
how the process continues. I hope that involvement opens up, in other words.
It, of course, begs a comparison to Stomp,
which John O'Hara (no link that I know of, and not the literary one) hit the big
point over on InfoQ, that AMQP aims to specify behavior inside the messaging system,
whereas Stomp specifically avoids that and sticks to message transfer between
the client and server, letting the server be a black box. I asserted there that
I think Stomp might see wider use because it is much simpler, and I have
a firm belief that complexity is one of the largest barriers to adoption that
any technology faces. Looking at the AMQP spec, I think it offers a lot for its jump
in complexity, maybe enough to be worth it. No telnet debugging, though =/
Jabber/XMPP also begs comparison, and this is going to be a fun one. I don't
especially like Jabber/XMPP -- it is very tied to its instant messaging heritage,
and is even less efficient than Stomp, which is saying a lot. They feel very
different to me, but I want to go read the Jabber RFC's again before spouting off.
So, I'm tentatively very excited! I'd like to see participation opened up. Open
development is a very big deal for something that hopes to become a standard in a
space which badly needs a standard. Heck, open up participation and clarify control
of the spec and it could very easily become a real standard, not yet-another-standard.
Previous Topic
