So, just to be clear the reason I asked the question is to try to help us frame better a scope statement.
People often ask why we currently have both a Java Broker and a C++ broker, and I think it's a fair question :-). If we start building up Dispatch as a component and someone says "hey - it'd be really cool to have some sort of message store built into Dispatch" and so on... how do we define the difference between what Dispatch might become and what we have in brokers currently? The questions on client APIs were really a nod to the confusion in scope that I see in Proton. Again, within Messenger I see it as not a huge step to suddenly add some storage and a bit of configuration and again ... you have something that looks a lot like a broker. Going back to Fraser's mail I think we need to be clear on what each component is and what it isn't (being clear on it ourselves seems to be a pre-requisite of being able to explain it to others :-) ). -- Rob On 11 October 2013 11:54, Gordon Sim <g...@redhat.com> wrote: > 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 > >
