Modularity is a lovely thing - and the protocol has a fair amount of it.
The problem with modular is that no one is ever sure what modules a server is running ;-) Just look at the NFS 2 lock daemon being separate. Consequently no one ever trusted it and NFS got a bad rep. NFSv4 went monolithic to solve that problem. XMPP has some of those issues too (btw, I like XMPP a lot but the design space caters to different needs). On AMQP, I believe it makes sense to use it as the basis for a raft of E-Commerce systems; including payment processing and regulatory reporting. If AMQP gets adopted in these areas it will be a huge driver for wider adoption. In financial services, the FIX 5 protocol now officially separates transport from application messages. AMQP has an opportunity to play in that space. It's quite a popular idiom for people to send FIX over MQ style transports.... could be interesting. John On 26/10/06, James Strachan <[EMAIL PROTECTED]> wrote:
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/
