On 18/01/2008, Gordon Sim <[EMAIL PROTECTED]> wrote: > 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.
Indeed and in thinking more about the recent changes due to support the Fanout exchange I realise that I missed the obvious fact that the BindingURL was reusing the amq.direct queue notion. The fanout exchange doesn't take a routing key so its value is surely unimportant. using fanout://amq.fanout//<queue_name> would work just fine with the current implementation. Ensuring a Destination was created is all that is required. The JMS Destination abstraction is the correct point here to correctly abstract the JNDI destinations so that the code can remain pure JMS. The question of portability then becomes does vendor a support this destination type. If so adjust syntax (which AMQP should standardise by the way) and job sorted. -- Martin Ritchie
