Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of whenry@redhat.com designates
 209.132.183.24 as permitted sender)
Date: Fri, 11 Oct 2013 12:23:22 -0400 (EDT)
From: William Henry <whenry@redhat.com>
To: users@qpid.apache.org
Message-ID: <1866448730.863692.1381508602337.JavaMail.root@redhat.com>
In-Reply-To: <5257CAE2.9090605@redhat.com>
References: <525574AE.6050008@redhat.com>
 <CACsaS946uJZsYTPQoY+p6XnS_dVyt7zPewbjchTvJ9Ys7g03vQ@mail.gmail.com>
 <52558D29.8010108@redhat.com>
 <CACsaS94Z2ehawK24tVoFFnN2PpYuBK3EgdYC6JnSRUCr+X3h1g@mail.gmail.com>
 <5256AD3A.7020904@redhat.com>
 <CACsaS94Lve5NjSDUnjXuOab0=QWH42faaueyS=6oPgiK4Mgw1A@mail.gmail.com>
 <5257CAE2.9090605@redhat.com>
Subject: Re: Qpid Dispatch Router component
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Qpid Dispatch Router component
Thread-Index: aj0noqoCz3/hEN9uki8/yOUtql/FQg==

+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