Martin Ritchie wrote:
There should never be a question of using interfaces A or interfaces B that will never work. In Java JMS _IS_ the interfaces used, the only option is to extend it but that should only be for the 1% use cases. Vendor lockin is something AMQP is working to avoid. So in the Java space we should attempt to be pure JMS. The AMQP features can be worked in via config such as JNDI or broker side queue configurations.
I think exploring whether the AMQDestination abstraction could be made a bit more powerful would be a good thing. E.g. by moving the actions performed when creating a subscriber or producer into the AMQDestination subclass rather than having that encoded in the session, producer or consumer implementations. (I'd need to spend some more time looking at the code to be more precise on this).
That would mean that you could get non-standard behaviour by supplying a custom subclass as the destination (however you obtained this destination instance). Though using non-standard destinations would likely reduce your ability to move between JMS providers, your code could process streams of messages using only normal JMS interfaces.
i.e. I think the AMQDestination could be enhanced to become a single, unintrusive extension point that could offer a fair bit of flexibility and power.
