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
