FWIW, I concur with Rob's assessment of strategy and layering. -Steve
> -----Original Message----- > From: Robert Godfrey [mailto:[email protected]] > Sent: Friday, March 25, 2011 9:18 AM > To: [email protected]; [email protected] > Subject: Re: Qpid and AMQP 1-0: Plans? > > > On 25 March 2011 13:44, Carl Trieloff <[email protected]> wrote: > > > > > > > It would also be good to get agreement on the > implementation strategy. > > > > > Absolutely - and I think we need to start on this ASAP... > There are certainly other people coding away furiously on > AMQP 1-0 implementations... and I think we at Apache should > be striving to be amongst the first (if not the first) to implement! > > > > Personally what I believe we would want to do is provide > native Java, > > Python and C++ 1.0 transports. > > > > Additionally I would like to see that we can use either the > native or > > C++ transports in the Java and Python clients, and then I > assume that > > Ruby, PHP, C#, etc will rely on the C++ transport. > > > > This brings the advantage of being able to run pure Java, but also > > allows for Java to use the RDMA transports via C++. > > > > > I'm fairly agnostic about a pure Python implementation... I > definitely see the need for a pure Java implementation, and a > widely portable C++ or C version (something that just works > across Windows, Mac, and all UNIX-like operating systems and > architectures). Things like RDMA are likely to be less > portable, so wouldn't be in core, but should definitely be > available and pluggable into Java / .net / Scripting languages, etc. > > > > This brings me to also believe that we need to introduce the new > > messaging API into the Java client, and then update the client to > > layer JMS over that. The new messaging > > API would then be the layer at which we can swap the Java & > C++ impls out > > under > > the new messaging API. > > > > > So - I think there are two different levels of abstraction we > need to draw here, there's the lower level transport, and the > higher level messaging API. For something that will be of > use in brokers as well as clients, my feeling is that the > Messaging API is too high level and aimed more at client side > programming (although someone with more experience please > feel free to step in and correct me). > > 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). > 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 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. > > 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). > > -- Rob > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
