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.