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. > > 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. > > 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
