qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John O'Hara" <john.r.oh...@gmail.com>
Subject Re: Compliance Test Suite
Date Thu, 26 Oct 2006 10:43:23 GMT
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

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

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.


On 26/10/06, James Strachan <james.strachan@gmail.com> wrote:
> On 10/24/06, John O'Hara <john.r.ohara@gmail.com> 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/

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message