On 10/24/06, John O'Hara <[EMAIL PROTECTED]> wrote:
James
AMQP is supposed to be "a message provider *protocol*" just like SMTP, or
NFS are protocols. They achieve a goal simply and well in a manner which is
broadly accessible.
So imagine for a moment you wanted to write an NFS server for an IBM
mainframe. Mainframes have lots of interesting notions about how files are
structured, accessed, secured etc, but to make a working NFS server you'd
need to ensure that all of the concepts in NFS like an IP transport, a
directory hierarchy, POSIX style permissions and filename character sets
were all perfectly mapped. Some of these concepts might not even exist on
source platform, and you'd have to implement them. But you'd do it, because
you know that your clients value compatibility with standards highly.
The same is true of anyone implementing AMQP. They may be adding it onto an
existing, perfectly fine implementation. But that existing codebase needs
to be modified, perhaps quite a lot, to meet AMQP semantics; or clients
won't be interested.
To quote you,
"its more a case of making some new messaging providers that speak the same
wire protocol?"
Whole new products - no; but a lot of modifications may be required to
existing brokers to achieve good compatibility - just as mainframes took
modification to support TCPIP.
Thanks for the heads up.
If you know of an easier way to plug-and-play wire-level interoperability
without compromising functionality, I'd love to hear it.
Its a classic tug of war between functionality, performance,
complexity and interop. It depends where on that continuum you're
aiming for what your ideal solution will look like.
I proposed that the AMQP Working Group create an interoperability subset of
AMQP (let's call it AMQP-lite). This would be just enough to login, publish
to and consume from queues. It would be easier to retro-fit onto other
middleware, but would have to be an lowest common denominator solution.
Would you like to help in such an effort?
I'm afraid I've enough on my plate right now :) I think with AMQP,
Stomp, XMPP, Cometd, REST, OpenWire and WS-N/WS-E/WS-RM we've enough
protocols for now :)
FWIW Stomp has proved itself to be excellent at the low end; where
ease of use & simplicity of the client outweighs the performance gains
in having a much more complex binary protocol. Folks can literally
write a client from scratch in an hour or two - or just use telnet :)
So it comes from the HTTP school; make clients really easy to write &
brokers fairly forgiving but a good server might take a while to write
:)
If someone ever had enough time on their hands I guess we could come
up with something in between Stomp and AMQP though am not sure if its
worth it; if folks care about simplicity & easy interop, they'd maybe
go with Stomp - if they wanted performance & functionality they'd go
with AMQP so am not sure who'd go for AMQP-lite.
Maybe we just need to make sure AMQP remains nice and modular like
XMPP is; with as small & simple a core as possible with then different
functionalities layered on in separate optional modules?
--
James
-------
http://radio.weblogs.com/0112098/
