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:whe...@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-unsubscr...@qpid.apache.org For
additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For
additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional
commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
