qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Huston <shus...@riverace.com>
Subject RE: Qpid Dispatch Router component
Date Fri, 11 Oct 2013 17:18:44 GMT
Hi William,

Thanks for expressing your view. And no reasonable person would discount it.

Speaking for my own points, I would not argue that Dispatch (or any trailblazing development)
should _wait_ for OASIS. However, since there are 2 areas of active work in OASIS that are
related, and Dispatch is quickly gaining experience and backing, I would very much like to
see Dispatch development folks actively involved in informing the OASIS technical committees
of their experience and help to get the eventual standard(s) worked out in a way that's been
proven in the field.

-Steve

> -----Original Message-----
> From: William Henry [mailto:whenry@redhat.com]
> Sent: Friday, October 11, 2013 12:49 PM
> To: users@qpid.apache.org
> Subject: Re: Qpid Dispatch Router component
> 
> 
> I'd also add, because I'm sure that some of you wonder why is William
> weighing in? What has he to do with AMQP/Qpid anyway besides being
> historically linked to it?
> 
> I've travelled globally talking about AMQP and Qpid to investment banks,
> government agencies, telecoms, animation studios, stock exchanges etc. etc.
> (strangers on planes ;-)  I'm sure others have done more to help promote
> AMQP and Qpid but, despite my seemingly lack of, or invisible, community
> involvement of late, I bet that list of others-that-have-done-more-to-
> promote it is actually not a very large list. I can think of a few. I have other
> technology areas I focus on but I continue to be involved in AMQP/Qpid
> because I get pulled back in, and I still "believe". There is a massive
> opportunity for AMQP that is more than just simple MOM.
> 
> So my 2 cents at a high level:
> 1) People love the AMQP story
> 2) People love the AMQP network story - with a variety of AMQP based
> assets.
> 3) As we've introduced the concept of what Dispatch does, people love it!
> Did I say love it?! And they do not see it as tangential to AMQP. But massively
> complimentary. A Dispatch type network with (various) brokers backing it up
> nearer to applications - that have different client interfaces (JMS, JCA,
> Python, C/C++, Ruby etc.)
> 4) The cloud will and is already playing a big part in AMQP adoption. We need
> to capitalize.
> 5) People want solutions now! Management now. Addressing nailed down
> now.
> 
> Best,
> William
> 
> ----- Original Message -----
> > +1. Great post Gordon. Again something to be captured in Qpid
> > +community
> > pages/documentation.
> >
> > I'd also add we need to be innovating fast around AMQP now that we have
> 1.0.
> > We can't always wait on the OASIS process. It has taken a very long
> > time to get here (not OASIS). There were some significant changes along
> the way.
> > Users are looking for solutions today.
> >
> > I understand there is a risk of getting ahead of ourselves in certain
> > areas and having to backtrack. However people that have been investing
> > in AMQP are looking for solutions to their problems ASAP and can't
> > wait until every area has been worked out.
> >
> > I agree there is a risk of a high cost to "fixing" addressing and management.
> > How can we get there faster? Surely innovations/projects like Dispatch
> > can only help in driving the standardization faster as it and other
> > artifacts hit issues.  I think Dispatch has already helped drive the
> > addressing discussion.
> >
> > Let's press forward.
> >
> > William
> >
> > ----- Original Message -----
> > > I don't claim to speak with any authority on Dispatch Router, but
> > > fwiw, here's my answer to these two specific questions:
> > >
> > > On 10/10/2013 04:20 PM, Rob Godfrey wrote:
> > > > How does a router differ from a broker?
> > >
> > > I tend to have a more general view of what 'broker' might mean, but
> > > in the context of statements that Dispatch Router 'is not a broker',
> > > what is meant is the type of intermediary as exemplified by the two
> > > existing Qpid brokers and others like them.
> > >
> > > As I see it, there are two key differences between Dispatch Router
> > > and these.
> > >
> > > The first is that a principle of the Dispatch Router is that it does
> > > not 'take ownership' of messages. This is in contrast to most
> > > brokers where the publisher transfers responsibility for messages to
> > > the broker and the broker then undertakes to deliver them allowing
> > > the producer to forget about them. With Dispatch Router, the idea is
> > > that it will route those messages, but any guarantee regarding
> > > acceptance of those messages comes from the consumer(s) of the
> message, not from the intermediary.
> > >
> > > The second distinction is that Dispatch Router is from the start
> > > designed to be a small piece in a distributed routing network of
> > > interconnected components.
> > >
> > > Now, there is nothing that says a broker can't do these things. In
> > > fact I added code a while back to the Qpid c++ broker that does the
> > > former - relays messages through it, providing end-to-end guarantees.
> > >
> > > Likewise the distributed architecture has its roots in things like
> > > the federation in the Qpid c++ broker (and similar solutions by other
> brokers).
> > >
> > > The Router however is setting out from the start to do *only* these
> > > things. It is based on the idea that these are separate concerns
> > > that can be split apart allowing 'brokers' to focus on queueing,
> > > persistence, transactions, augmented functionality such as LVQ
> > > patterns etc, and that the 'federation' logic can be provided in a
> > > separate component that can hook up different brokers into a
> > > federation as well as hooking in other types of AMQP based services
> > > and allow clients to connect directly to the router as well.
> > >
> > > By focusing on one aspect its thought components can do a better job.
> > > E.g. as I understand it, the Dispatch Router aims to address some of
> > > the weaknesses of the federation support in qpidd, by providing for
> > > redundant, fault-tolerant routes without duplication of messages,
> > > adapting to failures and dynamically computing the best path between
> > > two endpoints.
> > >
> > > I confess, for all its faults, federation has been one of my
> > > favourite features of the c++ broker because of the potential I see
> > > in it. That is why I started off adding some 1.0 related
> > > improvements. However I think Ted's thinking on Dispatch Router is
> > > quite compelling (though I also feel a lot of the necessary detail
> > > is still missing and it still needs to be proven).
> > >
> > > For my part, I am excited to see how this develops, am keen to take
> > > part if I can and would encourage anyone with an interest to chip in
> > > with ideas, feedback, criticism, questions, code, use cases or whatever
> else.
> > > This began as Ted's 'brainchild' - and most things begin as
> > > someone's idea - but it really is now open to anyone and everyone
> > > who is interested. Get involved and shape the direction!
> > >
> > > > Would you expect any special client APIs to form part of the
> > > > router package or not?
> > >
> > > I'm not entirely sure if I understand the question, but there are
> > > again two points I would make.
> > >
> > > First, in my opinion it is *vital* that no special client is
> > > required to use Dispatch Router effectively. Transparency is a key
> > > property. You should be able to point a JMS application or
> > > qpid::messaging or any other compliant AMQP client at it. Any
> > > special coupling between this and proton based clients would in my
> > > view be a horrendous mistake. (Nothing like that is planned I'm
> > > sure, I'm just using this as a hypothetical example to make the point).
> > >
> > > Second, the code in Dispatch Router is in theory designed around a
> > > toolkit for building  AMQP 'containers' of different kinds, with the
> > > router being one such example (another might be a proxy focused more
> > > on enforcing ACLs at the edge). In theory this could be viewed as an
> > > API of sorts. However I think at this point its better viewed as a
> > > sensible desire for some internal structure and separation of
> > > concerns. A publishable 'API' is in my view some way off and would
> > > require a lot of work that would at this point distract from the
> > > main goal, which is to define the behaviour of the router and implement
> it.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > additional commands, e-mail: users-help@qpid.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional
> commands, e-mail: users-help@qpid.apache.org

Mime
View raw message