Cliff Jansen wrote:
Perhaps it would be useful for somebody to assist this debate by introducing the messaging API in the .NET context and addressing why, for example, .NET programmers need this API, but Java programmers don't. Or why a developer who might be inclined to use WCF should use this messaging API instead.
I think Java developers do need this as it addresses a number of use cases that are not possible with JMS, e.g. explicit control over sync vs async publish, unacked message windows, and prefetch, as well as better support for non-blocking programming models. It's just lower priority because JMS covers many of the common cases already. Also, it makes sense to build it out and let it mature a bit in C++/Python before trying to take it to other languages.
Really this API isn't a million miles away from JMS anyways, so an ideal architecture would be JMS as a very thin layer on top of a Java version of the API. This would allow people to use JMS for many things they already know how to do there and then drop into the API for more advanced scenarios.
--Rafael --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
