On 07/06/07, Martin Ritchie <[EMAIL PROTECTED]> wrote:
Providing two distinct APIs seems like a clean way forward with new applications but it doesn't seem to offer much in the way of migration for existing JMS API users.
So, how do we let a JMS application do something that is more AMQP like? For example, there is no way in the current JMS implementation to do JMS over a headers exchange. Some suggestions: 1. Use the management console to set up the headers exchange and bind a queue to it. The JMS just accesses this queue already set up. 2. Do the same thing, but you specify this in the properties that you pass to the JNDI context, to get your connection factory from. Not exactly a nice solution. Both these approaches are pure JMS compliant. If you changed to a different JMS product, you'd have to figure out their way of doing it. 3. Provide an extension API that gives you access to AMQP features, or just make the lower level AMQ API available publicly. Once an app starts doing 3, its not plain JMS anymore, so can't change to a different JMS provider. At least its the application writers choice to move outside of JMS. Rupert
