On 03/25/2011 10:49 AM, Robert Godfrey wrote:
On 25 March 2011 14:57, Carl Trieloff<[email protected]> wrote:
Don't know if it is symantics but may not 100 agree, let's try pull that
apart.
I think what we're saying is that first we build the transport, and on top
of that we build a a library that gives the messaging API, and on top of
that we build JMS, possible WCF, and whatever other language-specific
bindings make sense. The important thing is that these are independently
versioned, releasable components (even though we will probably choose to
release all at the same time in general).
I believe we have project goals& AMQP goal. the project goals are not
necessarily
the exact same goals as AMQP.
For eample, for Qpid users we want solid inter-op and upgrade as we
introduce AMQP
1.0 and clean 0-10 1.0 inter-op for the C++ broker. For the Java broker
there may also
be a desire to also have 0-9 upgrade path. that is for those that know
better to comment
on.
I would argue that this is the highest goal.
I agree that the goals of Qpid and AMQP are not the same (and would actually
add that there are a third set of goals - the commercial ones of companies
building downstream products on top of Apache Qpid). I would suggest though
that the goal of Apache Qpid is not to be "Yet Another Message Broker", but
it pretty squarely aimed at being a/the *AMQP* messaging solution. Parts of
the project have previously decided to change from one version of the
protocol to another without having any sort of backwards API compatibility
(e.g. I believe this was the case when the C++ broker went from speaking
version 0.9 to 0.10) however I agree that this shouldn;t be the approach we
take here.
Secondly we obviously want to make is most attractive for new use to be
AMQP 1.0 and
that we provide clean API's which we have the the messaging API to be able
to consume
it in many forms.
Then there is an additional point of do we want to the 1.0 transport
semantics to be generally
reusable, which is a fine objective, but we should make sure it is fit for
Qpid propose first.
I think this is a matter of emphasis, and possibly also of philosophy. To
me we should be architecting in a way that allows us to see each strata of
of implementation as a potentially independent component or library.
Whether we actually spin these things off or not is essentially irrelevant.
What we should be thinking is that whatever transport layer we write should
be the best possible transport layer that anyone could write (because
obviously we're smarter than other people ;-) )... Therefore lots of other
people should want to use it too :-).
Part of this is possibly due to the difference in design of AMQP1-0 over
previous version of AMQP - namely that 1.0 is essentially symmetric and thus
is makes more sense to share machinery between client and broker.
Previously it would have been much less architecturally convenient to share
between clients and brokers. With 1-0 it becomes much more obvious that
this is a shared component that can be maintained independently of clients
or brokers that use it.
great, I think we are on the same page. my main point was that success
for Qpid
is to be a fantastic widely used project, and having a re-able transport
can be
an important part of that. but having a re-usable transport does not
mean per
definition success for Qpid.
This means that we're building
infrastructure which is generally useful for anybody who is interested in
using or *building* AMQP which should be an important part of our goal as
an
Apache project aiming at widespread AMQP adoption.
I would ague that we should make our client, broker, install etc easy to
consume for
widespread adoption.
For widespread adoption I think we should be aiming at clients that work
*any* AMQP 1-0 compliant broker, and brokers that work with *any* AMQP 1-0
compliant client. Anything less than that and we are missing the point of
AMQP. Clearly we are also interesting in building great broker(s) and we'll
want those to out perform and out feature any other AMQP 1-0 broker out
there... but there is no need for those features to be tied into our
clients... and indeed it'll help us if people can use clients on platforms
we don't support (for whatever reasons) but still use one of our superior
brokers.
agree.
I would see us building:
transport - as a standalone library (with RDMA, SCTP,.. whatever as
possibly non-portable implementations of part of that layer).
messaging - a client api with sub-components for SWIGed APIs in other
language, as well as a native Java (and possibly Python if desired)
implementations
jms - a JMS facade that sits on top of a messaging implementation
at the same level we might have a wcf wrapper.
All of these should really be about speaking pure AMQP1-0 and as such
should
be usable by *any* AMQP 1-0 broker (that is, of course, the point of
AMQP).
Where we have special Qpid goodness in our brokers they should be
accessible
through the defined extension points in AMQP.
Above you noted that we should start the transport. I believe for Java we
should
can work it from both sides and introduce the messaging API into the client
and
re-factor. Then we can bind in the transport down from the API and the work
on JMS can get done in parallel.
For example, if we did the work on the API, which should follow the
existing pattern
we could refactor the JMS onto it and test it on the C++ swig bound Java
version on
existing 0-10. Then we have a stable point to work the java impl, C++ impl
for 1.0 and
JMS refactor in parallel.
It also means that as the new transports get integrated into the brokers we
can get
wider test coverage faster for AMQP 1.0
Brokers are a little more problematic as really we should be looking to
bring their functionality and (for want of a better phrase) "user
interface"
more into line. Again, I think we want to be looking at reusing the
transport infrastructure (and again, the ability to use the C/C++ from the
Java Broker would be ideal). We should also be looking at separating out
system tests into something that can be run against either broker (or
indeed
any conforming AMQP 1-0 broker).
On the brokers I we are going to need to accept legacy and 1.0 traffic.
Absolutely - as previously mentioned I already have a prototype Java Broker
that builds on top of our current 0-8/0-9/0-9-1/0-10 speaking one, and adds
1-0 support and message translation.
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
