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.
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.
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.
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.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
