qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Qpid Dispatch Router component
Date Fri, 11 Oct 2013 09:54:42 GMT
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 

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 

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

View raw message