On 11 October 2013 19:43, Ted Ross <tr...@redhat.com> wrote: > Steve, > > I'm a member of the OASIS technical committee that is working on both the > addressing and management specifications. I see my role there as > tester/implementer. Both specifications have a long way to go before they > are usable IMO. It is my plan that Dispatch will become compliant with > both specifications, but it is a two-way street. The TC needs also to > respect the needs of implementers. > > I absolutely agree... that is the point of the TCs. It would be good if all of us who have questions, comments, etc raise them to the TC, and those of us who are members ensure that these concerns/comments/questions are acted upon and also fedback to this list.
None of the work in progress is solidified yet precisely because it needs feedback from implementers and users. The work won't be finalised until we have interoperable implementations from different sources. If you've raised concerns around the two pieces of work in question and you do not think they have been adequately addressed, you should definitely send a chaser e-mail. If there is stuff you haven't raised yet, then please do so. To be clear, the latest working draft of the addressing specification is here: https://www.oasis-open.org/committees/document.php?document_id=50701&wg_abbrev=amqp And the latest draft of the management specification is here: https://www.oasis-open.org/committees/document.php?document_id=50101&wg_abbrev=amqp Those who are not members of the TCs can raise comments/questions through the public comment list (see: https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp) Hope this helps, Rob -Ted > > > > On 10/11/2013 01:18 PM, Steve Huston wrote: > >> 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-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org>For >>>>> additional commands, e-mail: users-h...@qpid.apache.org >>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>> --------- >>>> To unsubscribe, e-mail: >>>> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org>For >>>> additional commands, e-mail: users-h...@qpid.apache.org >>>> >>>> >>>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org>For >>> additional >>> commands, e-mail: users-h...@qpid.apache.org >>> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
