qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Henry <whe...@redhat.com>
Subject Re: Qpid Dispatch Router component
Date Fri, 11 Oct 2013 17:33:21 GMT
Thanks Steve,

Yes Ted, and Gordon I believe, has been involved in trying to get this feedback based on our
experiences. 

As you know I was involved in the TC for a while but I got dragged elsewhere. Also, perhaps
I'm not as patient as I used to be for standards body work. It's a tough job and requires
a lot of patience. Maybe too much ;-)

William

----- Original Message -----
> 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
> 
> 
> ---------------------------------------------------------------------
> 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