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
