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:whe...@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-unsubscr...@qpid.apache.org For > > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > > additional commands, e-mail: users-h...@qpid.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional > commands, e-mail: users-h...@qpid.apache.org
