The chances of me using this? Zero.
With SonicMQ, however, I have happily used their RESTish HTTP Adapter that just maps destination names into the URL & looks for HTTP Headers for any messaging specifics. Want to check for a message? Check the response queue via a different HTTP GET. Certainly not perfect, but can be useful when working with a technology that does not have a richer client available.
I took a quick scan of this document & remembered a Tim Bray post from last year.
I guess I won’t offer any further commentary on the contents of this document. I can’t help but feel for the H/I/I/M staff who are going to have to do the work, and am reminded of Fritz Lang’s immortal Metropolis, where Maria says: “Nobody cared about the slaves who died laboring to raise the Tower of Babel.”
Not sure if they already are (don't see any of their names listed), but it would be nice if these vendors got involved in AMQP. That seems to have some promise.
Why AMQP? Though many networking protocol needs have been addressed, a large gap exists in common guaranteed-delivery messaging middleware. AMQP fills that gap...
What is AMQP? AMQP enables complete interoperability for messaging middleware, both the networking protocol and the semantics of broker services are defined in AMQP.
AMQP Model The AMQP model explicitly defines the server's semantics because interoperability demands the same semantics for any server implementation.
Wire-level Format To enable technology-neutral interoperability, AMQP defines an efficient wire-level format with modern features.
