qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: Qpid Dispatch Router component
Date Fri, 11 Oct 2013 17:43:37 GMT
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.

-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: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