2009/3/20 Jonathan Robie <[email protected]>: > James Mansion wrote: >> >> There are lots of JMS implementations. My own interest in AMQP is largely >> driven >> by it NOT being JMS - so there is a chance that my C#, Python and C++ code >> can be first class citizens. Clearly other people will have different >> priorities. > > Interop across languages and platforms is clearly an important design > criterion. I don't think anyone disagrees with you here. > > Our Java JMS clients interoperate with clients in Python and C++. There's > clearly demand for Java JMS support. I would like to also see a Java client > that more directly reflects AMQP, as our clients in other languages do. >
I must admit see no real reason for this *unless* 1) there is defined some common AMQP API that is not JMS and is blessed by the AMQP working group, or 2) there are significant features of AMQP than cannot be comfortably accessed through JMS or obvious extensions. Writing proprietary APIs for basic messaging functionality seems like a giant step backwards. It seems to me that the main motivation to have an API in Java that is directly based on AMQP is to make the example code between languages similar. Frankly as a Java developer I think knowing how to program to the JMS API is fair... asking me to learn an API for AMQP which is standardized across vendors, but isn't JMS, seems a little annoying but if it brings me great benefits I can probably live with it. Asking me to learn an API which is completely specific to Qpid/Java seems wilfully perverse. It seems that in the other languages we are moving towards a more protocol-neutral API. I don't see any reason to move in the reverse direction for Java. -- Rob --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
